A route-gateway nem redirect-gateway: mi változik valójában
Az opció csak a következő ugrást adja azoknak az útvonalaknak, amelyeket az OpenVPN telepít. Eltávolítása nem kapcsolja ki a tolt teljes alagutat, és a javítás az átirányításnál van.
Az alagút feljön, a privát alhálózat válaszol, és a szokásos böngészés továbbra is eltűnik a VPN-ben, pedig valaki törölte az átjáró sorát a profilból. Ez a kombináció a rossz direktíva szerkesztésének ujjlenyomata. Az eltávolított sor a következő ugrást adta az ügyfélnek az általa telepített útvonalakhoz; amit viszont továbbra is elkapott a forgalmat, az máshonnan érkezett, és a szerver tolta rá. A lefedettség és a következő ugrás külön feladatok, és csak az egyik dönti el, hogy a nyilvános célok használják-e az alagutat.
Az eltávolított sor a következő ugrás volt, nem házirend-kapcsoló
Minden útvonalhoz, amelyet az ügyfél telepít, kell egy átjárócím, amelyre mutat, és az átjáró direktíva az a forrás, ahonnan ez a cím jön, ha az útvonal maga nem nevez meg egyet. Törölje, és ezeknek az útvonalaknak nem lesz mihez kapcsolódniuk, tehát vagy nem települnek, vagy olyan útra kerülnek, amely sehová sem vezet. A privát alhálózat éppen az, amit egy ilyen útvonal szállított.
Közben a túlélő viselkedésnek más a szerzője: egy átirányítási opció a tolt blokkban, amely a jelzői szerint mozgatja a szokásos kimenő forgalmat az alagútba. Az átjáró eltávolítása nem kapcsolja ki és nem gyengíti. Az eredmény a két állapot legrosszabbja: a nyilvános forgalom továbbra is elkapott, és az alagutat indokló privát cél most elérhetetlen. Ezért a második szerkesztés, amelyet ugyanabban a szellemben végeztek, szintén nem változtat semmit.
Négy kar, négy különböző feladat
Ebben a vitában négy direktívát idéznek felcserélhetően, és közülük csak egy szabályozza a lefedettséget, vagyis azt, hogy mely célok haladnak egyáltalán az alagúton. A második a következő ugrást állítja be, amelyet az útvonalak használnak, a harmadik egyetlen előtagot telepít, a negyedik pedig eldob mindent, amit a szerver tolt, beleértve a telepítéshez szükséges privát útvonalakat is. A táblázat aszerint rendezi őket, hogy a rendszergazda mit akar megváltoztatni, nem név szerint, mert éppen a nevek okozzák a zavart. Kezelje őket négy külön döntésként, és válassza azt, amelyet valóban vissza akar vonni.
A gyakorlatban mind a négy gyakran egyetlen tolt blokkban érkezik, sorról sorra, ami egyetlen beállítás részeinek láttatja őket. Nem azok, és az OpenVPN-referencia éppen ezért külön mechanizmusként dokumentálja őket. Kideríteni, melyik döntést vonja vissza, a feladat; a szerkesztés egyetlen sor.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
Szűrje a tolt sort, tartsa meg a következő ugrást
Ha a kifogásolt lefedettség tolt opcióként érkezik, a szűk válasz az, hogy hagyjuk figyelmen kívül ezt az opciót név szerint, és a tolt blokk többi részét érintetlenül hagyjuk. Szűrőként írva úgy néz ki, mint az alábbi sor, és a helye az érintett ügyfél profiljában van, nem a szerver konfigurációjában.
pull-filter ignore "redirect-gateway"A szűkségesség a lényeg. Mivel a szűrő szöveges előtagot hasonlít össze, egy rövidebb minta a következő-ugrás direktívára is illeszkedik, ami pontosan azt az információt hámozza le, amelytől a privát útvonalak függnek, és új köntösben megismétli az eredeti hibát. A szűrő csak a tolt opciókra hat, így soha nem érinti a helyben írt vagy hálózati kezelő által kényszerített egyenértékű sort. Utána csatlakozzon újra, mert az élő munkamenet nem értékeli újra, amit a szerver tolt.
Olvassa a keresést, ne a táblát
A profil újratöltése után kérdezze meg a kernelt, hova mennének valójában két célállomások: az egyik a privát előtagon belül, a másik a nyilvános interneten. A fő tábla teljes kiírása nehezebben olvasható és könnyebben félreolvasható, mert egy útvonal létezhet, és mégis veszíthet egy pontosabb egyezéssel szemben. Házirend-alapú útválasztásnál a szabály, a tábla és a forráscím is a vizsgálat része.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showA def1 változat ismeretséget érdemel, mert láthatóvá hagyja a régi alapértelmezett bejegyzést, miközben egy pár fél-alapértelmezett nyeri a keresést. Ezért egy 0.0.0.0/0 sor a kimenetben önmagában semmit nem bizonyít. A keresés válaszol arra a kérdésre, amelyre a lista csak látszólag válaszol.
A DNS-nek, az IPv6-nak és a privát útvonalnak továbbra is működnie kell
Egy IPv4-átirányítás elutasítása semmit sem mond a feloldóról, ezért egy tolt DNS-opció továbbra is küldhet kéréseket az alagútba, miközben az útvonalak helyesnek tűnnek. Egy IPv6-alapértelmezett ugyanezt teheti egy olyan címcsaládnál, amelyet az IPv4-ellenőrzés soha nem érintett. Mindkettő kifejezett döntést igényel feltevés helyett. Utána erősítse meg, hogy a privát szolgáltatás még válaszol, mert az a megosztott alagút, amely elvesztette a privát útvonalát, nem megosztott alagút, hanem törött.
Egy szélesebb eszköz figyelmeztetést érdemel: a route-nopull eldob minden tolt útvonalat és minden tolt DNS-opciót, ami biztosan megállítja a teljes alagutat, és ugyanolyan biztosan eltöri a privát útvonalakat, amelyektől a telepítés függ, tehát sokkal nagyobb kalapács, mint egyetlen opcióra célzott névszűrő. Minden változás után ellenőrizze a privát célt, egy nyilvános célt és a feloldót, és a befejezett kézfogást ne tekintse más bizonyítékának, mint a kézfogásét.