PPTP у Docker-у се аутентификује, али не преноси саобраћај

Клијент се аутентификује, PPP преговара адресу, а затим се ништа не помера. Ping не успева, прегледач не успева, а контејнер изгледа повезан све време. Овај образац није проблем табеле рутирања, јер проблеми са рутирањем обично покваре и контролну везу. То је пут података, а у PPTP-у су подаци други протокол од оног који је управо успео.

Пет провера, редом који штеди највише времена.

Провера 1: одвојте контролни канал од података

PPTP се аутентификује преко TCP 1723, а затим носи PPP податке унутар GRE-а, IP протокола 47. GRE није ни TCP ни UDP, па свако правило које пропушта контролни порт не говори ништа о њему. NAT или ватрозид који пропушта 1723 може без притужбе одбацити протокол 47, а сесија остаје напола изграђена на начин који изгледа као успех.

Ако пријава ради и ниједан се пакет не враћа, прво претпоставите GRE, а затим то докажите.

Провера 2: потврдите помоћника у језгру хоста

Праћење веза не може повезати TCP контролну везу са GRE током без помоћника. Модул је nf_conntrack_pptp, живи у језгру хоста, а његово учитавање у слици контејнера не постиже ништа јер модули важе за цео хост. lsmod | grep nf_conntrack_pptp на Docker хосту је провера. Ако недостаје, modprobe nf_conntrack_pptp га учитава за језгро које ради и не говори ништа о следећем подизању, па га додајте и у конфигурацију хоста.

Модул који нестане при поновном подизању постаје иста карта следећег месеца.

Провера 3: прочитајте политику језгра која га искључује

Чак и кад је модул присутан, језгра од 4.7 постављају net.netfilter.nf_conntrack_helper подразумевано на 0, што искључује аутоматску доделу помоћника за сваки протокол. Због те подразумеване вредности исправно инсталиран модул ипак не ради ништа: код постоји, а политика каже да се не користи. sysctl net.netfilter.nf_conntrack_helper приказује тренутну вредност, а постављање на 1 током рада поново чини помоћника доступним. Сачувајте вредност кроз sysctl конфигурацију хоста ако дизајн то дозвољава.

Аутоматска додела дозвољава саобраћају да имплицитно ствара очекивања, и управо је зато подразумевана вредност промењена. Ограничите је на поуздани хост или употребите изричито правило усмерено на помоћника.

Провера 4: погледајте пут контејнера одвојено

Учитани помоћник не ствара руту. Контејнеру треба пут до PPTP сервера, а прослеђивање на хосту мора дозволити GRE у оба смера: iptables -L FORWARD -v -n показује да ли је протокол 47 прихваћен и да ли се бројачи померају. Docker masquerade правила преводе TCP и UDP, не протокол 47, па мостни контејнер може захтевати изричито одобрење forward и, на неким хостовима, сопствено правило превода. Проверите и да контејнер има подршку за PPP уређаје коју његова слика очекује.

Читајте бројаче, а не текст правила. Правило које постоји и ни са чим се не поклапа је украс.

Провера 5: докажите да се GRE прати, затим одлучите о PPTP-у

Док клијент ради, прочитајте табелу праћења. Успостављен PPTP контролни запис плус повезани GRE запис значи да помоћник повезује токове и да је преостала грешка другде. Контролни запис без GRE записа значи да се подаци одбацују или не прате, што вас враћа на провере 2 и 3.

Сам PPTP је наследство, а MS-CHAPv2 је слаб. Ако сервер нуди и L2TP/IPsec, IKEv2 или WireGuard, прелазак на један од њих уклања целу ову класу проблема.

Где PPTP мора да остане, покретање клијента на хосту уместо у контејнеру уклања један слој NAT-а и филтрирања, што је често јефтинија одлука.