Несогласованность дуплекса на порту VPN-шлюза: читайте оба конца

Копирование файла через туннель замирает на секунду, продолжается, а журналы VPN ничего не показывают. Приложение винит сеть, сеть винит приложение, а порт коммутатора включён уже одиннадцать месяцев. Этот разбор начинается с паузы и идёт наружу, к физическому каналу: что порт делает на самом деле, что делает дальний конец и что делали счётчики, пока вы наблюдали. Это стоит сделать прежде, чем кто-либо тронет настройку дуплекса.

Начните с паузы, а не с порта

Опишите симптом так, чтобы его можно было проверить. Замирание примерно на секунду при массовой передаче — это другая проблема, чем переподключение, а пауза раз в час отличается от той, что случается каждые несколько секунд. Запишите нагрузку, направление и примерный интервал.

Затем воспроизведите это, наблюдая за интерфейсом. Физическая проблема проявляется как движение счётчиков во время затронутой нагрузки, а проблема, которая вообще не двигает счётчики, скорее всего, находится выше канального уровня. Наблюдайте минуту, а не секунду, потому что эти дефекты часто требуют устойчивого трафика, прежде чем проявиться. Наблюдение в простое ничего не доказывает о канале, который ведёт себя плохо только под нагрузкой.

Это важно, потому что у несогласованности дуплекса есть подпись: ошибки появляются только под нагрузкой, по направлению трафика, тогда как небольшие ping и интерактивные сеансы остаются безупречными. Если и трафик в простое отказывает, сначала поищите в другом месте.

Прочитайте рабочий режим на обоих концах

Сохранённая конфигурация — это не рабочее состояние. Порт может быть настроен на автосогласование и оказаться на полудуплексе, либо настроен на фиксированную скорость, с которой другой конец никогда не соглашался. Прочитайте, что канал делает сейчас с обеих сторон.

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

Запишите скорость, дуплекс и включено ли автосогласование, затем получите те же три факта с соседнего коммутатора или порта провайдера. Один конец сам по себе ничего не говорит, потому что несогласованность — это отношение, а не настройка. Поместите обе строки в заявку рядом, с указанием времени, когда вы их прочитали. Половина ценности упражнения в том, чтобы оба показания были в одном месте.

Если вы не можете прочитать дальний конец, вы не можете это диагностировать. Попросите владельца сообщить рабочий режим и счётчики или организуйте доступ, прежде чем менять свою сторону.

Как выглядит случай 10/100 на полудуплексе

На медных линиях 10/100 конец с автосогласованием может определить скорость принудительно заданного партнёра, не узнав его настройку дуплекса. Параллельное обнаружение определяет скорость по сигналу, а дуплекс предполагается, а не согласуется, поэтому одна сторона может остаться на полудуплексе, пока другая работает на полном.

Руководство Cisco по автосогласованию объясняет именно этот случай. Это не аргумент за отключение согласования повсюду, и оно ничего полезного не говорит о гигабитной меди, где дуплекс фиксирован и автосогласование необходимо, чтобы канал вообще поднялся.

Наблюдаемое свидетельство — это смесь ошибок, которые существуют только в одном направлении: ошибки FCS или CRC на стороне полного дуплекса, коллизии или поздние коллизии на стороне полудуплекса и пропускная способность, которая рушится под нагрузкой, тогда как задержка остаётся нормальной в простое. Эта асимметрия и есть подпись. Канал, который просто перегружен, деградирует в обоих направлениях и всё время.

Меняйте оба конца вместе, с путём назад

Исправление дуплекса — это согласованное изменение, а не локальное. Принудительно задать свою сторону без согласия дальнего конца — это способ превратить работающий канал в сломанный, а то, что CLI принимает команду, доказывает лишь корректность синтаксиса.

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

Прежде чем запускать что-либо подобное, убедитесь, что платформа поддерживает такую комбинацию и что дальний конец будет изменён в том же окне. Сохраните независимый способ администрирования устройства, потому что порт, который вы собираетесь менять, может быть тем, который несёт ваш сеанс управления.

На многих современных каналах правильный ответ — оставить автосогласование включённым на обоих концах, а не принудительно что-то задавать. Принуждение — это средство от конкретной несогласованности в конкретной технологии, а не общее улучшение. Именно гигабитной меди нужно автосогласование, чтобы канал поднялся, поэтому совет для 10/100 сюда не переносится.

Убедитесь, что счётчики сдвинулись к лучшему

После изменения снова прочитайте рабочее состояние на обоих концах и убедитесь, что они совпадают. Затем запустите ту же нагрузку, которая вызвала паузу, и сравните приросты счётчиков, а не суммы за всё время, потому что сумма, накапливавшаяся год, не может сказать, что произошло за последние десять минут.

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

Канал без новых ошибок под той же нагрузкой — это доказательство, которого вам не хватало. Канал, который всё ещё ошибается, или тот, где счётчики вообще не двигались, отправляет вас к следующей границе, а не глубже в спор о дуплексе. Любой исход — это прогресс, а это больше того, что может дать файл конфигурации. Не пропускайте второе чтение только потому, что первое выглядело правильным.

Запишите числа до и после в заявку с отметками времени. Именно эта запись превращает «VPN стал работать лучше» в то, на что может опереться следующий инженер.