Третий раз трачу значительное время на диагностику и устранение проблемы с “туннелем в туннеле”. Чтобы избежать рецидива оставляю себе заметку о том, что забытый ныне MTU всё ещё требует ручной настройки в “нетрадиционных” сетевых конфигурациях.
Старожилы помнят множество способов изменить MTU подключения в музейных версиях популярных когда-то операционных систем. В современных версиях этих популярных систем найти нужное окошко мне не удалось (от чего и делаю вывод о том, что в широких кругах больше не требуется “work around a problem with your ISP”).
Имеется в наличии провайдер для доступа в интернет использующий VPN (L2TP) и с этим в общем и целом проблем нет – любому дешёвому роутеру это по плечу. Есть необходимость подключаться сквозь провайдерский туннель к удалённой сети. И с этим клиентские ПК тоже с лёгкостью справляются. Вроде бы. Ну по крайней мере должны были справляться. Ну подключились же без проблем…
Проблема проявлялась в “мелочах” – время от времени некоторые ресурсы внутренней VPN-сети не отвечали на поставленные “вопросы”, что конечно раздражало, но не казалось критичным и мнилось проблемой в сетевых настройках целевых ресурсов. Имеется возможность подключится по SSH/RDP к удалённой машине, для которой “проблемные” ресурсы локальны и доступны всегда. Но однажды проблема проявилась в “полный рост” – работая над исправлением бага в библиотеке для работы с базой данных в php столкнулся с “Database error” там где его быть не могло. Многочасовая отладка, откат сделанных изменений – ошибку устранить не удаётся. Неприятное удивление пришло в тот момент, когда проблемный код был запущен с проверенным боем и временем расширением mssql и завершился той же ошибкой. Дальше проблема довольно быстро была локализована – был проверен sql-запрос – на целевом сервере он ожидаемо работал, было проверено безошибочное выполнение php-кода с машины в локальной сети sql-сервера, выполнение sql-запроса без участия php (tsql) с той же ошибкой . Ну и далее анализ tdsdump-а дал искомый ответ – из-за сетевых проблем freetds-клиент делал попытку получить ответ от сервера снова и снова, по достижению mssql.timeout php завершал запрос и выбрасывал ту самую “невнятную” ошибку работы с базой данных.
Сетевая проблема, как не трудно догадаться из названия заметки, заключалась в MTU – пакеты размером в mtu локального интерфейса оборачиваются в пакеты размером в mtu интерфейса роутера, при одинаковых размерах mtu и пакетах данных с размером близким к максимальному начинаются ошибки передачи данных. Решение тоже очевидно – максимальный размер пакета “внутреннего” туннеля должен быть меньше максимального размера пакета в туннеле к провайдеру.
Цель этой заметки – напомнить о том, что есть параметр mtu 1200 в pppd.conf.
И это было просто. Теперь о главном: в другой операционной системе это делается иначе –
ищем внешний интерфейс:
netsh interface ipv4 show subinterfaces
меняем ему mtu:
netsh interface ipv4 set subinterface "Free wi-fi from the neighbors" mtu=1200 store=persistent