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



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

    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"

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

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



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



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

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

    но попробовал все-таки7810789a-d6db-4d2e-921b-b3f8f22547b3-image.png

    не помогло



  • @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 уменьшить.



  • я же писал что пинги (пакеты) то в принципе ходят, но фрагментация на уровне 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?

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



  • @forumlike

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

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



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



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

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



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

    a5602f1b-7263-45f9-b2ed-e92abca6cbe8-image.png

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

    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
    и тогда супер



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



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


Log in to reply