Mit tesz valójában hozzá a bypass-dhcp egy OpenVPN-útvonaltervhez

A redirect-gateway def1 bypass-dhcp beállítást tartalmazó profil az IPv4 alapértelmezett útvonal felülírását egyetlen szűk kivétellel kombinálja. Az emberek elolvassák az utolsó szót, és általános megoldást várnak a mobil kapcsolatokra, majd egy délutánt töltenek egy olyan DHCP-elmélettel, amelyet ez a kapcsoló soha nem támogatott. Minden rész egy dolgot tesz, és a kivétel sokkal kisebb a hírénél.

Bontsa szét a kapcsolókat, mielőtt egy csak mobilhálózaton jelentkező hibát a címkiosztásnak tulajdonítana. Annak a karakterláncnak a két fele semmi közös nincs egymással.

Két kapcsoló, két független feladat

A def1 kapcsolóval az ügyfél két fél alapértelmezett IPv4-útvonalat ad hozzá, ahelyett hogy lecserélné a már meglévő alapértelmezett útvonalat. A 0.0.0.0/1 a címterület alsó felét fedi le, a 128.0.0.0/1 pedig a felsőt, így együtt minden célállomást elérnek, miközben mindegyik specifikusabb marad, mint a 0.0.0.0/0. Az eredeti alapértelmezett útvonal ezért a táblában marad anélkül, hogy megnyerné ezeket a kereséseket, ami elérhetővé tartja a régi átjárót mindenhez, amit az ügyfél kifejezetten irányít. Emellett két átfedő alapértelmezett útvonalat is hagy a táblában, és ezért tűnhet egy útvonalkiírás furcsábbnak, mint amit a profil sugall.

A bypass-dhcp különálló, és egyáltalán nem érinti az alapértelmezett útvonalat. Az OpenVPN 2.6 kézikönyve úgy írja le, mint egy közvetlen útvonal hozzáadását egy olyan DHCP-kiszolgálóhoz, amely nem a helyi alhálózaton van, így a bérleti forgalom a bújtatón kívülre kerül, és megjegyzi, hogy ez a viselkedés Windows-ügyfeleken van megvalósítva, és máshol nem biztos, hogy elérhető.

Létének oka mechanikus. Amint a fél alapértelmezett útvonalak elkapják a kimenő forgalmat, a fizikai hálózaton lévő kiszolgáló felé irányuló DHCP-megújítás a bújtatóba irányulna, hacsak valami nem rögzíti azt a címet a valódi interfészhez. A kapcsoló rögzíti.

Mire terjed ki valójában a kivétel

Egy szemléltető táblázat sikeres kapcsolat után megmutatja a formát: két fél alapértelmezett útvonal a bújtatón át, és egy gazdagép-útvonal a DHCP-kiszolgálóhoz a fizikai átjárón át. Formaként olvassa, ne a saját címeiként.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

Az a harmadik sor egyetlen célállomást nevez meg. Ez nem feloldóbeállítás, nem általános engedély a helyi hálózatra, és nem kimenő szabály a kiszolgálón. Egy mobilhálózaton lévő telefonon lehet, hogy nincs olyan DHCP-kiszolgáló, amelyet az ügyfél így azonosíthatna, ezért a kapcsoló ott semmit sem változtat.

Ellenőrizze, mit telepített valójában az ügyfél

Különböztesse meg a profilba írt beállítást, a kiszolgáló által felajánlott beállítást és azt az útvonalat, amelyet a kapcsolat tulajdonosa ténylegesen alkalmazott. Egy nem támogatott kapcsolót elutasító ügyfél megtarthatja a konfiguráció többi részét, így a bújtató feljön, és a kivétel egyszerűen hiányzik. Olvassa el az ügyfél saját naplóját és a kapott útvonaltáblát, ahelyett hogy feltételezné, hogy a fájlban lévő sor hatályba lépett. Ezek közül három egyszerre igaz lehet, és csak az utolsó változtatja meg, hogy a csomagok valójában hová mennek.

Tartsa egyidejűleg használhatónak a VPN-végpont felé vezető útvonalat. Az a végpont-kivétel más követelmény, mint a DHCP-kivétel, és nélküle a bújtató befoghatja azt a szállítást, amely életben tartja.

Egy alkalmazás célállomásához vizsgálja meg a tényleges keresést abban a környezetben, ahol meghiúsul. A specifikusabb helyi útvonalak, a házirend-alapú irányítás és az alkalmazásonkénti kizárások mind megváltoztatják a választ, ezért két fél alapértelmezett útvonal jelenléte nem minden folyamat leltára.

Az útvonal többi része nincs ebben a kapcsolóban

A kiszolgálónak továbbra is engedélyre van szüksége az ügyfél internetes forgalmának továbbításához, és egy kimenő elrendezésre, amely vissza tudja adni. Egyetlen ügyféloldali útvonal sem hoz létre hiányzó továbbítást vagy forrásfordítást a kiszolgálón, és egyetlen kapcsoló sem helyettesít egy működő visszautat.

A névfeloldásnak és az IPv6-nak külön-külön szüksége van a saját házirendjére. Az IPv4-felülírás sem a bújtató oldali kiszolgáló felé nem irányítja a feloldót, sem IPv6-lefedettséget nem hoz létre, és az az ügyfél, amely csak a v4-et irányítja át, érintetlenül hagyja a v6 útvonalat.

Hasonlítson össze egy jóváhagyott ártalmatlan kérést egy működő és egy meghiúsuló hozzáférési útvonalon, a profilt és a célállomást rögzítve. Jegyezze fel, hogy a különbség a névfeloldásban, a bújtató létrehozásában, az útvonalválasztásban vagy a továbbított forgalomban van-e, és őrizze meg a választ a profillal együtt. Ez a feljegyzés az, ami megakadályozza, hogy a következő ember a DHCP-t hibáztassa egy olyan problémáért, amelyet az nem tud elérni.