A Dockerben futó PPTP hitelesít, de nem visz át forgalmat

A kliens hitelesít, a PPP címről egyezkedik, aztán semmi nem mozdul. A ping meghiúsul, a böngésző meghiúsul, és a konténer végig csatlakozottnak látszik. Ez a minta nem útválasztási tábla probléma, mert az útválasztási problémák általában a vezérlőkapcsolatot is elrontják. Ez az adatút, és a PPTP-ben az adat más protokoll, mint amelyik épp sikeres volt.

Öt ellenőrzés, abban a sorrendben, amely a legtöbb időt takarítja meg.

1. ellenőrzés: válasszuk szét a vezérlőcsatornát és az adatot

A PPTP TCP 1723 felett hitelesít, majd a PPP adatot GRE-ben, IP 47 protokollban viszi. A GRE sem nem TCP, sem nem UDP, ezért minden szabály, amely a vezérlőportot továbbítja, semmit nem mond róla. Egy NAT vagy tűzfal, amely átengedi az 1723-at, panasz nélkül eldobhatja a 47 protokollt, és a munkamenet félkész marad olyan módon, amely sikernek látszik.

Ha a bejelentkezés működik és nem jön vissza csomag, először feltételezzük a GRE-t, aztán bizonyítsuk.

2. ellenőrzés: erősítsük meg a segédet a gazdagerincben

A kapcsolatkövetés segéd nélkül nem tud összekapcsolni egy TCP vezérlőkapcsolatot egy GRE folyammal. A modul a nf_conntrack_pptp, a gazdagerincben él, és a konténerképben betölteni semmit nem ér, mert a modulok az egész gazdára érvényesek. A lsmod | grep nf_conntrack_pptp a Docker-gazdán maga az ellenőrzés. Ha hiányzik, a modprobe nf_conntrack_pptp betölti a futó rendszermaghoz, és semmit nem mond a következő indításról, ezért vegyük fel a gazda konfigurációjába is.

Egy modul, amely újraindításkor eltűnik, jövő hónapban ugyanaz a jegy lesz.

3. ellenőrzés: olvassuk el a rendszermag-szabályzatot, amely kikapcsolja

Még ha a modul jelen van, a 4.7 utáni rendszermagok a net.netfilter.nf_conntrack_helper alapértékét 0-ra állítják, ami minden protokoll automatikus segédhozzárendelését kikapcsolja. Ez az alapérték az oka, hogy a helyesen telepített modul mégis semmit nem tesz: a kód ott van, és a szabályzat azt mondja, ne használjuk. A sysctl net.netfilter.nf_conntrack_helper jelenti a jelenlegi értéket, és futásidőben 1-re állítva a segéd újra elérhető lesz. Őrizzük meg az értéket a gazda sysctl-konfigurációján keresztül, ha a tervezés engedi.

Az automatikus hozzárendelés lehetővé teszi, hogy a forgalom implicit módon elvárásokat hozzon létre, és pontosan ezért változott meg az alapérték. Korlátozzuk a megbízható gazdára, vagy használjunk kifejezett szabályt, amely a segédre irányul.

4. ellenőrzés: nézzük a konténer útvonalát külön

A betöltött segéd nem hoz létre útvonalat. A konténernek útra van szüksége a PPTP-kiszolgálóhoz, és a gazda továbbításának mindkét irányban engedélyeznie kell a GRE-t: a iptables -L FORWARD -v -n megmutatja, hogy a 47 protokollt elfogadják-e, és hogy a számlálók mozdulnak-e. A Docker masquerade szabályai a TCP-t és az UDP-t fordítják, nem a 47 protokollt, ezért egy áthidalt konténernek kifejezett forward-engedélyre és néhány gazdán saját fordítási szabályra lehet szüksége. Arról is győződjünk meg, hogy a konténer rendelkezik a képe által elvárt PPP-eszköztámogatással.

A számlálókat olvassuk, ne a szabály szövegét. Egy szabály, amely létezik és semmire nem illeszkedik, díszítés.

5. ellenőrzés: bizonyítsuk, hogy a GRE követve van, aztán döntsünk a PPTP-ről

Miközben a kliens fut, olvassuk a követési táblát. Egy létrejött PPTP vezérlőbejegyzés és egy kapcsolódó GRE bejegyzés azt jelenti, hogy a segéd összekapcsolja a folyamokat, és a fennmaradó hiba máshol van. Egy vezérlőbejegyzés GRE bejegyzés nélkül azt jelenti, hogy az adatot eldobják vagy nem követik, ami visszavisz a 2. és 3. ellenőrzéshez.

A PPTP maga örökölt, és az MS-CHAPv2 gyenge. Ha a kiszolgáló L2TP/IPsec, IKEv2 vagy WireGuard lehetőséget is kínál, az egyikre való áttérés megszünteti ezt az egész problémacsoportot.

Ahol a PPTP-nek maradnia kell, a kliens gazdán való futtatása konténer helyett eltávolít egy NAT- és szűrőréteget, ami gyakran az olcsóbb döntés.