PPTP v Dockeru se ověří, ale nepřenáší provoz

Klient se ověří, PPP vyjedná adresu a pak se nic nehýbe. Ping selhává, prohlížeč selhává a kontejner po celou dobu vypadá připojený. Tento vzorec není problém směrovací tabulky, protože problémy se směrováním obvykle rozbijí i řídicí spojení. Je to cesta dat a v PPTP jsou data jiný protokol než ten, který právě uspěl.

Pět kontrol v pořadí, které ušetří nejvíc času.

Kontrola 1: oddělte řídicí kanál od dat

PPTP se ověřuje přes TCP 1723 a pak nese data PPP uvnitř GRE, protokolu IP 47. GRE není ani TCP, ani UDP, takže každé pravidlo, které propouští řídicí port, o něm nic neříká. NAT nebo firewall, který propustí 1723, může bez stížnosti zahodit protokol 47 a relace zůstane napůl postavená způsobem, který vypadá jako úspěch.

Pokud přihlášení funguje a žádný paket se nevrací, předpokládejte nejprve GRE a potom to dokažte.

Kontrola 2: potvrďte pomocníka v jádře hostitele

Sledování spojení nedokáže propojit řídicí spojení TCP s tokem GRE bez pomocníka. Modul je nf_conntrack_pptp, žije v jádře hostitele a načtení v obraze kontejneru nic nepřinese, protože moduly jsou společné pro celý hostitel. lsmod | grep nf_conntrack_pptp na hostiteli Docker je ta kontrola. Pokud chybí, modprobe nf_conntrack_pptp ho načte pro běžící jádro a nic neříká o příštím startu, takže ho přidejte i do konfigurace hostitele.

Modul, který při restartu zmizí, se příští měsíc stane stejným tiketem.

Kontrola 3: přečtěte politiku jádra, která ho vypíná

I když je modul přítomen, jádra od 4.7 nastavují net.netfilter.nf_conntrack_helper ve výchozím stavu na 0, což vypíná automatické přiřazení pomocníka pro každý protokol. Kvůli tomuto výchozímu nastavení správně nainstalovaný modul stále nic nedělá: kód je tam a politika říká, aby se nepoužíval. sysctl net.netfilter.nf_conntrack_helper hlásí aktuální hodnotu a nastavení na 1 za běhu znovu zpřístupní pomocníka. Uložte hodnotu přes konfiguraci sysctl hostitele, pokud to návrh dovoluje.

Automatické přiřazení umožňuje provozu implicitně vytvářet očekávání, a právě proto se výchozí hodnota změnila. Omezte ho na důvěryhodného hostitele nebo použijte explicitní pravidlo cílené na pomocníka.

Kontrola 4: podívejte se na cestu kontejneru zvlášť

Načtený pomocník nevytváří trasu. Kontejner potřebuje cestu k serveru PPTP a přesměrování na hostiteli musí povolit GRE v obou směrech: iptables -L FORWARD -v -n ukazuje, zda je protokol 47 přijímán a zda se čítače hýbou. Pravidla masquerade v Dockeru překládají TCP a UDP, ne protokol 47, takže kontejner v bridge režimu může potřebovat výslovné povolení forward a na některých hostitelích vlastní překladové pravidlo. Ověřte také, že kontejner má podporu zařízení PPP, kterou jeho obraz očekává.

Čtěte čítače, ne text pravidla. Pravidlo, které existuje a s ničím se neshoduje, je dekorace.

Kontrola 5: dokažte, že GRE se sleduje, potom rozhodněte o PPTP

Když klient běží, přečtěte tabulku sledování. Navázaný řídicí záznam PPTP plus související záznam GRE znamená, že pomocník propojuje toky a zbývající závada je jinde. Řídicí záznam bez záznamu GRE znamená, že data jsou zahozena nebo nesledována, což vás vrací ke kontrolám 2 a 3.

Samotné PPTP je zastaralé a MS-CHAPv2 je slabé. Pokud server nabízí také L2TP/IPsec, IKEv2 nebo WireGuard, přechod na jeden z nich odstraní celou tuto třídu problémů.

Tam, kde PPTP musí zůstat, spuštění klienta na hostiteli místo v kontejneru odstraní jednu vrstvu NAT a filtrování, což je často levnější rozhodnutí.