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 и филтрирање, што често е поевтината одлука.