PPTP Dockerissa todentuu mutta ei välitä liikennettä

Asiakas todentuu, PPP neuvottelee osoitteen, ja sitten mikään ei liiku. Ping epäonnistuu, selain epäonnistuu ja säiliö näyttää yhdistetyltä koko ajan. Tämä kuvio ei ole reititystaulun ongelma, koska reititysongelmat rikkovat yleensä myös ohjausyhteyden. Se on hyötykuorman polku, ja PPTP:ssä hyötykuorma on eri protokolla kuin se, joka juuri onnistui.

Viisi tarkistusta siinä järjestyksessä, joka säästää eniten aikaa.

Tarkistus 1: erota ohjauskanava hyötykuormasta

PPTP todentuu TCP 1723:n yli ja kuljettaa sitten PPP-hyötykuorman GRE:n sisällä, IP-protokolla 47. GRE ei ole TCP eikä UDP, joten jokainen ohjausportin välittävä sääntö ei sano siitä mitään. NAT tai palomuuri, joka päästää 1723:n läpi, voi pudottaa protokollan 47 valittamatta, ja istunto jää puoliksi rakennetuksi tavalla, joka näyttää onnistumiselta.

Jos kirjautuminen toimii eikä yhtään pakettia tule takaisin, oleta ensin GRE ja todista se sitten.

Tarkistus 2: varmista apuri isäntäytimessä

Yhteyksien seuranta ei voi yhdistää TCP-ohjausyhteyttä GRE-virtaan ilman apuria. Moduuli on nf_conntrack_pptp, se elää isäntäytimessä, ja sen lataaminen säiliön kuvassa ei saavuta mitään, koska moduulit ovat isäntäkohtaisia. lsmod | grep nf_conntrack_pptp Docker-isännässä on tarkistus. Jos se puuttuu, modprobe nf_conntrack_pptp lataa sen käynnissä olevaan ytimeen eikä kerro mitään seuraavasta käynnistyksestä, joten lisää se myös isännän kokoonpanoon.

Uudelleenkäynnistyksessä katoava moduuli tulee ensi kuussa samaksi lipuksi.

Tarkistus 3: lue ytimen käytäntö, joka kytkee sen pois

Vaikka moduuli olisi paikalla, ytimet 4.7:stä lähtien asettavat net.netfilter.nf_conntrack_helper:n oletuksena arvoon 0, mikä kytkee automaattisen apurin osoittamisen pois päältä jokaiselta protokollalta. Tämä oletus on syy siihen, miksi oikein asennettu moduuli ei silti tee mitään: koodi on paikalla ja käytäntö sanoo, ettei sitä käytetä. sysctl net.netfilter.nf_conntrack_helper näyttää nykyisen arvon, ja sen asettaminen arvoon 1 ajon aikana tekee apurista jälleen käytettävän. Säilytä arvo isännän sysctl-kokoonpanon kautta, jos suunnittelu sen sallii.

Automaattinen osoittaminen antaa liikenteen luoda odotuksia implisiittisesti, ja juuri siksi oletusarvo muutettiin. Rajaa se luotettuun isäntään tai käytä apuriin kohdistuvaa nimenomaista sääntöä.

Tarkistus 4: katso säiliön polkua erikseen

Ladattu apuri ei luo reittiä. Säiliö tarvitsee polun PPTP-palvelimeen, ja isännän välityksen on sallittava GRE molempiin suuntiin: iptables -L FORWARD -v -n näyttää, hyväksytäänkö protokolla 47 ja liikkuvatko laskurit. Dockerin masquerade-säännöt kääntävät TCP:n ja UDP:n, eivät protokollaa 47, joten sillatettu säiliö voi tarvita nimenomaisen forward-hyväksynnän ja joillakin isännillä oman käännössäännön. Varmista myös, että säiliöllä on sen kuvan odottama PPP-laitetuki.

Lue laskurit, älä säännön tekstiä. Sääntö, joka on olemassa eikä vastaa mitään, on koristelu.

Tarkistus 5: todista, että GRE:tä seurataan, päätä sitten PPTP:stä

Kun asiakas on käynnissä, lue seurantataulukko. Vakiintunut PPTP-ohjausmerkintä ja siihen liittyvä GRE-merkintä tarkoittavat, että apuri yhdistää virrat ja jäljellä oleva vika on muualla. Ohjausmerkintä ilman GRE-merkintää tarkoittaa, että hyötykuorma pudotetaan tai sitä ei seurata, mikä palauttaa sinut tarkistuksiin 2 ja 3.

PPTP itsessään on perintöä ja MS-CHAPv2 on heikko. Jos palvelin tarjoaa myös L2TP/IPsec, IKEv2 tai WireGuard, siirtyminen johonkin niistä poistaa koko tämän ongelmaluokan.

Missä PPTP:n on jäätävä, asiakkaan ajaminen isännässä säiliön sijaan poistaa yhden NAT- ja suodatuskerroksen, mikä on usein halvempi ratkaisu.