PPTP in Docker authenticeert maar draagt geen verkeer

De client authenticeert, PPP onderhandelt een adres en dan beweegt niets. Ping mislukt, de browser mislukt en de container lijkt de hele tijd verbonden. Dat patroon is geen routeringstabelprobleem, want routeringsproblemen breken meestal ook de besturingsverbinding. Het is het pad van de lading, en bij PPTP is de lading een ander protocol dan dat wat net lukte.

Vijf controles, in de volgorde die het meeste tijd bespaart.

Controle 1: scheid het besturingskanaal van de lading

PPTP authenticeert via TCP 1723 en draagt daarna de PPP-lading in GRE, IP-protocol 47. GRE is geen TCP en geen UDP, dus elke regel die de besturingspoort doorstuurt, zegt er niets over. Een NAT of firewall die 1723 doorlaat, kan protocol 47 zonder klacht laten vallen, en de sessie blijft half opgebouwd op een manier die op succes lijkt.

Als de aanmelding werkt en er komt geen pakket terug, ga dan eerst uit van GRE en bewijs het daarna.

Controle 2: bevestig de hulp op de hostkernel

Verbindingstracking kan zonder hulp een TCP-besturingsverbinding niet aan een GRE-stroom koppelen. De module is nf_conntrack_pptp, hij leeft in de kernel van de host, en hem in de container-image laden levert niets op omdat modules hostbreed gelden. lsmod | grep nf_conntrack_pptp op de Docker-host is de controle. Ontbreekt hij, dan laadt modprobe nf_conntrack_pptp hem voor de draaiende kernel en zegt niets over de volgende start, dus voeg hem ook toe aan de hostconfiguratie.

Een module die bij herstart verdwijnt, wordt volgende maand hetzelfde ticket.

Controle 3: lees het kernelbeleid dat hem uitschakelt

Zelfs met de module aanwezig zetten kernels sinds 4.7 net.netfilter.nf_conntrack_helper standaard op 0, wat automatische hulptoewijzing voor elk protocol uitschakelt. Die standaard is de reden dat een correct geïnstalleerde module nog steeds niets doet: de code is er en het beleid zegt hem niet te gebruiken. sysctl net.netfilter.nf_conntrack_helper meldt de huidige waarde, en hem tijdens runtime op 1 zetten maakt de hulp weer beschikbaar. Bewaar de waarde via de sysctl-configuratie van de host als het ontwerp dat toelaat.

Automatische toewijzing laat verkeer impliciet verwachtingen scheppen, en dat is precies waarom de standaard veranderde. Beperk het tot de vertrouwde host, of gebruik een expliciete regel die op de hulp is gericht.

Controle 4: bekijk het pad van de container apart

Een geladen hulp maakt geen route. De container heeft een pad naar de PPTP-server nodig, en doorsturen op de host moet GRE in beide richtingen toestaan: iptables -L FORWARD -v -n laat zien of protocol 47 wordt geaccepteerd en of de tellers bewegen. De masquerade-regels van Docker vertalen TCP en UDP, niet protocol 47, dus een gebrugde container heeft mogelijk een expliciete forward-acceptatie nodig en, op sommige hosts, zijn eigen vertaalregel. Bevestig ook dat de container de PPP-apparaatondersteuning heeft die zijn image verwacht.

Lees de tellers in plaats van de regeltekst. Een regel die bestaat en niets raakt, is versiering.

Controle 5: bewijs dat GRE wordt gevolgd, beslis dan over PPTP

Lees, terwijl de client draait, de trackingtabel. Een gevestigde PPTP-besturingsregel plus een gerelateerde GRE-regel betekent dat de hulp de stromen koppelt en dat de resterende fout elders zit. Een besturingsregel zonder GRE-regel betekent dat de lading wordt weggegooid of niet gevolgd, wat je terugbrengt bij controles 2 en 3.

PPTP zelf is legacy en MS-CHAPv2 is zwak. Als de server ook L2TP/IPsec, IKEv2 of WireGuard biedt, verwijdert een overstap naar een daarvan deze hele klasse problemen.

Waar PPTP moet blijven, verwijdert de client op de host draaien in plaats van in een container een laag NAT en filtering, wat vaak de goedkopere beslissing is.