PPTP v Dockeri sa overí, ale neprenáša prevádzku

Klient sa overí, PPP vyjedná adresu a potom sa nič nehýbe. Ping zlyháva, prehliadač zlyháva a kontajner po celý čas vyzerá pripojený. Tento vzorec nie je problém smerovacej tabuľky, pretože problémy so smerovaním zvyčajne rozbijú aj riadiace spojenie. Je to cesta údajov a v PPTP sú údaje iný protokol než ten, ktorý práve uspel.

Päť kontrol v poradí, ktoré ušetrí najviac času.

Kontrola 1: oddeľte riadiaci kanál od údajov

PPTP sa overuje cez TCP 1723 a potom prenáša údaje PPP vnútri GRE, protokolu IP 47. GRE nie je ani TCP, ani UDP, takže každé pravidlo, ktoré prepúšťa riadiaci port, o ňom nič nehovorí. NAT alebo firewall, ktorý prepustí 1723, môže bez sťažnosti zahodiť protokol 47 a relácia zostane napoly postavená spôsobom, ktorý vyzerá ako úspech.

Ak prihlásenie funguje a žiadny paket sa nevracia, predpokladajte najprv GRE a potom to dokážte.

Kontrola 2: potvrďte pomocníka v jadre hostiteľa

Sledovanie spojení nedokáže prepojiť riadiace spojenie TCP s tokom GRE bez pomocníka. Modul je nf_conntrack_pptp, žije v jadre hostiteľa a načítanie v obraze kontajnera nič neprinesie, pretože moduly platia pre celého hostiteľa. lsmod | grep nf_conntrack_pptp na hostiteľovi Docker je tá kontrola. Ak chýba, modprobe nf_conntrack_pptp ho načíta pre bežiace jadro a nič nehovorí o ďalšom štarte, takže ho pridajte aj do konfigurácie hostiteľa.

Modul, ktorý pri reštarte zmizne, sa budúci mesiac stane tým istým tiketom.

Kontrola 3: prečítajte politiku jadra, ktorá ho vypína

Aj keď je modul prítomný, jadrá od 4.7 nastavujú net.netfilter.nf_conntrack_helper predvolene na 0, čo vypína automatické priraďovanie pomocníka pre každý protokol. Kvôli tomuto predvolenému nastaveniu správne nainštalovaný modul stále nič nerobí: kód je tam a politika hovorí, aby sa nepoužíval. sysctl net.netfilter.nf_conntrack_helper hlási aktuálnu hodnotu a nastavenie na 1 za behu znova sprístupní pomocníka. Uložte hodnotu cez konfiguráciu sysctl hostiteľa, ak to návrh dovoľuje.

Automatické priraďovanie umožňuje prevádzke implicitne vytvárať očakávania, a práve preto sa predvolená hodnota zmenila. Obmedzte ho na dôveryhodného hostiteľa alebo použite explicitné pravidlo zacielené na pomocníka.

Kontrola 4: pozrite sa na cestu kontajnera osobitne

Načítaný pomocník nevytvára trasu. Kontajner potrebuje cestu k serveru PPTP a presmerovanie na hostiteľovi musí povoliť GRE v oboch smeroch: iptables -L FORWARD -v -n ukazuje, či je protokol 47 prijímaný a či sa počítadlá hýbu. Pravidlá masquerade v Dockeri prekladajú TCP a UDP, nie protokol 47, takže kontajner v bridge režime môže potrebovať výslovné povolenie forward a na niektorých hostiteľoch vlastné prekladové pravidlo. Overte tiež, že kontajner má podporu zariadení PPP, ktorú jeho obraz očakáva.

Čítajte počítadlá, nie text pravidla. Pravidlo, ktoré existuje a s ničím sa nezhoduje, je dekorácia.

Kontrola 5: dokážte, že GRE sa sleduje, potom rozhodnite o PPTP

Keď klient beží, prečítajte tabuľku sledovania. Nadviazaný riadiaci záznam PPTP plus súvisiaci záznam GRE znamená, že pomocník prepája toky a zostávajúca závada je inde. Riadiaci záznam bez záznamu GRE znamená, že údaje sa zahadzujú alebo nesledujú, čo vás vracia ku kontrolám 2 a 3.

Samotné PPTP je zastarané a MS-CHAPv2 je slabé. Ak server ponúka aj L2TP/IPsec, IKEv2 alebo WireGuard, prechod na jeden z nich odstráni celú túto triedu problémov.

Tam, kde PPTP musí zostať, spustenie klienta na hostiteľovi namiesto v kontajneri odstráni jednu vrstvu NAT a filtrovania, čo je často lacnejšie rozhodnutie.