Tegye tartóssá az IPv4-továbbítást a VPN-átjáró újraindítása után is

Az átjáró pingelése működik, a mögötte lévő bármi elérése nem, és ez továbbítási probléma formája, nem alagútproblémáé. Az átjáróhoz való helyi kézbesítés bizonyítja, hogy az alagút feljött és a címkiosztás működött; semmit sem mond arról, hogy a kernel átad-e egy csomagot az egyik interfészről a másikra. Mielőtt bármelyik sysctl-hez nyúlna, erősítse meg, hogy a gép ezt a forgalmat hivatott útválasztani és keresse meg azt a hálózati környezetet, amely az ügyfél felé néző interfészt tartja. Ezután ott olvassa ki az értéket, nem ott, ahová az utoljára olvasott útmutató véletlenül nézett.

Az átjáró elérése nem ugyanaz, mint a továbbítás

A kernelben két külön döntés születik. A helyi címre történő kézbesítés befejezi a csomag útját; a továbbítás egy másik interfészen keresztül küldi ki újra, és ezt a második döntést hálózati névtérenként szabályozzák. Egy átjáró teljesen elérhető lehet, miközben a továbbítás ki van kapcsolva, és egy ping-parancssorból a két hiba egyformának látszik.

Írja fel, melyik interfészen érkezik az ügyfélcsomag, és melyik interfészen hagyja el a további út. Mindkettő egy névtérhez tartozik, és az a névtér tartja a fontos beállítást.

Ott olvassa ki az értéket, ahol a csomagok valóban vannak

Egy olyan átjárón, amely a gazdanévtérben útválaszt, egyetlen parancs válaszol a kérdésre: sysctl net.ipv4.ip_forward. Amikor a bejövő és a további út egy elnevezett névtérben él, azt a névteret kérdezze: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. A gazdaérték nem helyettesíti a névtérértéket, és az egyes a gazdán semminek sem bizonyítéka.

Nem minden útválasztási környezetnek van olyan címkéje, amelyet átadhat a ip netns parancsnak. A konténer-futtatókörnyezetek és szolgáltatások olyan névtereket hoznak létre, amelyeket soha nem jegyeznek be barátságos néven, és ezekhez a futtatókörnyezet vizsgálóeszközeit használja. Cserélje a vpn-gw helyére a valódi nevet vagy a futtatókörnyezet azon mechanizmusát, amely ugyanazt a környezetet éri el, és hagyja abba a találgatást gazdaszinten.

Adjon a beállításnak egyetlen gazdát

Egy hagyományos systemd-gazdaátjárón a tartós forma egy adminisztrátor által választott nevű drop-in fájl, például /etc/sysctl.d/60-vpn-forwarding.conf, amely net.ipv4.ip_forward = 1 tartalmaz. Írja meg a fájlt, majd töltse be éppen azt a fájlt, hogy az élő állapot is megváltozzon: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, majd olvassa vissza. A fájlnév példa, nem fenntartott VPN-útvonal, és a kezdő szám számít, mert a később rendezett fájlok nyernek.

Az elsőbbség az a hely, ahol a tartósság csendben eltörik. Ellenőrizze a disztribúció betöltőjét és a saját drop-in fájlját is, mert a procps sysctl --system a végén a /etc/sysctl.conf fájlt is olvassa, míg a systemd sysctl.d-sorrendje egészen más sorozat. Egy későbbi hozzárendelés azonnal visszaállíthatja ugyanazt a kulcsot, így a fájlja helyes, a tényleges érték pedig hibás marad. Ne írja felül a meglévő adminisztrátori fájlt, hogy megnyerje ezt a vitát; keresse meg a gazdát, és ott változtasson.

A rendszerindítás után létrehozott névtérre egyáltalán nem vonatkozik a gazda drop-in fájlja. A beállítása ahhoz tartozik, ami létrehozza, legyen az a konténer-futtatókörnyezet vagy a névtér előkészítő egysége. Széles gazdajogosultságokat adni egy konténernek a kérdés megkerüléséhez rosszabb üzlet, mint tíz percet tölteni a helyes gazda azonosításával.

Tudja, mennyibe kerül a kapcsoló, mielőtt átbillenti

ip_forward nem ártalmatlan logikai érték. A kernel dokumentációja megjegyzi, hogy a módosítása több más IPv4-paramétert visszaállít a gazda vagy az útválasztó alapértékeire, ezért egy diagnosztikai átbillentés eldobhat máshol végzett hangolást, és soha nem is említi. Kezelje mellékhatásokkal járó konfigurációváltozásként, nem olyan próbaként, amelyet gondtalanul futtathat.

Ez azt is kizárja, hogy minden alkalommal ki- és bekapcsolja, amikor egy ügyfél nem ér el egy gazdát. Ha az érték már egy, a hiba máshol van az útvonalon, és ugyanazon kulcs harmadik átírása nem mozdítja el.

Bizonyítsa a tartósságot, majd tesztelje az útvonal többi részét

Négy pillanatban olvassa vissza az értéket: közvetlenül a változtatás után, a VPN-interfész megjelenése után, újracsatlakozás után és tervezett újraindítás után. Az az érték, amely e pontok bármelyikén visszaáll, második gazdával rendelkezik, és még egy egyszeri írás csak a következő újraindításig rejti el.

Az engedélyezett továbbítás még mindig három dolgot hagy ellenőrizni. Az ügyfélnek útvonalra van szüksége a célhoz, az átjárónak további útvonalra plusz engedélyre annak használatára, a célnak pedig visszaútra az ügyfél alagútcíméhez. Egy privát, útválasztott LAN nem igényel automatikusan NAT-ot, ezért ne adjon hozzá masqueradinget, amíg nem tudja, melyik hiányzik a háromból, és a szándékolt ügyféltől teszteljen, ne magától az átjárótól, mert az átjárón indult kérés soha nem érinti az éppen engedélyezett továbbítási útvonalat. Az IPv6 saját továbbítási és útválasztási szabályzattal rendelkezik, ezért egy működő IPv4-teszt semmit sem mond róla.

Tartsa együtt a runbookban a drop-in útvonalát, a névtér gazdáját és a visszaolvasó parancsot. Aki ezt legközelebb átveszi, tudja kiolvasni az értéket, látni, kié, és egy percen belül eldönteni, hogy a tartósság vagy az útvonal többi része a probléma.