Разделенные виртуальные сети с тем же диапазоном подсетей с 2 интерфейсами

После четырех лет этот ответ заслужил обновления. В то время как первоначально я использовал authorized_keys самостоятельно и вероятно использовал бы его все еще в некоторых избранных случаях, можно также использовать центральное sshd_config конфигурационный файл сервера.

sshd_config

Можно назначить (для конкретного варианта использования) группу, такой как proxy-only или Match отдельные пользователи. В sshd_config. Это сделано после глобальных настроек и отменяет, повторяет или совершенствовало некоторые настройки, данные в глобальных настройках.

Примечание: часть синтаксиса/директив, используемого в sshd_config(5) документируются в man страница для ssh_config(5). В особенности удостоверьтесь, что считали раздел PATTERNS ssh_config(5).

Для группы это означает Ваш Match блок начался бы как это:

Match group proxy-only

Вы можете Match следующие критерии: User, Group, Host, LocalAddress, LocalPort и Address. Соответствовать нескольким критериям, просто отдельным от запятой пары шаблона критериев (group proxy-only выше).

В таком блоке, который традиционно располагается с отступом соответственно для краткости (но не должен к), можно затем объявить настройки, Вы хотите запросить группу пользователей, не имея необходимость редактировать каждый authorized_keys файл для членов той группы.

no-pty сходя authorized_keys был бы зеркально отражен a PermitTTY no установка и command="/sbin/nologin" стал бы ForceCommand /sbin/nologin.

Дополнительно можно также установить больше настроек для удовлетворения паранойи администратора, такой как chroot- луг пользователь в его домашнюю папку и закончился бы с чем-то вроде этого:

Match group proxy-only
    # AllowTcpForwarding no
    ChrootDirectory %h
    ForceCommand /sbin/nologin
    # GatewayPorts yes
    # KbdInteractiveAuthentication no
    # PasswordAuthentication no
    # PubkeyAuthentication yes
    # PermitRootLogin no
    PermitTTY no

(проверьтесь, нуждаетесь ли Вы или хотите закомментированные строки и не комментируете по мере необходимости),

%h маркер, которым заменяет каталог мотыги пользователя (%u привел бы к имени пользователя и %% знак процента). Я нашел ChrootDirectory особенно полезный для ограничения моего sftp-only пользователи:

Match group sftp-only
    X11Forwarding no
    AllowTcpForwarding no
    ChrootDirectory %h
    ForceCommand internal-sftp
    PasswordAuthentication no

Возражайте против этого, только определенные директивы могут использоваться в a Match блок. Консультируйтесь man страница sshd_config(5) для деталей (ищут Match).

authorized_keys

NB: часть ниже этого комментария был моим исходным ответом. Между тем - но это также зависит от функций Вашего точного sshd версия - я пошел бы для метода, описанного выше в большинстве случаев.

Да Вы можете, столь мелкомодульный, как можно присвоить открытые ключи. В дополнение к nologin, как рекомендуется ajdecon, я предложил бы установить следующее перед ключевой записью в authorized_keys:

no-pty ssh-rsa ...

Никакое имущество не говорит серверной стороне, что никакой псевдотерминал не должен быть выделен для того ключа.

Можно также вызвать выполнение чего-то как nologin для конкретного ключа путем предварительного ожидания этого:

command="/sbin/nologin",no-pty ssh-rsa ...

0
задан 6 November 2013 в 12:59
2 ответа

У нас была точно такая же конфигурация с разными IP-адресами. У одного хоста был настроен IP-адрес для нескольких интерфейсов, например:

10.0.0.0/24 dev eth1  proto kernel  scope link  src 10.0.0.10 
10.0.0.0/24 dev eth2  proto kernel  scope link  src 10.0.0.10 
10.0.0.0/24 dev eth3  proto kernel  scope link  src 10.0.0.10

Мне просто нужно было добавить IP-маршруты, например:

> ip route add 10.0.0.123 dev eth3

Итак, у меня были записи вроде:

> ip route show
...
10.0.0.123 dev eth3  scope link 
10.0.0.101 dev eth2  scope link 
10.0.0.136 dev eth1  scope link
...

После этого все должно работать. @nickw, предлагающий правила, основанные на политике, также может быть правильным, но я считаю этот подход немного проще.


Примечание: ИМХО, это действительно плохая практика, у нас с ней возникло много проблем. Также, AFAIK, вы не сможете получить доступ к хосту на другом интерфейсе без изменения IP-маршрута или записей правил, поэтому вам придется перенастроить таблицы, если вы переместите машину в другую (физическую) сеть.

1
ответ дан 4 December 2019 в 17:58

Проблема заключается в следующем:

Если компьютер находится в подсети 1, я могу пропинговать его. Если компьютер находится в подсети 2, я не могу его пропинговать.

Как я могу заставить сервер искать на обоих интерфейсах одну и ту же ранжированную подсеть для определенного IP?

Это невозможно. Не на уровне ядра.

Вы не можете иметь два маршрута в таблице маршрутизации и ожидать, что ядро ​​попробует оба, если вы не укажете что-либо еще, например, какой интерфейс или IP-адрес источника использовать.

Основное правило Практический опыт заключается в следующем: если хост недоступен через интерфейс, НЕ добавляйте маршрут для этого хоста на этом интерфейсе. Хосты не должны быть «умными» или волшебным образом угадывать, какой интерфейс использовать. Если есть маршрут, ядро ​​всегда выбирает этот маршрут, даже если он не работает.

У вас может быть несколько таблиц маршрутизации в зависимости от IP-адреса источника, интерфейса вывода, указанного приложением, или метки, или tos, или многих других параметров, и даже несколько сетевых пространств имен, но в конце, если вы выполните простой «ping 192.168.1.3», ядро ​​выберет только один маршрут в одной из ваших таблиц маршрутизации и будет использовать его.

Даже если Linux имеет техническую возможность циклического перебора маршрута, который следует использовать, он будет делать это для каждого пакета. Если вы используете это, у вас будет потеря 50% пакетов для достижения вашего хоста.


Если вам нужна эта несколько неработающая установка для работы, либо:

  • Соедините две сети, на ваших серверах или на ваших коммутаторах, даже если это только с точки зрения вашего сервера.
  • Убедитесь, что ваш хост 192.168.1.3 виден из обеих сетей
  • на уровне 2, соедините два ваших интерфейса и продублируйте все, что отправляется на eth0, на eth1 . Да, это ужасно.
  • Перестаньте перемещать 192.168.1.3 из двух ваших подсетей.
  • Запустите протокол маршрутизации на своем сервере и на 192.168.1.3, чтобы таблицы маршрутизации автоматически корректировались в зависимости от того, где находится 192.168.1.3.
0
ответ дан 4 December 2019 в 17:58

Теги

Похожие вопросы