Intereting Posts

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 пуст. Почему это не работает, и что мне нужно сделать, чтобы заставить его работать?

Максимальный размер блока передачи (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 за это.