PPTP over PPPoE в mpd 5

[Dimka]

Есть FreeBSD 7.1, на ней крутится mpd 5, устанавливающий PPPoE соединение к провайдеру.

Захотел я устроить VPN и для этого в mpd настроил PPTP-сервер с опциями, позволяющими подключаться Windows-клиентам.

Теперь наблюдаю странные и непонятные явления.

Если подключаться к PPTP-серверу изнутри локальной сети, то всё замечательно.

Если подключаться к нему же из внешней сети через PPPoE-соединение (и другой интерфейс, обслуживаемый mpd), то всё дохнет. С точки зрения Windows-клиента соединение устанавливается нормально, проходит авториация, поднимается сетевой интерфейс и на этом всё затыкается - спустя некоторое время Windows обнаруживает, что интерфейс на самом деле дохлый, и сообщает об этом, предлагая переподключиться. С точки зрения сервера mpd, кажется, беззвучно помирает - так, что даже в логах не оставляет никакого описания того, что с ним произошло.

Поглядеть на происходящее непосредственно на FreeBSD я пока не могу - надо тащить другую машину, ставить рядом, выводить в интернет через альтернативный канал. Когда соберусь всё это сделать - точно не знаю. Удалённо тоже поглядеть не могу, поскольку падение mpd приводит к обрыву ssh-сессии.

Никто случайно с таким не сталкивался? Почему это происходит, и как это поправить?

P.S. Вариант с перебросом не в тот туннель default-маршрута отпадает. Запретил все операции с маршрутами на сервере и клиенте, вбил статически маршруты на нужные адреса и интерфейсы. Ну и в таком случае mpd, думаю, в логах бы написал об обрыве PPPoE из-за отсутствия отклика удалённой стороны. Но не пишет ничего.

[RXL]

Дим, надо смотреть MTU этих каналов. PPtP на стадии авторизации использует TCP, а потом, в качестве транспорта, использует GRE (-40 байт от MTU).

Комбинированием PPPoE и PPtP не занимался, но с транзитом трафика через GRE боролся. Возможна трудность работы PMTU discovery и надо найти способ ограничить TCP MSS (до MTU -60 байт) на стадии TCP handshake.

Пример. У меня fast ethernet до провайдера - MTU 1500. Поверх идет IP+GRE - MTU 1460. Максимальный MSS - 1440.

[Sla]

если падает ssh, то все эксперименты проводить в screen

[RXL]

В теории, если крайние хосты поддерживаю PMTU discovery и никто из хостов в цепи не отфильтровывает ICMP, то проблема должна рассосаться автоматически.

[Dimka]

Пример. У меня fast ethernet до провайдера - MTU 1500. Поверх идет IP+GRE - MTU 1460. Максимальный MSS - 1440.

Ага, у меня стояло MTU 1460 в обоих случаях. Опция tcpmssfix включена в обоих случаях. Т.е. если дело в этом, то у PPTP нужно установить MTU 1420 или 1380? IP VPN идёт поверх GRE, который идёт поверх IP, который в туннеле PPPoE идёт поверх IP локальной сети, который идёт поверх Ethernet локальной сети?

По поводу ограничения MSS - это надо думать, читать литературу...

ICMP точно не фильтруется. А что такое PMTU discovery?

[RXL]

Path MTU discovery - "протокол" поиска подходящего размера пакета для данного сокета.
Работает по такому принципу:
1. Хост-источник ставит флаг DF.
2. Роутер, который не может пропустить данный пакет из-за узости MTU, видит флаг DF (don't fragment), отбрасывает пакет и возвращает ICMP сообщение об этом.
3. Хост источник понижает PMTU сокета. Переходим на п.1.

С TCP MSS все просто. В handshake идет обмен допустимым размером MSS (выбирается наименьший). Если роутер подменит MSS, то обе стороны в рамках данного TCP-соединения не будут посылать IP-пакетов длиннее допустимых шлюзом. Но хосты знают только о MTU (и, соотв., MSS) своих непосредственных интерфейсов и ничего не знают о транзитных каналах. Проблема транзита должна решаться через PMTU discovery.

[Dimka]

Но хосты знают только о MTU (и, соотв., MSS) своих непосредственных интерфейсов и ничего не знают о транзитных каналах. Проблема транзита должна решаться через PMTU discovery.

А что, на уровне транспортных протоколов туннеля не выполняется фрагментирование? Или это касается только пакетов с флагом DF?

[RXL]

Да, только пакетов с DF.