PPTP Dockeris autendib, kuid ei kanna liiklust

Klient autendib, PPP lepib kokku aadressi ja siis ei liigu miski. Ping ebaõnnestub, brauser ebaõnnestub ja konteiner näib kogu aeg ühendatud. See muster ei ole marsruutimistabeli probleem, sest marsruutimisprobleemid lõhuvad tavaliselt ka juhtühenduse. See on andmete tee ja PPTP puhul on andmed teine protokoll kui see, mis äsja õnnestus.

Viis kontrolli sellises järjekorras, mis säästab kõige rohkem aega.

Kontroll 1: eraldage juhtkanal andmetest

PPTP autendib TCP 1723 kaudu ja kannab seejärel PPP andmeid GRE sees, IP-protokoll 47. GRE ei ole TCP ega UDP, seega iga reegel, mis edastab juhtporti, ei ütle selle kohta midagi. NAT või tulemüür, mis laseb 1723 läbi, võib protokolli 47 ilma kaebuseta maha visata ja seanss jääb poolikuks viisil, mis näeb välja nagu edu.

Kui sisselogimine töötab ja ükski pakett ei tule tagasi, eeldage esmalt GRE-d ja tõestage seda seejärel.

Kontroll 2: kinnitage abiline hosti tuumas

Ühenduste jälgimine ei saa abiliseta siduda TCP juhtühendust GRE vooga. Moodul on nf_conntrack_pptp, see elab hosti tuumas ja selle laadimine konteineri kujutisse ei saavuta midagi, sest moodulid kehtivad kogu hosti kohta. lsmod | grep nf_conntrack_pptp Dockeri hostis on see kontroll. Kui see puudub, laadib modprobe nf_conntrack_pptp selle töötava tuuma jaoks ega ütle midagi järgmise käivituse kohta, seega lisage see ka hosti konfiguratsiooni.

Moodul, mis taaskäivitusel kaob, muutub järgmisel kuul samaks piletiks.

Kontroll 3: lugege tuuma poliitikat, mis selle välja lülitab

Isegi kui moodul on olemas, seavad tuumad alates 4.7 net.netfilter.nf_conntrack_helper vaikeväärtuseks 0, mis lülitab iga protokolli jaoks automaatse abilise määramise välja. See vaikeväärtus on põhjus, miks korrektselt paigaldatud moodul ikkagi midagi ei tee: kood on olemas ja poliitika ütleb, et seda mitte kasutada. sysctl net.netfilter.nf_conntrack_helper näitab praegust väärtust ja selle käitusajal 1-le seadmine teeb abilise taas kättesaadavaks. Säilitage väärtus hosti sysctl-konfiguratsiooni kaudu, kui disain seda lubab.

Automaatne määramine laseb liiklusel ootusi kaudselt luua ja täpselt seetõttu vaikeväärtust muudeti. Piirake see usaldusväärse hostiga või kasutage abilisele suunatud selgesõnalist reeglit.

Kontroll 4: vaadake konteineri teed eraldi

Laaditud abiline ei loo marsruuti. Konteiner vajab teed PPTP serverini ja hosti edastus peab lubama GRE-d mõlemas suunas: iptables -L FORWARD -v -n näitab, kas protokoll 47 on vastu võetud ja kas loendurid liiguvad. Dockeri masquerade reeglid tõlgivad TCP-d ja UDP-d, mitte protokolli 47, seega sillaga konteiner võib vajada selgesõnalist forward-luba ja mõnel hostil oma tõlkereeglit. Kinnitage ka seda, et konteineril on PPP seadmete tugi, mida selle kujutis eeldab.

Lugege loendureid, mitte reegli teksti. Reegel, mis on olemas ja ei vasta millelegi, on dekoratsioon.

Kontroll 5: tõestage, et GRE-d jälgitakse, seejärel otsustage PPTP üle

Kliendi töötamise ajal lugege jälgimistabelit. Kehtestatud PPTP juhtkirje pluss seotud GRE kirje tähendab, et abiline seob vood ja ülejäänud viga on mujal. Juhtkirje ilma GRE kirjeta tähendab, et andmed visatakse ära või neid ei jälgita, mis viib teid tagasi kontrollide 2 ja 3 juurde.

PPTP ise on pärand ja MS-CHAPv2 on nõrk. Kui server pakub ka L2TP/IPsec, IKEv2 või WireGuard, eemaldab ühele neist üleminek kogu selle probleemide klassi.

Kus PPTP peab jääma, eemaldab kliendi käitamine hostis, mitte konteineris ühe NAT-i ja filtreerimise kihi, mis on sageli odavam otsus.