PPTP Docker konteinerī autentificējas, bet nepārraida datplūsmu

Klients autentificējas, PPP vienojas par adresi, un tad nekas neizkustas. Ping neizdodas, pārlūks neizdodas, un konteiners visu laiku izskatās savienots. Šis modelis nav maršrutēšanas tabulas problēma, jo maršrutēšanas problēmas parasti salauž arī vadības savienojumu. Tas ir datu ceļš, un PPTP datos ir cits protokols nekā tas, kas tikko izdevās.

Piecas pārbaudes tādā secībā, kas ietaupa visvairāk laika.

1. pārbaude: atdaliet vadības kanālu no datiem

PPTP autentificējas pa TCP 1723 un pēc tam pārnēsā PPP datus GRE iekšpusē, IP protokols 47. GRE nav ne TCP, ne UDP, tāpēc katrs noteikums, kas pārsūta vadības portu, par to neko nesaka. NAT vai ugunsmūris, kas laiž cauri 1723, var bez sūdzībām nomest 47 protokolu, un sesija paliek pusceļā uzbūvēta tā, ka izskatās pēc panākuma.

Ja pieteikšanās darbojas un neviens pakets neatgriežas, vispirms pieņemiet GRE un pēc tam to pierādiet.

2. pārbaude: apstipriniet palīgu resursdatora kodolā

Savienojumu izsekošana nevar bez palīga saistīt TCP vadības savienojumu ar GRE plūsmu. Modulis ir nf_conntrack_pptp, tas dzīvo resursdatora kodolā, un tā ielāde konteinera attēlā neko nedod, jo moduļi attiecas uz visu resursdatoru. lsmod | grep nf_conntrack_pptp Docker resursdatorā ir pārbaude. Ja tā nav, modprobe nf_conntrack_pptp ielādē to darbojošajam kodolam un neko nepasaka par nākamo startu, tāpēc pievienojiet to arī resursdatora konfigurācijai.

Modulis, kas pazūd pārstartējot, nākamajā mēnesī kļūst par to pašu biļeti.

3. pārbaude: izlasiet kodola politiku, kas to izslēdz

Pat ja modulis ir, kodoli kopš 4.7 pēc noklusējuma iestata net.netfilter.nf_conntrack_helper uz 0, kas izslēdz automātisku palīga piešķiršanu visiem protokoliem. Šis noklusējums ir iemesls, kāpēc pareizi instalēts modulis joprojām neko nedara: kods ir, un politika saka to neizmantot. sysctl net.netfilter.nf_conntrack_helper ziņo pašreizējo vērtību, un iestatīšana uz 1 izpildes laikā padara palīgu atkal pieejamu. Saglabājiet vērtību resursdatora sysctl konfigurācijā, ja dizains to pieļauj.

Automātiskā piešķiršana ļauj datplūsmai netieši radīt gaidas, un tieši tāpēc noklusējums tika mainīts. Ierobežojiet to ar uzticamu resursdatoru vai izmantojiet skaidru noteikumu, kas vērsts uz palīgu.

4. pārbaude: aplūkojiet konteinera ceļu atsevišķi

Ielādēts palīgs neveido maršrutu. Konteineram vajag ceļu uz PPTP serveri, un resursdatora pārsūtīšanai jāatļauj GRE abos virzienos: iptables -L FORWARD -v -n parāda, vai 47 protokols tiek pieņemts un vai skaitītāji kustas. Docker masquerade noteikumi pārtulko TCP un UDP, nevis 47 protokolu, tāpēc tiltotam konteineram var būt nepieciešama skaidra forward atļauja un dažos resursdatoros sava tulkošanas noteikums. Pārliecinieties arī, ka konteineram ir PPP ierīču atbalsts, ko gaida tā attēls.

Lasiet skaitītājus, nevis noteikuma tekstu. Noteikums, kas pastāv un neatbilst nekam, ir dekorācija.

5. pārbaude: pierādiet, ka GRE tiek izsekots, tad izlemiet par PPTP

Kamēr klients darbojas, lasiet izsekošanas tabulu. Izveidots PPTP vadības ieraksts un saistīts GRE ieraksts nozīmē, ka palīgs saista plūsmas un atlikušais defekts ir citur. Vadības ieraksts bez GRE ieraksta nozīmē, ka dati tiek izmesti vai netiek izsekoti, un tas atgriež jūs pie 2. un 3. pārbaudes.

Pats PPTP ir mantojums, un MS-CHAPv2 ir vājš. Ja serveris piedāvā arī L2TP/IPsec, IKEv2 vai WireGuard, pāreja uz kādu no tiem novērš visu šo problēmu klasi.

Kur PPTP ir jāpaliek, klienta palaišana resursdatorā, nevis konteinerī novērš vienu NAT un filtrēšanas slāni, kas bieži ir lētāks lēmums.