SSH через VPN через Wi-Fi Hotspot не работает

У меня есть туннель VPN Netscreen vpnc, который я подключаю из разных ящиков Linux (Ubuntu, Lubuntu, Antergos), и все они показывают одинаковое поведение.

Когда я использую USB-модем, подключенный к компьютеру для подключения к Интернету, я могу подключить туннель VPN и использовать любую услугу – HTTP, HTTPS, Ping, SSH – тогда, как и ожидалось.

Если, однако, я подключаюсь к Интернету через точку доступа WiFi (и я уже тестировал несколько разных, из дома, офиса и некоторого бесплатного общедоступного Wi-Fi), только HTTP, HTTPS и PING, похоже, работают, в то время как SSH stucks в середине начальные переговоры:

$ ssh -v root@123.45.67.89 OpenSSH_6.7p1 Ubuntu-5ubuntu1.4, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 123.45.67.89 port 22. debug1: Connection established. debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_rsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_rsa-cert type -1 [ ... cut ... ] debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Ubuntu-5ubuntu1.4 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1 debug1: match: OpenSSH_5.1 pat OpenSSH_5* compat 0x0c000000 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr umac-64@openssh.com none debug1: kex: client->server aes128-ctr umac-64@openssh.com none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP 

и через некоторое время:

 Connection closed by 123.45.67.89 

Маршрут настроен так же, как при подключенном USB-модемом, а iptables пуст. Почему это не работает, и что мне нужно сделать, чтобы заставить его работать?

  • Невозможно изменить битрейт на адаптере wifi
  • Что заставляет SSH прекратить работу по проводному соединению, когда я подключаю беспроводную карту USB?
  • Беспроводной интерфейс доступен только при подключении кабеля Ethernet
  • В Archlinux он имеет действительный ip, но соединение не может быть установлено
  • Операция невозможна из-за RF-Kill
  • Debian 8 (Jessie): невозможно подключиться к WIFI после обновления
  • восстановление ядра без использования apt-get
  • Где Linux хранит журналы сетей Wi-Fi при поиске? Это вообще?
  • One Solution collect form web for “SSH через VPN через Wi-Fi Hotspot не работает”

    Максимальный размер блока передачи (MTU) в идеале должен быть одинаковым на точке доступа и клиенте, но клиент должен быть не более, чем размер точки доступа.

    Уменьшите размер MTU туннельного устройства клиента, например:

     $ ip addr show dev tun0 6: tun0: <POINTTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1412 qdisc pfifo_fast state UNKNOWN group default qlen 500 

    Таким образом, размер MTU составляет 1412 байтов. Понижение бит:

     $ ip link set tun0 mtu 1000 

    и voilà, ssh работает тоже.

    Попытка сделать это изменение постоянным должна выполняться индивидуально.


    Эта проблема изложена в Википедии :

    Разница между MTU, наблюдаемым конечными узлами (например, 1500) и MTU пути, приводит к введению Path MTU Discovery в действие, что может привести к невозможности доступа некоторых сайтов к плохо сконфигурированным брандмауэрам.

    Спасибо @Jakuje за это.

    Linux и Unix - лучшая ОС в мире.