PPTP Docker konteineryje autentifikuojasi, bet neperduoda srauto

Klientas autentifikuojasi, PPP susitaria dėl adreso, o tada niekas nejuda. Ping nepavyksta, naršyklė nepavyksta, o konteineris visą laiką atrodo prijungtas. Šis modelis nėra maršruto lentelės problema, nes maršruto problemos paprastai sugriauna ir valdymo ryšį. Tai duomenų kelias, o PPTP duomenys yra kitas protokolas nei tas, kuris ką tik pavyko.

Penki patikrinimai tokia tvarka, kuri sutaupo daugiausia laiko.

1 patikrinimas: atskirkite valdymo kanalą nuo duomenų

PPTP autentifikuojasi per TCP 1723 ir tada perduoda PPP duomenis GRE, IP protokolo 47 viduje. GRE nėra nei TCP, nei UDP, todėl kiekviena taisyklė, perduodanti valdymo prievadą, apie tai nieko nesako. NAT arba ugniasienė, kuri praleidžia 1723, gali be skundų numesti 47 protokolą, o sesija lieka pusiau sukurta taip, kad atrodo kaip sėkmė.

Jei prisijungimas veikia ir joks paketas negrįžta, pirmiausia manykite GRE ir tada tai įrodykite.

2 patikrinimas: patvirtinkite pagalbininką pagrindinio kompiuterio branduolyje

Ryšių sekimas negali be pagalbininko susieti TCP valdymo ryšio su GRE srautu. Modulis yra nf_conntrack_pptp, jis gyvena pagrindinio kompiuterio branduolyje, o įkėlimas konteinerio atvaizde nieko neduoda, nes moduliai galioja visam pagrindiniam kompiuteriui. lsmod | grep nf_conntrack_pptp Docker pagrindiniame kompiuteryje yra patikrinimas. Jei jo nėra, modprobe nf_conntrack_pptp įkelia jį veikiančiam branduoliui ir nieko nesako apie kitą paleidimą, todėl pridėkite jį ir į pagrindinio kompiuterio konfigūraciją.

Modulis, kuris dingsta paleidus iš naujo, kitą mėnesį tampa tuo pačiu bilietu.

3 patikrinimas: perskaitykite branduolio politiką, kuri jį išjungia

Net ir esant moduliui, branduoliai nuo 4.7 pagal numatytuosius nustatymus nustato net.netfilter.nf_conntrack_helper į 0, o tai išjungia automatinį pagalbininko priskyrimą visiems protokolams. Dėl šio numatytojo nustatymo teisingai įdiegtas modulis vis tiek nieko nedaro: kodas yra, o politika sako juo nesinaudoti. sysctl net.netfilter.nf_conntrack_helper rodo dabartinę reikšmę, o nustačius ją į 1 vykdymo metu pagalbininkas vėl tampa prieinamas. Išsaugokite reikšmę per pagrindinio kompiuterio sysctl konfigūraciją, jei dizainas tai leidžia.

Automatinis priskyrimas leidžia srautui netiesiogiai kurti lūkesčius, ir būtent todėl numatytasis nustatymas buvo pakeistas. Apribokite jį patikimu pagrindiniu kompiuteriu arba naudokite aiškią taisyklę, nukreiptą į pagalbininką.

4 patikrinimas: atskirai pažiūrėkite į konteinerio kelią

Įkeltas pagalbininkas nesukuria maršruto. Konteineriui reikia kelio į PPTP serverį, o pagrindinio kompiuterio persiuntimas turi leisti GRE abiem kryptimis: iptables -L FORWARD -v -n parodo, ar 47 protokolas priimamas ir ar skaitikliai juda. Docker masquerade taisyklės verčia TCP ir UDP, o ne 47 protokolą, todėl tiltu sujungtam konteineriui gali prireikti aiškaus forward leidimo ir kai kuriuose kompiuteriuose savo vertimo taisyklės. Taip pat patvirtinkite, kad konteineris turi PPP įrenginių palaikymą, kurio tikisi jo atvaizdas.

Skaitykite skaitiklius, o ne taisyklės tekstą. Taisyklė, kuri egzistuoja ir nieko neatitinka, yra puošmena.

5 patikrinimas: įrodykite, kad GRE sekamas, tada nuspręskite dėl PPTP

Kai klientas veikia, skaitykite sekimo lentelę. Nustatytas PPTP valdymo įrašas ir susijęs GRE įrašas reiškia, kad pagalbininkas susieja srautus, o likęs gedimas yra kitur. Valdymo įrašas be GRE įrašo reiškia, kad duomenys metami arba nesekami, ir tai grąžina jus prie 2 ir 3 patikrinimų.

Pats PPTP yra paveldas, o MS-CHAPv2 yra silpnas. Jei serveris taip pat siūlo L2TP/IPsec, IKEv2 arba WireGuard, perėjimas prie vieno iš jų pašalina visą šią problemų klasę.

Kur PPTP turi likti, kliento paleidimas pagrindiniame kompiuteryje, o ne konteineryje pašalina vieną NAT ir filtravimo sluoksnį, o tai dažnai yra pigesnis sprendimas.