Фон

У меня есть сервер VPN, работающий на draytek модеме.

Если я соединяюсь через модем с мобильного телефона Android, все хорошо работает.

Принимая во внимание, что, если я соединяюсь от NetworkManager с помощью pptp, он работает некоторое время:

• Соединение в порядке
• Я могу использовать ssh для соединения с машиной в другом конце ссылки pptp
• Я могу 'ls' и получать ответ OK
• Однако, когда я 'ls - la' (генерация большего ответа), замораживания соединения
• Кроме того, любой сеанс HTTP, который имеет изображения на странице также, замораживается

Диагноз

Питание с MTU

Мне удалось получить эту работу хорошо путем корректировки MTU в удаленном конце, т.е.:

• Подключение VPN - хорошо
• Проверьте MTU в местном конце с ifconfig (это - 1400),
• ssh к машине в другом конце ссылки pptp
• проверьте MTU в удаленном конце с ifconfig (это - 1500),
• Скорректируйте MTU в удаленном конце к 1300 (ifconfig eth0 mtu 1300)
• ls - la (и все остальное) хорошо работает

К сожалению, я не могу пойти о корректировке MTU никаких других машин, с которыми я могу соединиться по VPN (например, Google).

Wireshark

Я также использовал wireshark для получения транзакций, и он похож на одну из последних вещей, которая сделана, прежде чем соединение замораживается, должен отправить [Обновление Окна TCP] от клиента к другому концу (в этом случае... 192.168.11.200).

Ping

Я вошел в удаленную машину через VPN.

MTU этой машины на ppp0 является 1400 (как установлено установлением связи VPN в Администраторе сети). MTU удаленной машины на eth0 является 1500.

Я затем проверил с помощью ping-запросов эту машину от удаленного конца следующим образом и нашел, что любой пакет ping, больше, чем 1336, отбрасывается:

steve@remote:~$ ping -M do -c 1 -s 1336 192.168.11.105
PING 192.168.11.105 (192.168.11.105) 1336(1364) bytes of data.
1344 bytes from 192.168.11.105: icmp_seq=1 ttl=63 time=72.1 ms

--- 192.168.11.105 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 72.131/72.131/72.131/0.000 ms


steve@remote:~$ ping -M do -c 1 -s 1337 192.168.11.105
PING 192.168.11.105 (192.168.11.105) 1337(1365) bytes of data.

--- 192.168.11.105 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Маршрут IP

Отметьте уверенный, если это полезный, но вот является выводом "IP маршрута" показ, что состояние по умолчанию соединений... - там что-то не так здесь?

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
    link/ether 1c:4d:70:db:5f:ba brd ff:ff:ff:ff:ff:ff
13: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 3

Справка...

Я подозреваю, что это - что-то, чтобы сделать с согласованием размера пакета, которое не работает - я вполне уверен, это не часть конфигурирования модема, потому что все это хорошо работает от клиента Android, таким образом, все указывает клиенту Ubuntu.

Q: Кто-либо получил какие-либо указатели или идеи?

Q: Кто-либо знает, какая программа / часть Ubuntu ответственна за управление и согласование размеров пакета TCP для отдельного соединения TCP?

Q: Кто-либо знает, почему с MTU 1400 в одном конце и MTU 1500 с другой стороны, был бы максимальный размер пакета позволенного 1336 - что является настолько особенным приблизительно в 1336?

Q: Я ожидал, что ответ на ping будет иметь 'фрагментацию требуемое' сообщение с ними. У кого-либо есть какая-либо идея, что могло останавливать это сообщение?

версия pptp: 1.9.0 или 1.10.0

Steve