1.0Чудо{вищные} заметкиhttps://miracle.rpz.nameMiRacLehttps://miracle.rpz.name/author/miracle/Третий раз трачу значительное время на диагностику и устранение проблемы с "туннелем в туннеле". Чтобы избежать рецидива оставляю себе заметку о том, что забытый ныне <abbr title="Maximum transmission unit">MTU</abbr> всё ещё требует ручной настройки в "нетрадиционных" сетевых конфигурациях. <img src="//miracle.rpz.name/shared/2015/mtu-win98.gif" alt="Windows 98. General PPP settings" width="250" align="right" />Старожилы помнят множество способов изменить MTU подключения в музейных версиях популярных когда-то операционных систем. В современных версиях этих популярных систем найти нужное окошко мне не удалось (от чего и делаю вывод о том, что в широких кругах больше не требуется "work around a problem with your ISP"). Имеется в наличии провайдер для доступа в интернет использующий VPN (L2TP) и с этим в общем и целом проблем нет - любому дешёвому роутеру это по плечу. Есть необходимость подключаться сквозь провайдерский туннель к удалённой сети. И с этим клиентские ПК тоже с лёгкостью справляются. Вроде бы. Ну по крайней мере должны были справляться. Ну подключились же без проблем... Проблема проявлялась в "мелочах" - время от времени некоторые ресурсы внутренней VPN-сети не отвечали на поставленные "вопросы", что конечно раздражало, но не казалось критичным и мнилось проблемой в сетевых настройках целевых ресурсов. <!--more-->Имеется возможность подключится по SSH/RDP к удалённой машине, для которой "проблемные" ресурсы локальны и доступны всегда. Но однажды проблема проявилась в "полный рост" - работая над исправлением <a href="https://github.com/php/php-src/pull/1386">бага в библиотеке для работы с базой данных в php</a> столкнулся с "Database error" там где его быть не могло. Многочасовая отладка, откат сделанных изменений - ошибку устранить не удаётся. Неприятное удивление пришло в тот момент, когда проблемный код был запущен с проверенным боем и временем расширением <a href="http://php.net/mssql">mssql</a> и завершился той же ошибкой. Дальше проблема довольно быстро была локализована - был проверен sql-запрос - на целевом сервере он ожидаемо работал, было проверено безошибочное выполнение php-кода с машины в локальной сети sql-сервера, выполнение sql-запроса без участия php (tsql) с той же ошибкой . Ну и далее анализ tdsdump-а дал искомый ответ - из-за сетевых проблем freetds-клиент делал попытку получить ответ от сервера снова и снова, по достижению mssql.timeout php завершал запрос и выбрасывал ту самую "невнятную" ошибку работы с базой данных. <img src="//miracle.rpz.name/shared/2015/drtcp.gif" alt="DrTCP" width="210" align="left" hspace="10" />Сетевая проблема, как не трудно догадаться из названия заметки, заключалась в MTU - пакеты размером в mtu локального интерфейса оборачиваются в пакеты размером в mtu интерфейса роутера, при одинаковых размерах mtu и пакетах данных с размером близким к максимальному начинаются ошибки передачи данных. Решение тоже очевидно - максимальный размер пакета "внутреннего" туннеля должен быть меньше максимального размера пакета в туннеле к провайдеру. Цель этой заметки - напомнить о том, что есть параметр <code>mtu 1200</code> в <a href="https://ppp.samba.org/pppd.html">pppd.conf</a>. И это было просто. Теперь о главном: в <em>другой</em> операционной системе это делается иначе - ищем внешний интерфейс: <pre>netsh interface ipv4 show subinterfaces </pre> меняем ему mtu: <pre>netsh interface ipv4 set subinterface "Free wi-fi from the neighbors" mtu=1200 store=persistent </pre>rich