Hogyan különböztethetők meg a VPN által küldött útvonalak a statikusaktól Linuxon

Egy előtag jelenik meg a laptopon, amikor az alagút feljön, így úgy tűnik, mintha a VPN telepítette volna. Lehet, hogy így is van, de ugyanez az eredmény jöhet egy csatlakozáskor futó kliensszkriptből, az alhálózatot felsoroló kapcsolatprofilból vagy egy statikus útvonalból, amely végig ott volt, és csak akkor kezdett működni, amikor a felület létezett. A rossz gazda választása azt jelenti, hogy az útvonal minden tisztítás után visszatér, és a következő ember ugyanezt a javítást ismétli. Az alábbi sorrend szétválasztja a hármat, mielőtt bármi megváltozna.

1. lépés: nevezze meg az előtagokat telepítő mechanizmust

A különböző protokollok különböző módon biztosítanak elérhetőséget, és mindezt hirdetésnek nevezni elrejti a különbséget. Az OpenVPN-kiszolgáló egy útvonal-irányelvet küld a vezérlőcsatornán, és a kliens telepíti, hacsak egy pull szűrő nem blokkolja. A WireGuard konfiguráció helyben sorolja fel az engedélyezett előtagokat, amelyeket a kliens a titkosításikulcs-útválasztáshoz és a hozzáadott útvonalakhoz is használ. Az IPsec-alagút forgalomválasztókat egyeztet a partnerrel, és a kernel ezekből a választókból telepít útvonalakat.

Mielőtt bármilyen táblát olvasna, állapítsa meg, melyiket használja az alagútja. A csatlakozáskor küldött útvonal nem útválasztási protokoll hirdetése, és nem ígéri, hogy az előtag a távoli vég mögött elérhető. Jegyezze fel a mechanizmust az előtag mellé, mert ez dönti el, hová tartozik a javítás.

2. lépés: hasonlítsa össze a táblát egy kapcsolat során

Mentse el a fő táblát leengedett alagúttal, hozza fel, mentse el újra, és hasonlítsa össze a két felvételt. Minden, ami megjelent, a kapcsolat életciklusához tartozik, és minden, ami maradt, a helyi konfigurációhoz.

Rögzítse a ip route show table main > /tmp/route-down.txt paranccsal, csatlakozzon, és rögzítse újra. Tegye ugyanezt a ip -6 route paranccsal, ha a hely IPv6-ot használ, mert az ott hiányzó előtag olyan hibákat okoz, amelyek nem tűnnek útválasztási jellegűnek.

3. lépés: olvassa a metrikát, ne csak a jelenlétet

Ugyanahhoz az előtaghoz két bejegyzés is létezhet egyszerre, és a kernel az alacsonyabb metrikát választja. Az 50 metrikájú statikus útvonal továbbra is legyőzi a 100 metrikájú küldött útvonalat, pedig mindkettő látható, ezért „az útvonal ott van” és „a forgalom használja” különböző állítások.

Kérdezze meg közvetlenül a kernelt a ip route get 10.20.5.7 paranccsal, és olvassa el a jelentett felületet. Ha a forgalom a fizikai adapteren keresztül távozik, miközben egy alagútútvonal ül a táblában, ezt a metrika vagy az előtag hossza magyarázza, nem a VPN-kliens. Ismételje meg a keresést egy olyan gazdagépre, amelyről tudja, hogy az alagút mögött van, és egy olyanra, amelyről tudja, hogy nincs, és a különbség megmutatja, hogy a felosztás a szándéknak megfelelően viselkedik-e.

4. lépés: találja meg az alagutat túlélő bejegyzéseket

A statikus útvonalak tervezés szerint túlélik a kapcsolat bontását, és innen származnak az elavult bejegyzések. Egy már nem létező felületre mutató állandó útvonal csendben elnyelhet egy alhálózatot, és egy újrahasznált felületnévre mutató útvonal újraindítás után a rossz ajtón küldheti ki a magánforgalmat.

Ellenőrizze az állandó oldalt ott, ahol a disztribúciója használja, legyen az systemd-networkd egység, NetworkManager-profil vagy szkript a kliens up könyvtárában. Az élő tábla javítása a ip route del paranccsal csak a következő csatlakozásig tart. Tekintse ezt a törlést a hipotézis próbájának, nem a javításnak.

Ahol a távoli vég rossz lefedettséget ad, vigye az üzemeltetőhöz, ahelyett hogy mindent szűrnek. Az összes küldött beállítás eldobása eldobja a DNS-t és a megosztott alagút szabályát is, amelyektől a profil függ.

5. lépés: erősítse meg a visszautat, mielőtt a klienst hibáztatja

Hely-hely közötti kapcsolat vagy az alagút mögötti alhálózat esetén a távoli félnek útvonalra van szüksége vissza a kliens címe felé, és az átadásnak engedélyezettnek kell lennie az átjárón. Az egyirányú út pontosan úgy néz ki, mint egy kliens-útválasztási hiba, csak a kézfogás és a kimenő csomag is sikeres.

A fordított útvonal szűrése második csapdát ad a Linux-átjárókhoz. Az a válasz, amely más felületen érkezik, mint amit az útvonal jelez, szigorú módban eldobódik, és a két szolgáltatón át vezető aszimmetrikus utak ezt megbízhatóan kiváltják. Az átjárón, nem a kliensen lévő eldobásszámlálók mondják meg, hogy a szűrés az ok.

6. lépés: az erőforrást tesztelje, ne a pinget

Amikor a választott útvonal helyes, nyissa meg a tényleges erőforrást, és erősítse meg a visszaforgalmat. A ping-válasz egy irányban bizonyítja az utat, és semmit a szolgáltatásról, a gyorsítótárazott kapcsolaton válaszoló szolgáltatás pedig még kevesebbet bizonyít.

Ezután ismételje meg az egész ellenőrzést újracsatlakozás után. A sorrend értéke, hogy megjósolja, mit fog tenni a következő kapcsolat, ezért az összehasonlítás és a metrika is a jegyhez tartozik.