PPTP in Docker verifieer, maar dra geen verkeer nie

Die kliënt verifieer, PPP onderhandel 'n adres, en dan beweeg niks. Ping misluk, die blaaier misluk, en die houer lyk die hele tyd verbind. Daardie patroon is nie 'n roetetabel-probleem nie, want roeteerprobleme breek gewoonlik ook die beheerverbinding. Dit is die vragpad, en in PPTP is die vrag 'n ander protokol as die een wat pas geslaag het.

Vyf kontroles, in die volgorde wat die meeste tyd spaar.

Kontrole 1: skei die beheerkanaal van die vrag

PPTP verifieer oor TCP 1723 en dra dan die PPP-vrag binne GRE, IP-protokol 47. GRE is nóg TCP nóg UDP, so elke reël wat die beheerpoort deurstuur, sê niks daaroor nie. 'n NAT of firewall wat 1723 deurlaat, kan protokol 47 sonder klag laat val, en die sessie bly half opgebou op 'n manier wat soos sukses lyk.

As die aanmelding werk en geen pakkie kom terug nie, aanvaar eers GRE en bewys dit tweedens.

Kontrole 2: bevestig die hulp op die gasheerkern

Verbindingnasporing kan nie 'n TCP-beheerverbinding aan 'n GRE-vloei koppel sonder 'n hulp nie. Die module is nf_conntrack_pptp, dit woon in die gasheerkern, en om dit binne die houerbeeld te laai bereik niks omdat modules gasheerwyd is. lsmod | grep nf_conntrack_pptp op die Docker-gasheer is die kontrole. As dit ontbreek, laai modprobe nf_conntrack_pptp dit vir die lopende kern en sê niks oor die volgende selflaai nie, so voeg dit ook by die gasheerkonfigurasie.

’n Module wat by herlaai verdwyn, word volgende maand dieselfde kaartjie.

Kontrole 3: lees die kernbeleid wat dit uitskakel

Selfs met die module teenwoordig, verstek kerne sedert 4.7 net.netfilter.nf_conntrack_helper op 0, wat outomatiese hulptoewysing vir elke protokol afskakel. Daardie verstek is waarom 'n korrek geïnstalleerde module steeds niks doen: die kode is daar en die beleid sê om dit nie te gebruik nie. sysctl net.netfilter.nf_conntrack_helper rapporteer die huidige waarde, en om dit tydens looptyd op 1 te stel maak die hulp weer beskikbaar. Bewaar die waarde deur die gasheer se sysctl-konfigurasie as die ontwerp dit toelaat.

Outomatiese toewysing laat verkeer implisiet verwagtings skep, wat juis is waarom die verstek verander het. Beperk dit tot die vertroude gasheer, of gebruik 'n eksplisiete reël wat op die hulp mik.

Kontrole 4: kyk afsonderlik na die houer se pad

’n Gelaaide hulp skep nie 'n roete nie. Die houer het 'n pad na die PPTP-bediener nodig, en gasheer-deursturing moet GRE in beide rigtings toelaat: iptables -L FORWARD -v -n wys of protokol 47 aanvaar word en of die tellers beweeg. Docker se masquerade-reëls vertaal TCP en UDP, nie protokol 47 nie, so 'n gebrugde houer het dalk 'n eksplisiete deurstuur-aanvaarding nodig en, op sommige gashere, sy eie vertaalreël. Bevestig ook dat die houer die PPP-toestelondersteuning het wat sy beeld verwag.

Lees die tellers eerder as die reëlteks. 'n Reël wat bestaan en niks pas nie, is versiering.

Kontrole 5: bewys GRE word genaspor, besluit dan oor PPTP

Laat die kliënt loop en lees die nasporingstabel. 'n Gevestigde PPTP-beheerinskrywing plus 'n verwante GRE-inskrywing beteken die hulp koppel die vloeie en die oorblywende fout is elders. 'n Beheerinskrywing sonder 'n GRE-inskrywing beteken die vrag word laat val of nie genaspor nie, wat jou terugbring by kontroles 2 en 3.

PPTP self is legacy en MS-CHAPv2 is swak. As die bediener ook L2TP/IPsec, IKEv2 of WireGuard bied, verwyder die oorgang na een daarvan hierdie hele klas probleme.

Waar PPTP moet bly, verwyder die kliënt op die gasheer te laat loop in plaas van binne 'n houer een laag NAT en filtering, wat dikwels die goedkoper besluit is.