PPTP yn Docker ferifiearret mar fiert gjin ferkear

De klant ferifiearret, PPP ûnderhannelet in adres, en dan beweecht neat. Ping mislearret, de browser mislearret, en de kontener liket de hiele tiid ferbûn. Dat patroan is gjin probleem fan 'e rûtele-tabel, want rûteleproblemen brekke meastentiids ek de kontrôleferbining. It is it paad fan 'e lading, en yn PPTP is de lading in oar protokol as dat dat krekt slagge.

Fiif kontrôles, yn 'e folchoarder dy't it measte tiid besparret.

Kontrôle 1: skied it kontrôlekanaal fan 'e lading

PPTP ferifiearret oer TCP 1723 en fiert dan de PPP-lading yn GRE, IP-protokol 47. GRE is noch TCP noch UDP, dat elke regel dy't de kontrôlepoarte trochstjoert seit neat oer it. In NAT of firewall dy't 1723 trochlit kin protokol 47 sûnder klacht falle litte, en de sesje bliuwt heal opboud op in manier dy't op súkses liket.

As de oanmelding wurket en der komt gjin pakket werom, nim dan earst GRE oan en bewize it dêrnei.

Kontrôle 2: befêstigje de helper op 'e hostkearn

Ferbiningsopspoaring kin in TCP-kontrôleferbining net oan in GRE-stroom keppelje sûnder helper. De module is nf_conntrack_pptp, hy libbet yn 'e hostkearn, en it laden yn 'e kontenerôfbylding leveret neat op om't modules hostbreed jilde. lsmod | grep nf_conntrack_pptp op 'e Docker-host is de kontrôle. As it ûntbrekt, lit modprobe nf_conntrack_pptp it foar de rinnende kearn lade en seit neat oer de folgjende opstart, dus foegje it ek ta oan 'e hostkonfiguraasje.

In module dy't by werstart ferdwynt, wurdt folgjende moanne itselde ticket.

Kontrôle 3: lês it kearnbelied dat it útskeakelet

Sels mei de module oanwêzich sette kearnen sûnt 4.7 net.netfilter.nf_conntrack_helper standert op 0, wat automatyske helpertawizing foar elk protokol útskeakelet. Dy standert is de reden dat in korrekt ynstallearre module noch altyd neat docht: de koade is der en it belied seit it net te brûken. sysctl net.netfilter.nf_conntrack_helper rapportearret de hjoeddeiske wearde, en it op 1 setten by runtime makket de helper wer beskikber. Bewarje de wearde fia de sysctl-konfiguraasje fan 'e host as it ûntwerp dat tasteat.

Automatyske tawizing lit ferkear ymplisyt ferwachtingen meitsje, en dat is krekt wêrom't de standert feroare. Behein it ta de fertroude host, of brûk in eksplisite regel dy't op 'e helper rjochte is.

Kontrôle 4: besjoch it paad fan 'e kontener apart

In laden helper makket gjin rûte. De kontener hat in paad nei de PPTP-tsjinner nedich, en trochstjoering op 'e host moat GRE yn beide rjochtings tastean: iptables -L FORWARD -v -n lit sjen oft protokol 47 akseptearre wurdt en oft de tellers bewege. De masquerade-regels fan Docker oersette TCP en UDP, net protokol 47, dus in brêge kontener hat miskien in eksplisite forward-akseptaasje nedich en, op guon hosts, syn eigen oersettingsregel. Befêstigje ek dat de kontener de PPP-apparaatstipe hat dy't syn ôfbylding ferwachtet.

Lês de tellers ynstee fan 'e regeltekst. In regel dy't bestiet en neat treft is fersiering.

Kontrôle 5: bewize dat GRE opspoard wurdt, beslút dan oer PPTP

Lês, mei de klant oan, de opspoaringstabel. In fêstige PPTP-kontrôleynskriuwing plus in besibbe GRE-ynskriuwing betsjut dat de helper de streamen keppelt en dat de oerbleaune flater earne oars is. In kontrôleynskriuwing sûnder GRE-ynskriuwing betsjut dat de lading falle litten of net opspoard wurdt, wat jo werom bringt by kontrôles 2 en 3.

PPTP sels is legacy en MS-CHAPv2 is swak. As de tsjinner ek L2TP/IPsec, IKEv2 of WireGuard biedt, dan hellet in oerstap nei ien fan dy dizze hiele klasse problemen fuort.

Wêr't PPTP bliuwe moat, hellet it draaien fan 'e klant op 'e host ynstee fan yn in kontener ien laach NAT en filterjen fuort, wat faak de goedkeapere beslissing is.