SSH в пространство имен, соединение отказано

Question

У меня есть сервер Ubuntu с двумя сетевыми интерфейсами и пространством имен с именем "bluewire" (названным в честь цвета подключенного к нему кабеля Ethernet).

Пространство имен bluewire имеет добавленный интерфейс enp4s0 и изолирован от WAN (что желательно). Я могу SSH с PuTTY со своего рабочего стола на сам сервер через 192.168.1.1:22, но PuTTY выдает ошибку "Отказ в соединении", когда я пытаюсь подключиться через 192.168.1.2:22. Я подозреваю, что пространство имен вообще не слушает никаких портов.

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

Дополнительная информация:

• UFW открыт как на стороне сервера, так и на стороне ip netns exec bluewire для OpenSSH.
• Правила iptables для пространства имен bluewire широко открыты (все установлено на ACCEPT).
• Сервер может быть проверен с адреса .2, он просто отказывается от соединения. После запуска ip netns exec bluewire tcpdump -n dst port 22 я могу предположить, что сервер знает, что он получает запрос с рабочего стола.
• Запуск netns -an показывает, что сервер сам прослушивает порт 22, но ip netns exec bluewire netstat -an открывает пустую таблицу. Вот где я подозреваю, что проблема.
• В случае, если вам интересно, почему у меня такая настройка: красный провод соединяет сервер с интернетом, а синий - от интернета. Причина в том, что если я подозреваю, что мой сервер подвергается атаке (например, мои личные ключи ifdown), то я могу отключить или отключить интерфейс красного провода и ограничить доступ сервера к локальной сети, чтобы я мог изменить SSH только через рабочий стол для изменения замки.

РЕДАКТИРОВАТЬ

За комментарий Blerg ниже, скриншот netstat -plunt

• Оба интерфейса доступны для проверки через командлет Windows на моем рабочем столе.
• Насколько я знаю, маршрутизатор не блокирует порты во внутренней сети; он просто блокирует весь доступ из внешнего мира, за исключением 1194, который я использую для OpenVPN. Я могу подключиться через интерфейс .1 без каких-либо проблем, используя настольный PuTTY, поэтому я сомневаюсь, что виновником является роутер ... возможно.

• Мой файл /etc/ssh/sshd_config

  [07:28]<~ @ > $ cat /etc/ssh/sshd_config
  # Package generated configuration file
  # See the sshd_config(5) manpage for details
  # What ports, IPs and protocols we listen for
  Port 22
  # Use these options to restrict which interfaces/protocols sshd will bind to
  #ListenAddress ::
  ListenAddress 192.168.1.1
  ListenAddress 192.168.1.2
  Protocol 2
  # HostKeys for protocol version 2
  HostKey /etc/ssh/ssh_host_rsa_key
  HostKey /etc/ssh/ssh_host_dsa_key
  HostKey /etc/ssh/ssh_host_ecdsa_key
  HostKey /etc/ssh/ssh_host_ed25519_key
  #Privilege Separation is turned on for security
  UsePrivilegeSeparation yes
  # Lifetime and size of ephemeral version 1 server key
  KeyRegenerationInterval 3600
  ServerKeyBits 1024
  # Logging
  SyslogFacility AUTH
  LogLevel INFO 
  # Authentication:
  LoginGraceTime 120
  PermitRootLogin prohibit-password
  StrictModes yes
  RSAAuthentication yes
  PubkeyAuthentication yes
  #AuthorizedKeysFile     %h/.ssh/authorized_keys
  # Don't read the user's ~/.rhosts and ~/.shosts files
  IgnoreRhosts yes
  # For this to work you will also need host keys in /etc/ssh_known_hosts
  RhostsRSAAuthentication no
  # similar for protocol version 2
  HostbasedAuthentication no
  # Uncomment if you don't trust ~/.ssh/known_hosts for 
  # RhostsRSAAuthentication
  #IgnoreUserKnownHosts yes
  # To enable empty passwords, change to yes (NOT RECOMMENDED)
  PermitEmptyPasswords no
  # Change to yes to enable challenge-response passwords (beware issues with
  # some PAM modules and threads)
  ChallengeResponseAuthentication no
  # Change to no to disable tunnelled clear text passwords
  PasswordAuthentication no
  # Kerberos options
  #KerberosAuthentication no
  #KerberosGetAFSToken no
  #KerberosOrLocalPasswd yes
  #KerberosTicketCleanup yes
  # GSSAPI options
  #GSSAPIAuthentication no
  #GSSAPICleanupCredentials yes
  X11Forwarding yes
  X11DisplayOffset 10
  PrintMotd no
  PrintLastLog yes
  TCPKeepAlive yes
  #UseLogin no    
  #MaxStartups 10:30:60
  Banner /etc/issue.net
  # Allow client to pass locale environment variables
  AcceptEnv LANG LC_*    
  Subsystem sftp /usr/lib/openssh/sftp-server    
  # Set this to 'yes' to enable PAM authentication, account processing,
  # and session processing. If this is enabled, PAM authentication will
  # be allowed through the ChallengeResponseAuthentication and
  # PasswordAuthentication.  Depending on your PAM configuration,
  # PAM authentication via ChallengeResponseAuthentication may bypass
  # the setting of "PermitRootLogin without-password".
  # If you just want the PAM account and session checks to run without
  # PAM authentication, then enable this but set PasswordAuthentication
  # and ChallengeResponseAuthentication to 'no'.
  UsePAM yes
  [07:29]<~ @ > $
  

Answer 1

Для тех, кто заинтересован, я нашел решение здесь: https://blog.bofh.it/debian/id_446.

Хитрость заключается в том, чтобы запустить отдельный сервер sshd в каждом пространстве имен:

ip netns exec mynamesapce /usr/sbin/sshd -o PidFile=/run/sshd-mynamespace.pid

Конечно, брандмауэр должен разрешать tcp/ssh

 

Answer 2

Из того, что я могу сказать из вашего поста, ваш демон SSH, вероятно, прослушивает только один интерфейс. В вашем /etc/ssh/sshd_config убедитесь, что в списке ListenAddress указано следующее: #ListenAddress . Если он включен, сервер OpenSSH будет прослушивать только входящие соединения по указанному адресу (ам). Если вы хотите использовать ListenAddress для нескольких IP-адресов, то вам нужно, чтобы они были в отдельных строках, например так:

ListenAddress 192.168.1.1
ListenAddress 192.168.1.2