From: Vyacheslav Khudyakov <slava@in4net.info.>
Newsgroups: email
Date: Mon, 14 Mar 2007 14:31:37 +0000 (UTC)
Subject: О PPPoE, MTU и проблеме Path MTU Discovery Black Hole
Предыстория
Приехав как-то домой, я вдруг обнаружил что некоторые сайты с моего
ноутбука перестали зугружаться. Причем, на следующий день, ноутбук был
проверен на работе -- интернет работал и сайты открывались
замечательно, все было доступно. Дома же -- только www.yandex.ru и
www.google.com. Да и то, начиная с некоторого момента, зугружаться
стал только гугл. Причем, веб-сайты отлично пинговались, до них
доходил трейс и даже устанавливалось соединение с помощью telnet на
80-й порт...
Теперь немного о том, как я соединен с инетом. У меня дома небольшая
локальная сеть, к которой подключены по wifi ноут и стационарная
машина на которой работает отец. Шлюзом выступает linux сервер,
который соединен с провайдером по PPPoE. По сути, такой же способ
доступа в интернет, через PPPoE, предлагают все dsl провайдеры (Стрим
и пр.). Сначала я был весьма наивен. И погрешил на винду,
переустановив ее с диска-реаниматора...
Не помогло. Загрузился на ноуте под линукс - те же яйца, вид сбоку.
При этом, что интересно, на самом шлюзе все сайты замечательнейшим
образом открывались...
Сама история
Надо сказать, что первая же мысль после этого была - посмотреть что
там с MTU. Что я и сделал, введя ifconfig на шлюзе:
Как видим, ppp0 соединение имеет MTU 1492. Что по сути это означает?
Проще говоря, ваше соединение с интернет имеет окно в 1492 байт (MTU -
Maximim Transmission Unit) - это наибольший пакет, который ваша машина
может передать по данному соединению. В тоже время, почти все веб и
ftp серверы соединены с интернет с MTU 1500.
Если где-нибудь на пути пакета от одного хоста к другому выяснится,
что он не умещается в MTU следующего участка, то роутер будет
фрагментировать данный пакет. Так произошло бы, если бы роутеры не
использовали технологию Path MTU Discovery :-) .
Поскольку фрагментация пакетов сильно снижает производительность
роутеров, то в 1988 году была предложена технология Path MTU Discoverу
(PMTUD). Она описана в RFC 1191. Суть технологии состоит в том, что
когда два хоста соединяются друг с другом, то устанавливается DF бит
"Dont Fragmen"), который запрещает фрагментацию пакетов на роутерах.
Это заставляет роутер, который собирается перенаправить пакет через
соединение с MTU меньше размера пакета, отбрасывать пакеты и
отправлять хосту-отправителю сообщение типа ICMP 3:4. Данное сообщение
типа "Destination is unreachable" означает "Хост недоступен, поскольку
пакет слишком большой и роутер не будет его фрагментировать". В
добавлении к данному сообщению, при применении PMTUD, прилагается
размер MTU нижестоящего за роутером участка. Таким образом,
хост-отправитель, после получения ICMP 3:4 с информацией от PMTUD,
уменьшает размер отправляемого пакета и пересылает его заново. Как
итог -- пакеты доходят до хоста-получателя без фрагментации.
Все операционные системы с 1988 года поддерживают технологию PMTUD.
Однако, проблема может быть в том, что либо вышестоящий над вашим
соединением роутер, либо некий роутер между вами и удаленным сервером,
либо сам удаленный веб-сервер могут БЛОКИРОВАТЬ некоторые типы ICMP
пакетов, включая ICMP 3:4. В этом месте хочется передать привет
параноидальным администраторам -- НЕ ДЕЛАЙТЕ ТАК, НЕ БЛОКИРУЙТЕ ICMP
трафик! Как итог - соединение между хостами устанавливается, но пакеты
от одного хоста к другому не доставляются, отбрасяваясь где-то по
пути... Похоже на наши симптомы?
Собственно проблема не нова, ее начали обсуждать еще в 1998 году.
Называется она Path MTU Discovery Black Hole, и описана в RFC 2923.
По сути, потенциально этой проблеме подвержено любой PPPoE соединение,
поскольку его MTU меньше типового MTU в 1500 байт и, для прохождение
через PPPoE, TCP/IP пакет необходимо либо фрагментировать, либо
использовать PMTUD.
В тоже время, если у вас обыкновенная машина с DSL модемом, вы не
столкнетесь с этой проблемой, поскольку на этапе инициализации
соединения с удаленными серверами размер пакета будет вычислен исходя
из размера MTU PPPoE соединения.
Однако, если у вас DSL роутер (например как у меня, на базе линукса),
то вы в зоне риска, поскольку ваша машина, при установлении соединения
с удаленными серверами, по умолчанию оперирует размером пакета исходя
из MTU локальной сети, которое установлено в 1500. В тоже время,
пакеты от удаленных серверов к вам проходят через канал роутера,
который имеет MTU PPPoE соединения, т.е. 1492...
Решение проблемы
Самый простой и логичный способ - снятие фильтрации ICMP 3:4, как
правило, находится вне вашей компетенции. Поэтому решить проблему
можно следующим способом: автоматически уменьшать размер передаваемого
пакета на вашем шлюзе, либо с помошью pppd, либо с помощью iptables.
При установке TCP-соединения сервер и клиент сообщают друг другу так
называемый максимальный размер сегмента (MSS), который каждый из них
сможет принять (по умолчанию на 40 байт меньше mtu интерфейса -- размер
заголовков ip+tcp). И далее каждый из них в рамках этого tcp-соединения
посылает пакеты размером не более чем min(mss+[размер заголовков], pmtu).
Мы меняем MSS, заставляя обе стороны посылать друг другу tcp-пакеты
только таких размеров, которые заведомо пролезут в наш интерфейс
без фрагментации.
Для iptables есть и модуль снятия бита DF, в случае с ним шлюз бы
фрагментировал пакеты... В случае с корректировкой MSS
фрагментация просто не требуется, что является более изящным решением.
Идентификация проблемы и поиск решения у меня занял около 6 часов, в
ходе которых я анализировал пакеты с помощью tcpdump и netstat,
выискивал закономерность между открывающимися не открывавшимися
сайтами, конфигурировал ядро сервера, перестанавливал операционку на
ноуте и задумывался уже над тем чтобы плюнуть и поставить просто
прокси-сервер... Проблема усугублялась еще и тем, что интернет мне,
фактически, был недоступен.... Хотя решение, на самом деле, очень
простое.
Vova
