PPTP i Docker autentiserer, men fører ingen trafikk

Klienten autentiserer, PPP forhandler om en adresse, og deretter beveger ingenting seg. Ping feiler, nettleseren feiler, og containeren ser tilkoblet ut hele tiden. Dette mønsteret er ikke et rutingtabellproblem, fordi rutingproblemer vanligvis bryter kontrollforbindelsen også. Det er nyttelastens vei, og i PPTP er nyttelasten en annen protokoll enn den som nettopp lyktes.

Fem kontroller, i den rekkefølgen som sparer mest tid.

Kontroll 1: skill kontrollkanalen fra nyttelasten

PPTP autentiserer over TCP 1723 og bærer deretter PPP-nyttelasten inne i GRE, IP-protokoll 47. GRE er verken TCP eller UDP, så hver regel som videresender kontrollporten sier ingenting om det. En NAT eller brannmur som slipper 1723 gjennom, kan droppe protokoll 47 uten klage, og økten forblir halvbygd på en måte som ser ut som suksess.

Hvis påloggingen virker og ingen pakke kommer tilbake, anta GRE først og bevis det etterpå.

Kontroll 2: bekreft hjelperen i vertens kjerne

Tilkoblingssporing kan ikke knytte en TCP-kontrollforbindelse til en GRE-strøm uten en hjelper. Modulen er nf_conntrack_pptp, den bor i vertens kjerne, og å laste den i containerbildet oppnår ingenting fordi moduler gjelder for hele verten. lsmod | grep nf_conntrack_pptp på Docker-verten er kontrollen. Hvis den mangler, laster modprobe nf_conntrack_pptp den for kjernen som kjører og sier ingenting om neste oppstart, så legg den også til i vertens konfigurasjon.

En modul som forsvinner ved omstart, blir samme sak neste måned.

Kontroll 3: les kjerne-policyen som slår den av

Selv med modulen til stede setter kjerner fra 4.7 net.netfilter.nf_conntrack_helper som standard til 0, noe som slår av automatisk hjelpertildeling for hver protokoll. Denne standarden er grunnen til at en riktig installert modul fortsatt ikke gjør noe: koden er der, og policyen sier at den ikke skal brukes. sysctl net.netfilter.nf_conntrack_helper rapporterer gjeldende verdi, og å sette den til 1 under kjøring gjør hjelperen tilgjengelig igjen. Behold verdien gjennom vertens sysctl-konfigurasjon hvis designet tillater det.

Automatisk tildeling lar trafikk skape forventninger implisitt, og det er nettopp derfor standarden ble endret. Begrens den til den klarerte verten, eller bruk en eksplisitt regel som retter seg mot hjelperen.

Kontroll 4: se på containerens vei for seg

En lastet hjelper lager ikke en rute. Containeren trenger en vei til PPTP-serveren, og videresending på verten må tillate GRE i begge retninger: iptables -L FORWARD -v -n viser om protokoll 47 godtas og om tellerne beveger seg. Dockers masquerade-regler oversetter TCP og UDP, ikke protokoll 47, så en broet container kan trenge en eksplisitt forward-godkjenning og, på noen verter, sin egen oversettelsesregel. Bekreft også at containeren har den PPP-enhetsstøtten som bildet forventer.

Les tellerne i stedet for regelteksten. En regel som finnes og ikke treffer noe, er dekorasjon.

Kontroll 5: bevis at GRE spores, og avgjør deretter om PPTP

Mens klienten kjører, les sporingstabellen. En etablert PPTP-kontrolloppføring pluss en relatert GRE-oppføring betyr at hjelperen kobler strømmene og at den gjenværende feilen er et annet sted. En kontrolloppføring uten GRE-oppføring betyr at nyttelasten droppes eller ikke spores, noe som bringer deg tilbake til kontrollene 2 og 3.

PPTP selv er arv og MS-CHAPv2 er svak. Hvis serveren også tilbyr L2TP/IPsec, IKEv2 eller WireGuard, fjerner et bytte til en av dem hele denne klassen med problemer.

Der PPTP må bli, fjerner å kjøre klienten på verten i stedet for i en container et lag med NAT og filtrering, noe som ofte er den billigere beslutningen.