эти конкретные признаки (с VPN) являются довольно распространенными симптомами, указывающими на проблему с MTU пути.
основы MTU
MTU пути (максимальный блок передачи) является самым большим пакетом, который может пересечь между двумя устройствами в интернете (или любой другой сети). Каждая ссылка вдоль пути имеет свой собственный MTU, который может или не может совпасть с другими. Общий MTU пути является самым низким MTU вдоль всего пути.
Если ваш компьютер пытается отправить пакет больше, чем MTU пути, пакет данных отбрасывается на прыжке, который он превышает, и данные никогда не будут поступать. В хорошо функционирующих сетях ваш компьютер должен получить ответ об ошибке и знать, чтобы автоматически настроить MTU вниз и / или фрагментировать последующие пакеты. В плохо функционирующих сетях это может быть просто отброшено тихо.
путь MTU (auto)discovery механизм используемый автоматически для того чтобы обнаружить MTU между вами и сервером VPN, однако он более надежен с TCP, чем с UDP в плохо функционирующих сетях, потому что TCP требует явной обратной связи, которая может сказать вам, какие пакеты не поступают.
причина, по которой он действует так же, как с VPN-ссылками, заключается в том, что заголовки инкапсуляции VPN уменьшают MTU туннельного соединения и потому, что UDP не предоставляет обратной связи по отброшенным пакетам.
если ваш реальный PMTU, например, 1400 байт, отправка пакета 1400 байт через VPN может занять 1432 байта. По TCP-соединению, если вы попытаетесь отправить 1432 байта пакета, TCP может сказать он не приедет и фрагменты его и передает его снова как байтных пакетов 1400 и второй 32 байт (это грубое упрощение, тем не менее). С UDP он просто падает молча. Однако, в и случаи, отправка любого пакета меньше, чем 1400 байт будет успешным.
вот почему SSH и telnet работают, а просмотр веб-страниц нет. VPN уменьшил MTU ниже вашего значения по умолчанию, но ваша ОС не поняла ни потому, что сообщения об ошибках не возвращаются должным образом, ни PMTU autodiscovery не работает. Но поскольку SSH, telnet и ping используют очень маленькие пакеты (обычно <100 байт), если MTU был уменьшен с 1400 до 1368 (1400-32), это не имеет значения, поскольку они все еще намного меньше предела. SSH и telnet обычно передают между одним байтом и одной строкой за один раз, плюс заголовки пакета. Пинг пакеты обычно до 64 байт плюс заголовки пакетов, опять же намного меньше, чем любой здравомыслящий MTU (1400+)
просмотр веб-страниц первоначально подключается, потому что DNS, TCP SYN / ACK пакеты и HTTP-запросы, как правило, гораздо меньше, чем 1400 байт, но как только веб-сайт пытается отправить фактическую веб-страницу, он будет использовать полноразмерные пакеты, которые затем получить молча отбрасываются по пути.
решение проблемы
есть легкий (обманчивый) путь, и другой путь, который включает в себя выяснение, в чем проблема на самом деле.
мошеннический способ заключается в том, чтобы установить MTU намного ниже вручную - например, до 1000, поэтому все будет вписываться даже в уменьшенный MTU VPN. Это само по себе является хорошим тестом, чтобы видеть, является ли MTU проблемой.
лучший способ-выяснить, в чем проблема, и исправить ее. Проблемы автообнаружения MTU могут возникнуть из-за дрянного сервера или интернет-провайдера, о котором вы ничего не можете сделать или локальный брандмауэр/проблемы конфигурации, которые можно исправить. Это может быть маршрутизация OpenVPN, а правила брандмауэра не позволяют сообщениям об ошибках ICMP возвращаться на ваш компьютер.
промежуточный метод должен был бы выяснить истинный максимальный MTU и установить это вручную-вы можете начать с чего-то маленького как 1000 байтов и работать вверх, чтобы найти самое высокое значение, которое работает. В принципе, подключите VPN с помощью UDP, а затем пропингуйте что-то через VPN с помощью команды ping -f <server address> -l <packet size> и увеличить размер пакета вверх, пока он не перестанет работать - либо с таймаутом, либо с ошибкой.
Komp
2960
