OpenVPN redirect-gateway: mit tesz az egyes kapcsolók az útvonalakkal

Csatlakozzon a profilban redirect-gateway beállítással, és a gép alapértelmezett útvonala eltűnhet, kettéválhat, vagy pontosan ott maradhat, ahol volt, olyan kapcsolóktól függően, amelyeket senki nem olvas el kétszer. A beállítás csak az útválasztás állapotát változtatja meg és semmi mást, ezért az egyetlen megbízható bizonyíték arra, mit tett, az a tábla, amelyet az ügyfél utána telepített. A következőkben a kapcsolat utáni tábla, az útvonal, amely életben tartja magát az alagutat, és az IPv6-forgalom következik, amelynek lefedését az utasítás soha nem állítja. Minden lépés egy parancs, amelyet az ügyfélen futtathat, amíg az alagút áll.

Mit tesz az egyes kapcsolók az alapértelmezett útvonallal

Kapcsoló nélkül a beállítás eltávolítja a szokásos alapértelmezett útvonalat, és az alagutat teszi a helyére, így a régi átjáró eltűnik a táblából, amíg a kapcsolat áll. Adja hozzá a def1 kapcsolót, és ez az alapértelmezés a listán marad, a munkát két szűkebb útvonal végzi. Adja hozzá a bypass-dhcp kapcsolót, és a DHCP-útvonal is túléli, ami olyan hálózaton számít, ahol az ügyfélnek még el kell érnie a helyi DHCP-kiszolgálót. A OpenVPN 2.6 kézikönyv oldalán lévő kapcsolólista elég rövid egyetlen olvasáshoz, és minden bejegyzés megváltoztatja, mely útvonalak kerülnek a táblába.

A betolt beállítás ugyanígy viselkedik, amikor megérkezik, ezért az ügyfélprofilban semmi sem lehet, miközben a tábla teljesen átirányítottnak látszik. Ez normális: a kiszolgáló elküldte a kapcsolókat, az ügyfél alkalmazta őket, és a helyi fájl soha nem említette az utasítást. Amikor egy betolás úgy tűnik, semmit nem tesz, ellenőrizze az ügyféloldali szűrőt, amely elfogadja vagy eldobja a lekért beállításokat, mert az eldobott beállítás egyik oldalon sem okoz hibát.

A def1 specificitással nyer anélkül, hogy hozzányúlna az alapértelmezéséhez

Két fél-alapértelmezett útvonal együtt lefedi az IPv4 teret, 0.0.0.0/1 és 128.0.0.0/1. Mindkettő specifikusabb, mint a 0.0.0.0/0, ezért a keresés őket részesíti előnyben, míg az igazi alapértelmezés a táblában marad mindannak, ami a legkevésbé specifikus egyezést kéri.

A táblát olvassa, ne a profilt, mert csak a tábla mutatja meg, melyik esetben van. Két sor elég a megkülönböztetésükhöz:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Figyeljen az interfészre és a metrikára minden sorban, ne csak a célra. Az alagútra mutató alapértelmezés és az alagútra mutató fél-alapértelmezések párja ugyanazt a szándékot írja le, és másképp hibázik, amikor az alagút leesik, mert az egyik esetben a tartalék még létezik. Jegyezze fel mindkét mezőt a változási jegyzetbe. A túlélő tartalék néha az, ami elég sokáig életben tart egy távoli munkamenetet az alagút javításához, és ez az is, ami forgalmat szivárogtat, amikor a szándék teljes alagút volt.

Tartsa elérhetővé az alagút végpontját

Az ügyfélnek olyan útvonalra van szüksége az alagút túlsó végéhez, amely maga nem halad át az alagúton. Az OpenVPN ezt a gazdaútvonalat még azelőtt telepíti, hogy bármi mást megváltoztatna, és egy kézi útvonal-módosítás vagy egy második VPN-ügyfél elveheti. A tünet utána egy kapcsolat, amely azt jelzi, hogy csatlakozva van, majd semmit nem enged át.

Kérdezze meg a kernelt, melyik interfészt használná a végpont címéhez, amíg az alagút áll. A válasznak meg kell neveznie a fizikai interfészt és annak átjáróját, soha nem tun0:

ip route get 198.51.100.20

Ha ez a keresés az alagút eszközét adja vissza, az alagút a saját szállítását hordozza, és összeomlik, amint egy csomagnak ki kell mennie. A helyi előtagok, egy második adapter és a szabályalapú útválasztás itt még számítanak, ezért egy tiszta laptopon működő átirányítás elbukhat egy felügyeleti interfésszel és két alapértelmezéssel rendelkező gazdagépen. Általában a profilt hibáztatják azért, amit a címtérv tett.

Az IPv6-forgalom továbbra is a saját tábláját használja

Az IPv4 átirányítása békén hagyja az IPv6-ot, és a két családot különböző kapcsolók változtatják. Egy kettős veremmel rendelkező gazdagépen, ahol működik a v6 alapértelmezés, a v4-forgalom teljesen az alagútban maradhat, miközben minden v6-képes cél a fizikai kapcsolaton keresztül távozik. Egy gazdagép, amely az egyik táblában helyesnek látszik, a másikban szivárog.

Csatlakozás után ellenőrizze a v6 táblát, ahelyett hogy feltételezné, hogy az alagút lefedte. Az utasítás éppen ezért hordoz címcsalád-kapcsolókat, és a profil, amely kihagyja őket, azt örökli, amit a platform alapértelmezésként tesz:

ip -6 route show default
ip -6 route get 2001:db8::10

Bizonyítsa, melyik interfészt használja egy alkalmazás

A csatlakozott állapot nem blokk, és az útvonal változása nem vészkapcsoló. Ha a közvetlen forgalomnak le kell állnia, amikor az alagút meghibásodik, az a szabály a tűzfalban él, és saját tesztet igényel.

Azt az útvonalat tesztelje, amelyet egy alkalmazás valóban bejár, ne azt, amelyet a profil leír. Először kérdezze le az útvonalat, majd kösse sorra egy kéréshez az egyes interfészeket, és hasonlítsa össze, mit jelent a túlsó oldal:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

Ha mindkét kérés ugyanazt a címet adja vissza, az alkalmazás nem használja az alagutat, pedig az útválasztási tábla szerint kellene. Ha csak az alagúthoz kötött kérés sikeres, a fizikai útvonal szűrve van ahhoz a célhoz, és az alagút azt teszi, amit kért. Írja be a kapcsolókat, a telepített útvonalakat, a végpont keresését és mindkét kimeneti eredményt a változási naplóba, hogy a következő ember tényeket örököljön a képernyőkép helyett.