PPTP v Dockerju se overi, a ne prenaša prometa

Odjemalec se overi, PPP se pogodi o naslovu, nato pa se nič ne premakne. Ping spodleti, brskalnik spodleti, vsebnik pa je ves čas videti povezan. Ta vzorec ni težava usmerjevalne tabele, ker težave z usmerjanjem običajno zlomijo tudi nadzorno povezavo. To je pot podatkov, in pri PPTP so podatki drugačen protokol od tistega, ki je pravkar uspel.

Pet preverjanj v vrstnem redu, ki prihrani največ časa.

Preverjanje 1: ločite nadzorni kanal od podatkov

PPTP se overi prek TCP 1723 in nato prenaša podatke PPP znotraj GRE, protokola IP 47. GRE ni ne TCP ne UDP, zato vsako pravilo, ki posreduje nadzorna vrata, o njem ne pove ničesar. NAT ali požarni zid, ki spusti 1723, lahko brez pritožbe zavrže protokol 47, seja pa ostane napol zgrajena na način, ki je videti kot uspeh.

Če prijava deluje in se noben paket ne vrne, najprej predpostavite GRE in nato to dokažite.

Preverjanje 2: potrdite pomočnika v jedru gostitelja

Sledenje povezavam ne more brez pomočnika povezati nadzorne povezave TCP s tokom GRE. Modul je nf_conntrack_pptp, živi v jedru gostitelja, nalaganje v sliki vsebnika pa ne doseže ničesar, ker moduli veljajo za celega gostitelja. lsmod | grep nf_conntrack_pptp na gostitelju Docker je preverjanje. Če ga ni, modprobe nf_conntrack_pptp ga naloži za tekoče jedro in ne pove ničesar o naslednjem zagonu, zato ga dodajte tudi v konfiguracijo gostitelja.

Modul, ki ob ponovnem zagonu izgine, postane naslednji mesec ista zahteva.

Preverjanje 3: preberite politiko jedra, ki ga izklopi

Tudi ko je modul prisoten, jedra od 4.7 privzeto nastavijo net.netfilter.nf_conntrack_helper na 0, kar izklopi samodejno dodeljevanje pomočnika za vsak protokol. Zaradi te privzete vrednosti pravilno nameščen modul še vedno ne naredi ničesar: koda je tam, politika pa pravi, naj se ne uporablja. sysctl net.netfilter.nf_conntrack_helper poroča trenutno vrednost, in nastavitev na 1 med delovanjem znova omogoči pomočnika. Vrednost ohranite prek konfiguracije sysctl gostitelja, če zasnova to dovoljuje.

Samodejno dodeljevanje omogoča prometu, da implicitno ustvarja pričakovanja, in prav zato se je privzeta vrednost spremenila. Omejite ga na zaupanja vrednega gostitelja ali uporabite izrecno pravilo, usmerjeno na pomočnika.

Preverjanje 4: poglejte pot vsebnika posebej

Naložen pomočnik ne ustvari poti. Vsebnik potrebuje pot do strežnika PPTP, posredovanje na gostitelju pa mora dovoliti GRE v obe smeri: iptables -L FORWARD -v -n pokaže, ali je protokol 47 sprejet in ali se števci premikajo. Pravila masquerade v Dockerju prevajajo TCP in UDP, ne protokola 47, zato mostni vsebnik morda potrebuje izrecno dovoljenje forward in na nekaterih gostiteljih svoje prevajalno pravilo. Prepričajte se tudi, da ima vsebnik podporo za naprave PPP, ki jo pričakuje njegova slika.

Berite števce, ne besedila pravila. Pravilo, ki obstaja in se z ničimer ne ujema, je okras.

Preverjanje 5: dokažite, da se GRE sledi, nato odločite o PPTP

Medtem ko odjemalec teče, preberite tabelo sledenja. Vzpostavljen nadzorni vnos PPTP in povezan vnos GRE pomenita, da pomočnik povezuje tokove in da je preostala napaka drugje. Nadzorni vnos brez vnosa GRE pomeni, da so podatki zavrženi ali nesledeni, kar vas vrne k preverjanjema 2 in 3.

Sam PPTP je zapuščina in MS-CHAPv2 je šibek. Če strežnik ponuja tudi L2TP/IPsec, IKEv2 ali WireGuard, prehod na enega od njih odpravi celoten ta razred težav.

Kjer mora PPTP ostati, zagon odjemalca na gostitelju namesto v vsebniku odpravi eno plast NAT in filtriranja, kar je pogosto cenejša odločitev.