Tartsa meg a privát útvonalakat és dobja el az átirányítást: OpenVPN osztott alagút
A csak privát hálózatokra szánt alagúthoz két szabály kell: a privát előtagok rajta mennek keresztül, a szokásos böngészés megtartja a helyi útvonalát. Az alapértelmezett útvonal törlése nem szabályzat.
Az alagút feljön, az alkalmazás betöltődik, és utána minden más a laptopon furcsán kezd viselkedni. Ez a szokásos formája az egy sor törlésével megvalósított, csak privát hálózatokra szánt szabályzatnak. Az elküldött alapértelmezett útvonal eltávolítása valóban megváltoztatja, hova megy a forgalom, de nem mondja meg, hova kellene helyette mennie, és a névfeloldást egyáltalán nem érinti. Egy szabályzatnak két pozitív félre van szüksége ahhoz, hogy tesztelhető legyen.
Az átirányítás törlése csak a változás fele
A teljes alagút átirányítása és a csak privát szabályzat abban különbözik, mit állítanak a világról. Az átirányítás minden célállomásra igényt tart, míg a privát szabályzat egy listára tart igényt, és a többit békén hagyja. Az igény törlése a lista megírása nélkül olyan klienst eredményez, amely a helyi hálózaton kívül semmit nem ér el, ami inkább útvonalválasztási hibának tűnik, mint a szabályzat hiányosságának. Írja meg a listát, mielőtt eltávolítja az igényt, és akkor a két lépés sorrendje már nem számít.
Mindkét fél követelmény, nem alapértelmezés. A privát előtagoknak be kell lépniük az alagútba, a szokásos célállomásoknak pedig meg kell tartaniuk a kapcsolat előtti útvonalukat.
Ha egy szervezet teljes alagutat ír elő, ebből semmi nem érvényes. A csak privát kialakítás azokhoz a telepítésekhez tartozik, ahol az osztott útvonalválasztás engedélyezett.
A pull-filter egyezés, nem kapcsoló
A pull-filter irányelv eltávolítja azokat az elküldött beállításokat, amelyek neve egy előtaggal egyezik, és ez minden, amit tesz. Az átirányítás figyelmen kívül hagyása minden más elküldött beállítást a helyén hagy, ami általában az, amit szeretne: az útvonalak, a DNS-beállítások és az útvonal-átjáró értéke továbbra is megérkezik. Helyi profilban írt irányelvet sem tud eltávolítani, mert a szűrés arra vonatkozik, amit a kiszolgáló küld.
Ellenálljon a kísértésnek, hogy figyelmen kívül hagyjon minden route-tal kezdődő beállítást. Ez a minta a kapcsolat számára szükséges privát útvonalakat is eldobja, és olyan átjáróinformációt veszíthet el, amelytől az alagút függ.
A route-nopull szélesebb döntés, mint amilyennek látszik. Megakadályozza, hogy a kliens az elküldött útvonalakat és a DHCP-szerű beállításokat csoportként fogadja el, ami más szabályzat, mint egyetlen beállítás kiszűrése.
Az alkalmazástól kifelé írja meg az útvonallistát
Kezdje azzal, amit a felhasználó valóban megnyit, majd adja hozzá a támogató részeket. Egy alkalmazás a 10.60.20.15 címen magában foglalja a saját alhálózatát, 10.60.0.0/16, egy privát név pedig azt a feloldót foglalja magában, amely válaszol rá. Ezért annak a felhasználónak, aki egyetlen alkalmazást kért, két célállomásra és egy DNS-döntésre van szüksége. Az ezen a listán túli minden építésnél fogva hatókörön kívül esik, és ez tartja a szabályzatot áttekinthetővé.
Egy együttműködő kiszolgálón ezekből két elküldött útvonal lesz, és egyik sem átirányítás. Tartsa meg az alagút topológiáját és az útvonal-átjáró értékeit, amelyeket a meglévő szolgáltatás biztosít.
Ha csak néhány felhasználónak kell ez a szabályzat, alkalmazza kliensenként vagy csoportonként. Mindenki útvonalválasztását megváltoztatni egyetlen csapat igényének javításáért az az út, amelyen egy osztott alagút kieséssé válik.
| Destination | Intended path |
|---|---|
10.60.0.0/16 | Tunnel, for the approved application services |
10.61.0.53/32 | Tunnel, to reach the internal resolver |
corp.example queries | Internal resolver, selected per namespace |
| Everything else | Local path and local resolver |
Engedje, hogy a DNS ugyanazt az utat kövesse
A feloldóhoz vezető útvonal nem feloldói szabályzat. Egy systemd-resolved kliensen a szemantikai eredmény a privát névtér útválasztási tartománya, amely a belső feloldóra mutat, és ez az, ami miatt csak azok a nevek használják. Egy Windows kliensnek viszont saját névtér-szabályzati mechanizmusra van szüksége. A profilban szereplő DNS-kiszolgáló sor önmagában egyiket sem telepíti.
Azt ellenőrizze, mit választott az operációs rendszer, és ne azt, mit kért a profil. Linuxon a resolvectl status mutatja a tartományt és a kiszolgálót kapcsolatonként; Windowson a névtér-szabályzati tábla az egyenértékű bizonyíték.
Tartsa a feloldót elérhetővé az alagúton keresztül, különben a szabályzat olyan címre mutat, amely nem kérdezhető le. Egy olyan feloldócím, amelyet az alagút nem ér el, működő szabályzatot időtúllépéssé változtat.
Újracsatlakozáskor ellenőrizze mindkét felet
A változtatás után csatlakoztassa újra a klienst, és vizsgálja meg a privát és a nyilvános cím felé vezető tényleges útvonalat. Ezután oldjon fel egy privát és egy nyilvános nevet, és erősítse meg, hogy mindegyik a szándékolt feloldót használta. Egy nyilvános webhely betöltése csak a második felet bizonyítja, és általában éppen ez a fél működik véletlenül.
Rögzítse a kész szabályzatot egy mondatban: ezek az előtagok és nevek ezt a kapcsolatot használják, minden más a helyi útvonalat követi. Utána tartsa a profilban, ahelyett hogy minden bejelentkezés után javítgatná az adapter beállításait.