PPTP out-of-order пакеты от провайдера не проникают на pptp интерфейс

forumlike

здравствуйте, наблюдаю интересную проблему

pfsense создает интернет подключение через pptp провайдера, при подключении приходит mru 1436 которое становится mtu 1436 на pptp0 интерфейсе

пингую пакетами size > mtu: ping -s 2000 ya.ru

request'ы разбиваются на пары 1486 и 662 байта
а reply'и возвращаются тремя пакетами: 1486 134 и 598

но в чем проблема! если reply возвращаются не в исходном порядке - обычно 2-1-3, то icmp reply уже не dump'ятся на pptp интерфейсе и ping пишет "packet loss"

я так понимаю полученные обратно фрэймы как бы не "проходят вверх по стеку" и в итоге чуть-чуть не доходят до финиша

а виртуалки с другими операционками вполне переваривают такой "непорядок"

werter

@forumlike
У пф в настройках есть про DF bit. Покрутите ее.

forumlike

DF бит насколько я понимают это не дропать фрагментированные пакеты с DF битом.

у меня пинги отправляются и возвращаются без DF бита, так что не вижу перспективы в этом направлении.

но попробовал все-таки

не помогло

werter

@forumlike

http://netwild.ru/pptp/

MTU
Не менее важный вопрос для протокола — это вопрос MTU.
Так как PPTP — это полезная нагрузка + заголовок PPP+ GRE + заголовок IP. MTU Ethernet = 1500 байт, header IP = 20 байт, GRE = 4 байта. 1500-20-4 = 1476 байт.

Что говорит ping -f -l 1476 -t <ip-addr> на Win? И уменьшайте размер до момента прохождения пакета.
Может на одном из концов туннеля у провайдера иной размер mtu?
Вроде ж у пф есть возможность уменьшить MTU на pptp-интерфейсе. Попробуйте до 1300 уменьшить.

forumlike

я же писал что пинги (пакеты) то в принципе ходят, но фрагментация на уровне GRE не позволяет им "появиться" на PPTP

может это по моей проблеме?:

Представим себе, что недалеко от точки приёма такого трафика возникают неподконтрольные нам перестановки пакетов - то есть, все пакеты доставляются без потерь, но очень часто соседние пакеты приходят переставленными местами .............. И даже если использовать PPP-туннель без шифрования/компрессии, мы получаем огромный процент потерь внутри туннеля, потому что GRE вынужден дропать "опоздавшие" фреймы PPP, так как не имеет права доставлять их с нарушением порядка (дропать - имеет право).

Но если обучить GRE восстанавливать порядок пакетов, то PPP/MPPE даже и не узнают, что были проблемы с доставкой (пока не начнутся настоящие потери). Для ноды ng_pptpgre(4), которую использует mpd при создании PPtP-туннелей, сделал патч. Update 07.09.2016: обновление (information text)

Патч даёт возможность управлять глубиной очереди ожидания переупорядоченных пакетов через sysctl net.graph.pptpgre.reorder_max (ноль отключает восстановление порядка) и таймаутом ожидания "опоздавших" пакетов (в милисекундах) через net.graph.pptpgre.reorder_timeout. Тесты показали хороший результат при reorder_max=16 и таймаутом в 1ms, когда точка переупорядочивания близко к нам и в 50ms, если далеко. Изменять значения этих параметров можно "на лету", без переустановки туннелей. В итоге CCP даже не дергается, если низлежащий GRE успешно восстанавливает порядок.

взято отсюда https://dadv.livejournal.com/tag/pptpgre

там сказано что есть патч для ng_pptpgre.ko но в итоге придется пересобирать ядро, так вообще делают с pfSense?

что же делать?

werter

@forumlike

Сменить провайдера.
Узнать у провайдера о др. типах подключения.

Не надо велосипедить.

Konstanti

@forumlike
Здр
Если проблема именно в том , что Вы описали
Возможно стоит дождаться версии PF 2.4.5 , насколько вижу , в этой версии этот патч уже присутствует.
Или пойти по пути , который советует Werter

werter

@forumlike
Или пользовать 2.4.5 не дожидаясь релиза )

@Konstanti
https://redmine.pfsense.org/projects/pfsense/roadmap ничего по pptp нет и по ppp не вижу (
Нашел из похожего только https://redmine.pfsense.org/issues/10222
Можно ссылку?

forumlike

2.4.5-RC - проблема исчезла! радости нет предела

добавили вышеназванный патч
параметры на скрине

net.graph.pptpgre.reorder_timeout: 1
net.graph.pptpgre.reorder_max: 1

ради любопытства сделал
sysctl -w net.graph.pptpgre.reorder_max=0
и получил те самые 100.0% packet loss

sysctl -w net.graph.pptpgre.reorder_max=1
и тогда супер

Konstanti

@werter
Ссылки на официальные доки нет
Есть ссылка на исходники freebsd , собственно там все и было найдено

werter

@Konstanti
Принял, спасибо.