PPTP în Docker se autentifică, dar nu transportă trafic

Clientul se autentifică, PPP negociază o adresă, iar apoi nimic nu se mișcă. Ping eșuează, browserul eșuează, iar containerul pare conectat tot timpul. Acest model nu este o problemă a tabelului de rutare, pentru că problemele de rutare strică de obicei și conexiunea de control. Este calea încărcăturii, iar în PPTP încărcătura este un alt protocol decât cel care tocmai a reușit.

Cinci verificări, în ordinea care economisește cel mai mult timp.

Verificarea 1: separă canalul de control de încărcătură

PPTP se autentifică prin TCP 1723 și apoi transportă încărcătura PPP în interiorul GRE, protocolul IP 47. GRE nu este nici TCP, nici UDP, așa că fiecare regulă care redirecționează portul de control nu spune nimic despre el. Un NAT sau un firewall care lasă să treacă 1723 poate arunca protocolul 47 fără reclamație, iar sesiunea rămâne pe jumătate construită într-un mod care arată ca un succes.

Dacă autentificarea funcționează și nu se întoarce niciun pachet, presupune mai întâi GRE și apoi demonstrează-l.

Verificarea 2: confirmă asistentul din nucleul gazdă

Urmărirea conexiunilor nu poate lega o conexiune de control TCP de un flux GRE fără un asistent. Modulul este nf_conntrack_pptp, trăiește în nucleul gazdă, iar încărcarea lui în imaginea containerului nu realizează nimic pentru că modulele se aplică întregii gazde. lsmod | grep nf_conntrack_pptp pe gazda Docker este verificarea. Dacă lipsește, modprobe nf_conntrack_pptp îl încarcă pentru nucleul care rulează și nu spune nimic despre următoarea pornire, așa că adaugă-l și în configurația gazdei.

Un modul care dispare la repornire devine același tichet luna viitoare.

Verificarea 3: citește politica nucleului care îl dezactivează

Chiar și cu modulul prezent, nucleele din 4.7 încoace setează net.netfilter.nf_conntrack_helper la 0 în mod implicit, ceea ce dezactivează alocarea automată a asistentului pentru fiecare protocol. Această valoare implicită este motivul pentru care un modul instalat corect tot nu face nimic: codul este acolo și politica spune să nu fie folosit. sysctl net.netfilter.nf_conntrack_helper raportează valoarea curentă, iar setarea ei la 1 în timpul rulării face asistentul din nou disponibil. Păstrează valoarea prin configurația sysctl a gazdei dacă designul permite.

Alocarea automată lasă traficul să creeze așteptări implicit, și exact de aceea valoarea implicită a fost schimbată. Limiteaz-o la gazda de încredere sau folosește o regulă explicită îndreptată spre asistent.

Verificarea 4: privește separat calea containerului

Un asistent încărcat nu creează o rută. Containerul are nevoie de o cale către serverul PPTP, iar redirecționarea pe gazdă trebuie să permită GRE în ambele direcții: iptables -L FORWARD -v -n arată dacă protocolul 47 este acceptat și dacă contoarele se mișcă. Regulile masquerade ale Docker traduc TCP și UDP, nu protocolul 47, așa că un container în punte poate avea nevoie de o acceptare forward explicită și, pe unele gazde, de propria regulă de traducere. Confirmă și că containerul are suportul pentru dispozitive PPP pe care îl așteaptă imaginea sa.

Citește contoarele, nu textul regulii. O regulă care există și nu se potrivește cu nimic este decorațiune.

Verificarea 5: demonstrează că GRE este urmărit, apoi decide despre PPTP

Cât timp clientul rulează, citește tabelul de urmărire. O intrare de control PPTP stabilită plus o intrare GRE asociată înseamnă că asistentul leagă fluxurile și că defectul rămas este în altă parte. O intrare de control fără intrare GRE înseamnă că încărcătura este aruncată sau nu este urmărită, ceea ce te readuce la verificările 2 și 3.

PPTP în sine este moștenire, iar MS-CHAPv2 este slab. Dacă serverul oferă și L2TP/IPsec, IKEv2 sau WireGuard, trecerea la unul dintre ele elimină toată această clasă de probleme.

Acolo unde PPTP trebuie să rămână, rularea clientului pe gazdă în loc de interiorul unui container elimină un strat de NAT și filtrare, ceea ce este adesea decizia mai ieftină.