Обратная переадресация порта SSH не работает, если не связанный интерфейс обратной связи отключен.

Вопрос или проблема

У меня есть удаленная машина, на которой обычно есть 2 обратных интерфейса:

[email protected] : / > ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: lo

lo100: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.0.2 netmask 0xffff0000
        inet6 fe80::1%lo100 prefixlen 64 tentative scopeid 0x5
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        groups: lo

С этой машины я открываю обратный ssh к известному хосту. Предположим, он начинает прослушивать по порту 12345.

ssh -N \
    -T \
    -R 0:127.0.0.1:22 \
    [email protected]

С remotemachine.com, когда я вхожу в систему, я делаю следующее. Это работает нормально.

ssh -p 12345 [email protected]

Вот в чем проблема:

  • если я выполню ifconfig lo100 down, то ssh с remotemachine.com больше не работает, пока я не выполню ifconfig lo100 up.
  • вместо этого, если я выполню ifconfig lo100 down destroy и затем перезапущу команду удаленного SSH, то все работает хорошо.

Почему команда обратного SSH зависит от того, что lo100 активен, когда lo0 удерживает 127.0.0.1 (который используется в команде обратного SSH)?

Проблема связана с маской подсети, установленной на lo100.

По умолчанию, у lo100 кажется, что маска подсети составляет 255.255.0.0 (т.е. /16). Это как-то конфликтует с lo0 и вызывает проблемы, когда устанавливается обратное соединение.

Проблема описана ниже.

  • На ВМ мы видим следующие интерфейсы:
[email protected] : / > ifconfig lo100
lo100: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.0.2 netmask 0xffff0000
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        groups: lo
[email protected] : / > ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: lo
  • После запуска обратного SSH на ВМ мы можем войти из прыжка:
# remote @ remotemachine.com in ~ [14:22:36]
$ ssh -p 60454 ...
Последний вход: Пт Дек 20 06:19:57 2024 с 127.0.0.1
...
  • После входа из прыжка мы видим открытые следующие сокеты:
[email protected] : / > sockstat -c -P tcp | grep ssh
root     sshd       88301 4  tcp4   127.0.0.1:22          127.0.0.2:56760         <<<< lo100 IP
root     sshd       88065 4  tcp4   127.0.0.1:22          127.0.0.2:56760
...
  • Если мы отключим lo100, то ssh из прыжка останавливается:
[email protected] : / > ifconfig lo100 down
[email protected] : / > sockstat -c -P tcp | grep ssh
root     ssh        74726 4  tcp4   127.0.0.2:56760       127.0.0.1:22
  • из прыжка мы не можем снова подключиться по ssh.
# remote @ remotemachine.com in ~ [14:26:26]
$ ssh -p 60454 ...
^C%

# remote @ remotemachine.com in ~ [14:26:26]
$

Если мы установим маску подсети на lo100 как 255.0.0.0 (т.е. /8), то она не будет конфликтовать с lo0.
Это означает, что независимо от того, что происходит с lo100 (вниз и/или уничтожение), соединение обратного SSH не сбрасывается.
Подтверждение работы ниже.

  • На ВМ мы видим следующие интерфейсы:
[email protected] : / > ifconfig lo100
lo100: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.0.2 netmask 0xff000000
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        groups: lo
[email protected] : / > ifconfig lo0
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: lo
  • После запуска обратного SSH на ВМ мы можем войти из прыжка:
# remote @ remotemachine.com in ~ [14:30:02]
$ ssh -p 62768 ...
Последний вход: Пт Дек 20 06:29:35 2024 с 127.0.0.2
...
  • После входа из прыжка мы видим открытые следующие сокеты:
[email protected] : / > sockstat -c -P tcp | grep ssh
zsroot   sshd       35528 4  tcp4   127.0.0.1:22          127.0.0.1:60722           <<<< lo0 IP
...
  • Если мы отключим lo100, то ssh из прыжка не останавливается:
[email protected] : zsroot > ifconfig lo100 down
[email protected] : zsroot > sockstat -c -P tcp | grep ssh
root     sshd       35528 4  tcp4   127.0.0.1:22          127.0.0.1:60722
root     sshd       35304 4  tcp4   127.0.0.1:22          127.0.0.1:60722
...

Ответ или решение

Обратная SSH-перенаправка: Влияние состояния интерфейса lo100 на работу

Проблема, с которой вы столкнулись, заключается в том, что обратная SSH перенаправка не работает, если интерфейс lo100 отключен, в то время как интерфейс lo0, используемый для локального соединения, остается активным. Чтобы понять, почему так происходит, необходимо рассмотреть архитектуру сетевого взаимодействия и конфигурацию интерфейсов.

Архитектура интерфейсов

На вашем удаленном сервере существуют два интерфейса обратной петли:

  1. lo0 (с IP-адресом 127.0.0.1)
  2. lo100 (с IP-адресом 127.0.0.2 и сетевой маской 255.255.0.0)

Каждый из этих интерфейсов предназначен для обеспечения локальной отправки пакетов, однако наличие двух интерфейсов с перекрывающимися IP-адресами создает определенные сложности.

Причины проблемы

Когда интерфейс lo100 отключен с помощью команды ifconfig lo100 down, все соединения, использующиеся для обмена данными между сервером SSH и клиентом, которые зависят от lo100, также становятся недоступными. Ваша команда обратной SSH:

ssh -N -T -R 0:127.0.0.1:22 user@remotemachine.com

устанавливает перенаправление порта с локального адреса 127.0.0.1 на порт 22. Однако в данном случае и с учетом настроек lo100, если этот интерфейс неактивен, SSH-сервер не может завершить соединение.

Проблема конфликтующих масок

Сетевой маской 255.255.0.0 (/16) для lo100 создается перекрытие с lo0, который использует маску 255.0.0.0 (/8). Это приводит к конфликтам при маршрутизации пакетов, когда система пытается определить наилучший путь к IP-адресам в диапазонах 127.0.0.0/8 и 127.0.0.0/16. В результате, когда lo100 отключен, маршрутизация пакетов, как правило, зависит от активного интерфейса, и любые запросы, которые должны были отправляться через Active Interface (lo100), не могут быть завершены.

Решение проблемы

Чтобы избежать этой проблемы, вы предприняли правильные шаги, изменив маску подсети для lo100 на 255.0.0.0 (/8). Это позволило интерфейсу lo100 работать совместно с lo0, поскольку теперь они использовали разные диапазоны IP-адресов без перекрытия. С новым конфигурированным интерфейсом вы можете отключить lo100, и, тем не менее, ваши соединения SSH останутся активными.

Заключение

Проблема, с которой вы столкнулись, сводится к взаимодействию между двумя интерфейсами обратной связи с конфликтующими сетевыми масками. Уменьшение размера маски для интерфейса lo100 до уровня, который позволяет избежать конфликта, обеспечивает стабильную работу SSH-соединений. Убедитесь в том, что вся конфигурация сети правильно настроена и поддерживается, чтобы минимизировать возможные конфликты и обеспечить бесперебойную работу ваших SSH-подключений.

Рекомендации для дальнейшего изучения

  1. Документация по Linux сети: Ознакомьтесь с принципами работы сетевых интерфейсов в Linux.
  2. Статистика соединений: Используйте утилиты, такие как sockstat, для мониторинга активных соединений и понимания зависимостей между интерфейсами.
  3. Сетевые таблицы маршрутизации: Изучите команду route или ip route, чтобы лучше понять маршрутизацию на вашем сервере.

Таким образом, у вас будет полное понимание причин возникновения данной проблемы и путей ее решения.

Оцените материал
Добавить комментарий

Капча загружается...