Я столкнулся с проблемой, когда ssh к удаленному серверу зависает с сообщением SSH2_MSG_KEXINIT отправлен. Я уже изучил варианты MTU без везения.
Случай 1 (сбой)
Это происходит, когда я подключаюсь по ssh со своего ПК с Linux через маршрутизатор openWRT, на котором запущен клиент openVPN. У меня настроен роутер на пересылку из локальной сети 44.20.11.0/24 к VPN tun0. Я могу успешно пропинговать удаленный сервер ssh со своего ПК, поэтому я не думаю, что переадресация является проблемой.
Эта версия клиента openVPN для ПК 2.5.2 mips-openwrt-linux-gnu. Серверная версия openWRT openVPN опенвпн-2.3.8-16.26.1.x86_64.
Вот вывод клиента ssh для неудачного случая:
ssh -vvvv [email protected]
OpenSSH_8.8p1, OpenSSL 1.1.1m 14 декабря 2021 г.
debug1: Чтение данных конфигурации /home/myuser/.ssh/config
debug1: Чтение данных конфигурации /usr/etc/ssh/ssh_config
debug1: /usr/etc/ssh/ssh_config строка 24: включение /etc/ssh/ssh_config.d/*.conf не соответствует ни одному файлу
debug1: /usr/etc/ssh/ssh_config строка 26: Применение параметров для *
debug2: resolve_canonicalize: имя хоста 10.84.96.200 — это адрес
debug3: расширенный UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/myuser/.ssh/known_hosts'
debug3: расширенный UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/myuser/.ssh/known_hosts2'
debug3: ssh_connect_direct: вход
debug1: подключение к порту 22 10.84.96.200 [10.84.96.200].
debug3: set_sock_tos: установить сокет 3 IP_TOS 0x10
отладка1: соединение установлено.
debug1: файл идентификации /home/myuser/.ssh/id_rsa типа 0
debug1: файл идентификации /home/myuser/.ssh/id_rsa-cert type -1
debug1: файл идентификации /home/myuser/.ssh/id_dsa тип -1
debug1: файл идентификации /home/myuser/.ssh/id_dsa-cert type -1
debug1: файл идентификации /home/myuser/.ssh/id_ecdsa типа 2
debug1: файл идентификации /home/myuser/.ssh/id_ecdsa-cert type -1
debug1: файл идентификации /home/myuser/.ssh/id_ecdsa_sk тип -1
debug1: файл идентификации /home/myuser/.ssh/id_ecdsa_sk-cert type -1
debug1: файл идентификации /home/myuser/.ssh/id_ed25519 тип -1
debug1: файл идентификации /home/myuser/.ssh/id_ed25519-cert type -1
debug1: файл идентификации /home/myuser/.ssh/id_ed25519_sk тип -1
debug1: файл идентификации /home/myuser/.ssh/id_ed25519_sk-cert тип -1
debug1: файл идентификации /home/myuser/.ssh/id_xmss тип -1
debug1: файл идентификации /home/myuser/.ssh/id_xmss-cert type -1
debug1: строка локальной версии SSH-2.0-OpenSSH_8.8
debug1: удаленный протокол версии 2.0, удаленная версия программного обеспечения OpenSSH_7.6
debug1: compat_banner: соответствие: OpenSSH_7.6 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* совместимость 0x04000002
debug2: параметр fd 3 O_NONBLOCK
debug1: Аутентификация на 10.84.96.200:22 как «мой пользователь»
debug3: record_hostkey: найден тип ключа ECDSA в файле /home/myuser/.ssh/known_hosts:828
debug3: record_hostkey: найден тип ключа RSA в файле /home/myuser/.ssh/known_hosts:2050
debug3: record_hostkey: найден тип ключа DSA в файле /home/myuser/.ssh/known_hosts:2051
debug3: record_hostkey: найден тип ключа ED25519 в файле /home/myuser/.ssh/known_hosts:2052
debug3: load_hostkeys_file: загружено 4 ключа с 10.84.96.200
debug1: load_hostkeys: fopen /home/myuser/.ssh/known_hosts2: нет такого файла или каталога
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: нет такого файла или каталога
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: нет такого файла или каталога
debug3: order_hostkeyalgs: иметь соответствующий тип ключа наилучшего предпочтения [email protected], используя HostkeyAlgorithms дословно
debug3: отправить пакет: введите 20
debug1: SSH2_MSG_KEXINIT отправлено```
Вот маршрут ПК для этого сценария (Случай 1, сбой):
по умолчанию через 44.20.6.1 dev br0
10.0.0.0/8 через 44.20.11.11 dev enp1s0
44.20.6.0/24 dev br0 ссылка на область ядра прото src 44.20.6.2
44.20.11.0/24 dev enp1s0 прото-область ядра ссылка src 44.20.11.187
Случай 2 (работает)
Когда я запускаю клиент openVPN непосредственно на ПК с Linux, я могу успешно подключиться по ssh к удаленному ssh-серверу. Это заставляет меня думать, что проблема заключается в маршрутизаторе openWRT/openVPN.
Эта версия клиента openvpn 2.5.5 x86_64-suse-linux-gnu
Вот маршрут ПК с Linux при обходе маршрутизатора openWRT и запуске клиента openVPN непосредственно на ПК:
по умолчанию через 44.20.6.1 dev br0
44.20.6.0/24 dev br0 ссылка на область действия ядра proto src 44.20.6.2
44.20.11.0/24 dev enp1s0 прото-область ядра ссылка src 44.20.11.187
В любой момент времени у меня работает только один экземпляр клиента openVPN.
Я прочитал все темы, предлагающие изменить MTU. Я пытался установить его на 1492, 1000, и 576 на сетевых устройствах на стороне клиента, без везения. MTU сервера openVPN на стороне сервера установлен на 1492.
И ПК с Linux, и VPN-клиенты openWRT/openVPN используют одну и ту же конфигурацию клиента (соответствующие части включены):
клиент
разработчик тун
поддержка активности 10 300
reeg-sec 0
auth-user-pass
скрипт-безопасность 3
тяга
постоянный ключ
упорный тун
сервер типа ns-cert
комп-льзо
глагол 6
заглушить 20
аутентификация SHA512
шифр AES-256-CBC
Мои наблюдения:
Поскольку это работает при запуске VPN-клиента непосредственно на ПК с Linux, я не считаю, что это неправильная конфигурация клиента или сервера openVPN. Я подозреваю, что проблема кроется между ними, в маршрутизаторе openWRT/openVPN. При ssh'ировании напрямую с роутера openWRT соединение тоже зависает.
мтр 10.84.96.200 показывает отсутствие потери пакетов.
Подозреваю, что проблема может заключаться в одном из этих пунктов:
- Я не изменил MTU на правильных сетевых устройствах
- MTU должно быть значением, отличным от
1492, 1000 или же 576
- На маршрутизаторе openWRT есть настройка брандмауэра, которая нарушает это.
- Что-то в openWRT мешает этому
Устройство openWRT представляет собой туристический маршрутизатор gl.inet Slate. Я могу получить доступ к журналам как с клиента, так и с сервера openVPN, но я не могу изменить openVPN на стороне сервера. Я могу получить доступ и изменить сервер ssh на стороне сервера.
Вот диаграмма, которая, надеюсь, объяснит более ясно:
