PPTP i Docker autentiserar men bär ingen trafik

Klienten autentiserar, PPP förhandlar fram en adress och sedan rör sig ingenting. Ping misslyckas, webbläsaren misslyckas och containern ser ansluten ut hela tiden. Mönstret är inte ett routingtabellsproblem, eftersom routingproblem vanligtvis bryter styranslutningen också. Det är nyttolastens väg, och i PPTP är nyttolasten ett annat protokoll än det som just lyckades.

Fem kontroller, i den ordning som sparar mest tid.

Kontroll 1: skilj styrkanalen från nyttolasten

PPTP autentiserar över TCP 1723 och bär sedan PPP-nyttolasten inne i GRE, IP-protokoll 47. GRE är varken TCP eller UDP, så varje regel som vidarebefordrar styrporten säger ingenting om det. En NAT eller brandvägg som släpper igenom 1723 kan tappa protokoll 47 utan klagomål, och sessionen förblir halvbyggd på ett sätt som ser ut som framgång.

Om inloggningen fungerar och inget paket kommer tillbaka, anta GRE först och bevisa det sedan.

Kontroll 2: bekräfta hjälparen i värdens kärna

Anslutningsspårning kan inte koppla en TCP-styranslutning till ett GRE-flöde utan en hjälpare. Modulen är nf_conntrack_pptp, den bor i värdens kärna, och att läsa in den i containeravbildningen gör ingen nytta eftersom moduler gäller för hela värden. lsmod | grep nf_conntrack_pptp på Docker-värden är kontrollen. Om den saknas läser modprobe nf_conntrack_pptp in den för den körande kärnan och säger ingenting om nästa start, så lägg även till den i värdens konfiguration.

En modul som försvinner vid omstart blir samma ärende nästa månad.

Kontroll 3: läs kärnans policy som stänger av den

Även med modulen närvarande sätter kärnor sedan 4.7 net.netfilter.nf_conntrack_helper som standard till 0, vilket stänger av automatisk hjälpartilldelning för varje protokoll. Den standarden är anledningen till att en korrekt installerad modul fortfarande inte gör något: koden finns och policyn säger att den inte ska användas. sysctl net.netfilter.nf_conntrack_helper rapporterar aktuellt värde, och att sätta det till 1 under körning gör hjälparen tillgänglig igen. Behåll värdet via värdens sysctl-konfiguration om designen tillåter det.

Automatisk tilldelning låter trafik skapa förväntningar implicit, och det är precis därför standarden ändrades. Begränsa den till den betrodda värden, eller använd en uttrycklig regel som riktar sig mot hjälparen.

Kontroll 4: titta på containerens väg separat

En inläst hjälpare skapar ingen rutt. Containern behöver en väg till PPTP-servern, och vidarebefordran på värden måste tillåta GRE i båda riktningarna: iptables -L FORWARD -v -n visar om protokoll 47 accepteras och om räknarna rör sig. Dockers masquerade-regler översätter TCP och UDP, inte protokoll 47, så en bryggad container kan behöva ett uttryckligt forward-tillstånd och, på vissa värdar, sin egen översättningsregel. Bekräfta också att containern har det PPP-enhetsstöd som avbildningen förväntar sig.

Läs räknarna i stället för regeltexten. En regel som finns och inte träffar något är dekoration.

Kontroll 5: bevisa att GRE spåras, avgör sedan om PPTP

Läs spårningstabellen medan klienten kör. En etablerad PPTP-styrpost plus en relaterad GRE-post betyder att hjälparen kopplar flödena och att det kvarvarande felet finns någon annanstans. En styrpost utan GRE-post betyder att nyttolasten släpps eller inte spåras, vilket tar dig tillbaka till kontrollerna 2 och 3.

PPTP självt är arv och MS-CHAPv2 är svagt. Om servern också erbjuder L2TP/IPsec, IKEv2 eller WireGuard tar ett byte till någon av dem bort hela den här klassen av problem.

Där PPTP måste stanna, tar att köra klienten på värden i stället för i en container bort ett lager NAT och filtrering, vilket ofta är det billigare beslutet.