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

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

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

  • Нет вывода из команды, выполненной поверх ssh на SUSE с помощью openBSD sshd
  • Как я могу узнать, какую версию OS X я запускаю из командной строки?
  • Как добавить ключ без фразы в ssh-агент?
  • Wi-Fi работает на местном, без подключения к Интернету. Дебайн 7
  • ssh на сервер с использованием .ssh / config alias и запускать псевдоним на сервере в одно и то же время
  • Переключитесь на указанную сеть Wi-Fi через bash на Mac
  • Если, однако, я подключаюсь к Интернету через точку доступа 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 пуст. Почему это не работает, и что мне нужно сделать, чтобы заставить его работать?

  • Отключить аутентификацию SSH-пароля на определенном интерфейсе
  • Пересылка IP через туннель ssh
  • Два сетевых адаптера с DHCP, используйте один в качестве резервного
  • Можно ли удалить «ssh: //» из URL-адресов git remote?
  • Как я могу запустить startx и запустить сценарий удаленно через SSH?
  • как избежать разрешения ssh?
  • 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 - лучшая ОС в мире.