PPTP u Dockeru se autentificira, ali ne prenosi promet

Klijent se autentificira, PPP pregovara adresu, a zatim se ništa ne pomjera. Ping ne uspijeva, preglednik ne uspijeva, a kontejner cijelo vrijeme izgleda povezan. Taj obrazac nije problem tablice usmjeravanja, jer problemi s usmjeravanjem obično pokvare i kontrolnu vezu. To je put podataka, a u PPTP-u su podaci drugi protokol od onoga koji je upravo uspio.

Pet provjera, redom koji štedi najviše vremena.

Provjera 1: odvojite kontrolni kanal od podataka

PPTP se autentificira preko TCP 1723, a zatim nosi PPP podatke unutar GRE-a, IP protokola 47. GRE nije ni TCP ni UDP, pa svako pravilo koje propušta kontrolni port ne govori ništa o njemu. NAT ili vatrozid koji propušta 1723 može bez pritužbe odbaciti protokol 47, a sesija ostaje napola izgrađena na način koji izgleda kao uspjeh.

Ako prijava radi i nijedan paket se ne vraća, prvo pretpostavite GRE, a zatim to dokažite.

Provjera 2: potvrdite pomoćnik u jezgri hosta

Praćenje veza ne može povezati TCP kontrolnu vezu s GRE tokom bez pomoćnika. Modul je nf_conntrack_pptp, živi u jezgri hosta, a učitavanje u slici kontejnera ne postiže ništa jer su moduli zajednički za cijeli host. lsmod | grep nf_conntrack_pptp na Docker hostu je provjera. Ako nedostaje, modprobe nf_conntrack_pptp ga učitava za trenutnu jezgru i ne govori ništa o sljedećem podizanju, pa ga dodajte i u konfiguraciju hosta.

Modul koji nestane pri ponovnom podizanju postaje ista kartica sljedeći mjesec.

Provjera 3: pročitajte politiku jezgre koja ga isključuje

Čak i kad je modul prisutan, jezgre od 4.7 postavljaju net.netfilter.nf_conntrack_helper prema zadanim postavkama na 0, što isključuje automatsku dodjelu pomoćnika za svaki protokol. Zbog te zadane vrijednosti ispravno instaliran modul ipak ne radi ništa: kod postoji, a politika kaže da se ne koristi. sysctl net.netfilter.nf_conntrack_helper prikazuje trenutnu vrijednost, a postavljanje na 1 tijekom rada ponovno čini pomoćnik dostupnim. Sačuvajte vrijednost kroz sysctl konfiguraciju hosta ako dizajn to dopušta.

Automatska dodjela dopušta prometu da implicitno stvara očekivanja, i upravo je zato zadana vrijednost promijenjena. Ograničite je na pouzdani host ili upotrijebite izričito pravilo koje cilja pomoćnik.

Provjera 4: pogledajte put kontejnera odvojeno

Učitani pomoćnik ne stvara rutu. Kontejneru treba put do PPTP poslužitelja, a prosljeđivanje na hostu mora dopustiti GRE u oba smjera: iptables -L FORWARD -v -n pokazuje je li protokol 47 prihvaćen i pomiču li se brojači. Docker masquerade pravila prevode TCP i UDP, ne protokol 47, pa mostni kontejner može trebati izričito dopuštenje za forward i, na nekim hostovima, vlastito pravilo prevođenja. Provjerite i da kontejner ima podršku za PPP uređaje koju njegova slika očekuje.

Čitajte brojače, a ne tekst pravila. Pravilo koje postoji i ni s čim se ne poklapa je ukras.

Provjera 5: dokažite da se GRE prati, zatim odlučite o PPTP-u

Dok klijent radi, pročitajte tablicu praćenja. Uspostavljen PPTP kontrolni zapis plus povezani GRE zapis znači da pomoćnik povezuje tokove i da je preostala greška drugdje. Kontrolni zapis bez GRE zapisa znači da se podaci odbacuju ili ne prate, što vas vraća na provjere 2 i 3.

Sam PPTP je naslijeđe, a MS-CHAPv2 je slab. Ako poslužitelj nudi i L2TP/IPsec, IKEv2 ili WireGuard, prelazak na jedan od njih uklanja cijelu ovu klasu problema.

Gdje PPTP mora ostati, pokretanje klijenta na hostu umjesto u kontejneru uklanja jedan sloj NAT-a i filtriranja, što je često jeftinija odluka.