PPTP i Docker godkender, men fører ingen trafik

Klienten godkendes, PPP forhandler en adresse, og derefter flytter intet sig. Ping fejler, browseren fejler, og containeren ser forbundet ud hele tiden. Det mønster er ikke et problem med routingtabellen, fordi routingproblemer normalt også bryder kontrolforbindelsen. Det er nyttelastens vej, og i PPTP er nyttelasten en anden protokol end den, der netop lykkedes.

Fem kontroller, i den rækkefølge der sparer mest tid.

Kontrol 1: adskil kontrolkanalen fra nyttelasten

PPTP godkender over TCP 1723 og bærer derefter PPP-nyttelasten inde i GRE, IP-protokol 47. GRE er hverken TCP eller UDP, så hver regel, der videresender kontrolporten, siger intet om det. En NAT eller firewall, der lukker 1723 igennem, kan droppe protokol 47 uden klage, og sessionen forbliver halvt opbygget på en måde, der ligner succes.

Hvis login virker, og ingen pakke kommer tilbage, antag GRE først og bevis det bagefter.

Kontrol 2: bekræft hjælperen i værtens kerne

Forbindelsessporing kan ikke knytte en TCP-kontrolforbindelse til en GRE-strøm uden en hjælper. Modulet er nf_conntrack_pptp, det bor i værtens kerne, og at indlæse det i containerbilledet opnår intet, fordi moduler er fælles for hele værten. lsmod | grep nf_conntrack_pptp på Docker-værten er kontrollen. Hvis det mangler, indlæser modprobe nf_conntrack_pptp det for den kørende kerne og siger intet om næste opstart, så føj det også til værtens konfiguration.

Et modul, der forsvinder ved genstart, bliver den samme sag næste måned.

Kontrol 3: læs den kernepolitik, der slår det fra

Selv med modulet til stede sætter kerner fra 4.7 net.netfilter.nf_conntrack_helper som standard til 0, hvilket slår automatisk hjælpertildeling fra for hver protokol. Den standard er grunden til, at et korrekt installeret modul stadig intet gør: koden er der, og politikken siger, at den ikke må bruges. sysctl net.netfilter.nf_conntrack_helper rapporterer den aktuelle værdi, og at sætte den til 1 under kørsel gør hjælperen tilgængelig igen. Bevar værdien via værtens sysctl-konfiguration, hvis designet tillader det.

Automatisk tildeling lader trafik skabe forventninger implicit, og det er netop derfor, standarden blev ændret. Afgræns den til den betroede vært, eller brug en eksplicit regel, der retter sig mod hjælperen.

Kontrol 4: se på containerens vej for sig

En indlæst hjælper skaber ikke en rute. Containeren har brug for en vej til PPTP-serveren, og videresendelse på værten skal tillade GRE i begge retninger: iptables -L FORWARD -v -n viser, om protokol 47 accepteres, og om tællerne flytter sig. Dockers masquerade-regler oversætter TCP og UDP, ikke protokol 47, så en broet container kan have brug for en eksplicit forward-accept og, på nogle værter, sin egen oversættelsesregel. Bekræft også, at containeren har den PPP-enhedsunderstøttelse, som dens billede forventer.

Læs tællerne i stedet for reglens tekst. En regel, der findes og ikke matcher noget, er udsmykning.

Kontrol 5: bevis at GRE spores, og afgør så PPTP

Når klienten kører, læs sporingstabellen. En etableret PPTP-kontrolpost plus en relateret GRE-post betyder, at hjælperen kæder strømmene sammen, og at den resterende fejl er et andet sted. En kontrolpost uden GRE-post betyder, at nyttelasten droppes eller ikke spores, hvilket bringer dig tilbage til kontrollerne 2 og 3.

PPTP selv er legacy, og MS-CHAPv2 er svag. Hvis serveren også tilbyder L2TP/IPsec, IKEv2 eller WireGuard, fjerner et skift til en af dem hele denne klasse af problemer.

Hvor PPTP skal blive, fjerner at køre klienten på værten i stedet for inde i en container et lag NAT og filtrering, hvilket ofte er den billigere beslutning.