Назад | Перейти на главную страницу

Перенаправление портов через удаленное имя хоста невозможно подключиться, работает через IP

Я пытаюсь выполнить перенаправление локального порта через ssh на удаленный сервер («сервер перехода»), у которого есть доступ к серверу mariadb («сервер БД»). Сервер перехода имеет публичный IP-адрес 1.2.3.4, а сервер БД - внутренний IP-адрес 10.5.6.7. Следующая команда работает должным образом:

ssh -v -N user@1.2.3.4 -L 3306:10.5.6.7:3306

Однако внутренний IP-адрес сервера БД не является статическим, поэтому я хотел бы полагаться на его внутреннее имя хоста, mariadb.local. Однако следующее не работай:

ssh -v -N user@1.2.3.4 -L 3306:mariadb.local:3306

Создание следующего вывода из sshd на сервере перехода:

debug1: active: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch
debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0
debug1: server_input_channel_open: ctype direct-tcpip rchan 2 win 2097152 max 32768
debug1: server_request_direct_tcpip: originator 127.0.0.1 port 58953, target mariadb.local port 3306
connect_to mariadb.local: unknown host (Try again)
debug1: server_input_channel_open: failure direct-tcpip

Таким образом, похоже, что это проблема разрешения DNS, но я не уверен, как разрешение DNS работает во время переадресации портов, поэтому здесь мои знания ломаются. Для ясности, это результат пинга с сервера перехода:

/ # ping mariadb.local
PING mariadb.local (10.5.6.7): 56 data bytes

Примечание: вся эта среда фактически находится в кубернетах, поэтому имя хоста mariadb.local становится доступным через службу и разрешается через k8s coreDNS. Однако я не могу понять, почему это повлияет на что-либо, поэтому я пропустил это в основном описании проблемы, чтобы не усложнять проблему и не предлагать «использовать kubectl port-forward»; это не вариант, поскольку я хочу сделать эту службу доступной для пользователей, которым не хочу предоставлять доступ kubectl.

Проблема заключалась в том, что пользователь был заблокирован, что, как оказалось, если UsePrivilegeSeparation is on (что является обязательным в openSSH 7.5) также искоренит разветвленный процесс.

Очевидно, что это привело к тому, что процесс не мог читать /etc/resolv.conf что необходимо для правильного разрешения имен хостов. Есть несколько решения к этому, но, по сути, если у вас возникли такие проблемы, вероятно, resolv.conf не читается по той или иной причине (другой возможной проблемой могут быть разрешения этого файла).