Краткое описание: Я подключен к Inte rnet через модем Draytek xDSL без проблем. Но когда я включаю свое соединение VPN L2TP и устанавливаю его в качестве шлюза по умолчанию, все конечные точки моей сети (будь то Linux, Win, смартфоны) могут загружать только очень немногие сайты, такие как мой банк, некоторые сайты в Великобритании и сайты Google, такие как Youtube и такие сервисы, как Gmail. Тем не менее, все другие веб-сайты (включая чат-серверы, такие как Skype) либо находились в тайм-ауте с сообщениями об ошибках, не являющимися признаками. Такое поведение сводило меня с ума!
Устранение неполадок: Поскольку симптомы в разных ОС / устройствах одинаковы, я сосредоточился на своей сети, в частности на модеме Draytek. Сначала я проверил таблицу маршрутизации на модеме, чтобы проверить, не испортился ли туннель L2TP, но все выглядело нормально. Затем я потратил около 12 часов на устранение неполадок в различных сетевых аспектах (огромный список, который следует упомянуть в такой короткой записи), но все же я не смог определить причину root. Перед сном я отправил сообщение провайдеру VPN, который подтвердил мне, что это не из их собственной сети.
На следующий день подумал, может ли это быть ошибкой прошивки? Итак, понизил и обновил его до десятков различных версий ... все равно не повезло! Затем я проверил значение MTU моего интерфейса ADSL WAN, и оно было установлено на 1492 (по умолчанию для большинства PPPoE). Я подтвердил правильность значения, введя следующую команду из поля Linux:
ping -c 4 -s 1464 -M do <vpn server>
Хмм…. Что может быть причиной? Я проверил бит DF модема (не фрагментировать) моего модема, и он был выключен Итак, я пошел вперед и включил его, до сих пор не повезло! На этом этапе я бился головой о стену;). Итак, я решил настроить L2TP-соединение на моем Linux и подключиться напрямую к VPN-серверу. Странно, все работало без сбоев! В этот момент я был почти уверен, что модем Draytek - это суть проблемы.
Итак, я запустил сетевой сниффер и собрал несколько пакетов HTTP / TCP на созданном туннельном интерфейсе ppp0 (который находится на Linux), чтобы посмотреть, что происходит. Я заметил, что мой Linux объявлял MSS (максимальный размер сегмента) 1160 на веб-сервере, а не 1460, когда я подключался к VPN через мой модем. Поскольку MTU для ppp0 составляет 1200 (стандарт для L2TP), то логически MSS составляет 1160 (MTU - 40 = MTU). Чтобы имитировать c правильные значения интерфейса PPP0 (MTU и MSS), я настроил свой MTU интерфейса Ethe rnet на 1200, чтобы он объявлял 1160 при инициализации пакета TCP SYN. Чтобы проверить это, я отключил свое прямое VPN-соединение через Linux и снова подключил свой модем к VPN-серверу (помните, что это мой шлюз по умолчанию). Я проверил мой обновленный MTU, выполнив форму Linux:
~ $ ping -c 4 -s 1174 -M do 104.26.13.39
PING 104.26.13.39 (104.26.13.39) 1174(1202) bytes of data.
ping: local error: Message too long, mtu=1200
--- 104.26.13.39 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1023ms
~ $ ping -c 4 -s 1172 -M do 104.26.13.39
PING 104.26.13.39 (104.26.13.39) 1172(1200) bytes of data.
1180 bytes from 104.26.13.39: icmp_seq=1 ttl=59 time=115 ms
--- 104.26.13.39 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
После проверки MTU я снова прослушал некоторые пакеты HTTP / TCP, и действительно объявленный MSS был 1160. Но угадайте, что? Я все еще не мог просмотреть почти все сайты Inte rnet! Я говорил себе, что еще может быть причиной ?! Хотя я правильно установил значения MTU и MSS на сетевом интерфейсе моего Linux (и проверил его с помощью сниффера), никаких изменений не произошло! В этот момент я решил перейти к самому модему и промежуточным переходам и исследовать его…
Сначала я проверил, позволяет ли мой модем устанавливать MTU интерфейса туннеля (не интерфейса PPPoE), и, к сожалению, нет Вариант CLI для этого - я даже не мог просмотреть установленное значение. Затем я проверил значение MSS и обнаружил, что оно установлено на 1360! ЧТО! Я спросил себя: как, черт возьми, модем может вместить 1360 байт в 1200 единиц MTU ?! Может ли это быть решением моего двухдневного поиска неисправностей? Я установил MSS модема на стандартное значение 1160 (и которое мы наблюдали ранее в захваченных пакетах), и все работало безупречно !!! Woohoo! Я почти собирался сдаться и купить новый модем для другого производителя.
Вопрос: почему он не работал раньше, когда я правильно установил MSS и MTU в моем Linux? Это должно работать, верно? Согласно инструкции, модем рекламировал другое значение MSS для другого конца! Другими словами, когда я рекламировал в пакете TCP SYN веб-серверу, что мой предпочтительный MSS - 1160, мой любимый модем перезаписывал это значение 1360! Это заставило сайт поверить моему модему и ответить большими TCP-сегментами, которые не укладываются в конверт 1200 MTU и, следовательно, были отброшены. В соединениях не-VPN MSS 1360 (установленный Draytek и многими другими производителями) может работать безупречно. Но как только мы добавим накладные расходы на инкапсуляцию и шифрование, это израсходует некоторое пространство от размера MTU, следовательно, заставит нас уменьшить MSS, чтобы не отбрасывать пакеты.
Хотя я не мог просмотреть значение MTU туннельного интерфейса на Draytek, это 1400 в соответствии со стандартным правилом: 1400 - 40 = 1360. Однако я надеялся, что есть какой-то путь от CLI / Web к Измени это.
Примечание для владельцев Draytek: если вы столкнулись с такой проблемой, исправьте значение MSS для других устаревших протоколов, таких как PPTP и L2TP через IPse c. Например, я использую L2TP, поэтому я исправил его MSS следующим образом:
modem> vpn mss set 2 1160
% VPN TCP maximum segment size (MSS) :
PPTP = 1360
L2TP = 1160 <------------------------------------------------ corrected
IPsec = 1360
L2TP over IPsec = 1360
GRE over IPsec = 1360
SSL Tunnel = 1360
Все еще без ответа вопрос: Почему вы думаете, когда я включил бит DF, все еще не работало ? Это потому, что DF разбивает выходные пакеты и, следовательно, портит инкапсуляцию протокола VPN? Или устаревший L2TP не настолько умен, как IPSe c IKE, чтобы справляться с фрагментацией? Может кто-нибудь поделиться своим анализом?