Miért teszi a route-nopull önmagában elérhetetlenné a fájlszervert
A tolt útvonalak figyelmen kívül hagyása csak a felosztott alagút fele. Válassza ki az útvonal tulajdonosát, adja hozzá kézzel az irodai előtagot, és teszteljen három folyamatot, mielőtt megoldottnak nevezné.
A fájlszerver szépen megnyílik, és a szomszéd ablakban a videóhívás akadozni kezd. Semmi sem lassú, és egyetlen MTU sem rossz: az ügyfél átvette a szerver által adott útvonallistát, így most minden csomag az irodai tűzfalon keresztül megy ki. A javítás nem egy újabb hangolókapcsoló, hanem döntés arról, kié az ügyfél útválasztási táblája. Ez a döntés egyetlen helyhez tartozik, és az alábbi hibaformák megmondják, melyik helyet választotta valójában.
Döntse el, kié az útválasztási tábla
Három tulajdonos lehetséges. A szerver tolhat útvonalakat és egy alapértelmezett átjárót, ekkor az ügyfél azt telepíti, amit mondanak neki, és teljes alagút lesz. Az ügyfélprofil tulajdonjogot vehet át azzal, hogy eldobja a tolásokat és saját útvonal-sorokat hordoz. Az asztali kapcsolatkezelő is birtokolhatja a döntést a saját útvonal- és alapértelmezett útvonal tulajdonságain keresztül.
Minden választás másképp bukik el, ezért érdemes elolvasni a táblázatot, mielőtt szerkesztené a profilt. A tünetéhez illeszkedő sor az a tulajdonos, amely valóban Önnél van.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Válasszon egyet, és írja le. Kettő keverése olyan gazdagépet hagy, amelynek alapértelmezett útvonala ellentmond a saját dokumentációjának, és a következő mérnök nem tudja megmondani, melyik réteg nyert. Törölje a vesztest egyértelműen.
A route-nopull szűri a tolásokat, nem ad hozzá útvonalakat
route-nopull az ügyfélprofilba való, és sorrendje abban a fájlban közömbös, mert csak a szerverről érkező értékeket dobja el. Eldobja a tolt útvonalakat, beleértve egy tolt alapértelmezett útvonalat is, miközben az alagút továbbra is normálisan feljön.
A következmény, amit az emberek kihagynak, hogy a tolt DHCP-beállítások velük mennek. A szerver által küldött DNS-beállítások is eldobódnak, így a belső nevek megszűnnek feloldódni, pedig az alagút egészséges, és a szerver cím alapján elérhető.
Ez útvonal nélkül hagyja az alagutat az irodai előtag felé, hacsak nem ad hozzá egyet maga: route-nopull, majd route 10.30.0.0 255.255.0.0 ugyanabban a profilban. Az a sor címet és maszkot hordoz; nem nevez meg következő ugrást.
Egy alternatív forma átjáró-tokent fűz hozzá, route 10.30.0.0 255.255.0.0 vpn_gateway, amely név szerint az alagútra mutatja a bejegyzést. Az importálók eltérnek abban, hogy lefordítják-e ezt a változatot, ezért vizsgálja meg a tárolt kapcsolatot, ha a bejegyzés hiányzik a kernel táblájából.
Útvonalkeresésekkel ellenőrizzen, ne pinggel
A ping megmondja, hogy valami válaszolt. Az útvonalkeresés megmondja, melyik interfészt választaná a kernel, és ez az a kérdés, amit valójában feltett. Négy rövid parancs választja el a hiányzó útvonalat a rossz eszközre mutató útvonaltól.
Olvassa el, mit telepített az alagút a ip route show dev tun0 segítségével. Teljes kimenethiány nulla útvonalat jelent, ami nem működő felosztott alagút, és ez a szokásos eredménye a szűrő kifejezett sor nélküli hozzáadásának.
Ezután ellenőrizzen egy irodai címet a ip route get 10.30.5.7 segítségével, és egy közönséges internetcímet a ip route get 1.1.1.1 segítségével. A másodiknak a fizikai interfészt kell megneveznie; ha az alagutat nevezi meg, a tolás egyáltalán nem lett szűrve.
Végül olvassa el a ip rule kimenetét, mert egy korábbi kísérlet által hagyott házirend-szabály felülírhatja az imént javított táblázatot. A helyes profil egy elavult szabállyal a tetején pontosan úgy néz ki, mint egy törött profil. Törölje a legutóbb hozzáadott szabályt, mielőtt újat adna hozzá.
Az átfedő alhálózatok törött alagútnak látszanak
Két privát tartomány azonos lehet az ügyfél szemszögéből, és itt okolják a felosztott alagutat valamiért, amit nem okozott. Ha az iroda ugyanazt az előtagot osztja ki, amit az otthoni routere használ, az alagút útvonala lefedi a routert, és az otthoni hálózat úgy tűnik, mintha eltűnt volna.
Hasonlítsa össze a saját interfészén lévő címet a profillal telepített útvonallal, egyszerű címlistát használva, mielőtt bármit megváltoztatna. Az átfedés valós, és egyetlen profilbeállítás sem oldja meg. Amit javíthat, az az elnevezés, hogy a következő ember két tartományt lásson egy helyett.
Az őszinte javítások az egyik oldal újraszámozása vagy a címek fordítása az irodában. Egyetlen gazdagép-útvonal rögzítése a routerhez addig működik, amíg a router címe meg nem változik, és akkor az első fölött egy második rejtély lesz.
Tegye a döntést túlélővé egy újracsatlakozás után
A kézzel beírt bejegyzések nem élik túl az újracsatlakozást, és a kapcsolatkezelő minden alkalommal újraépíti a táblát, amikor a profil elindul. Tegye a döntést oda, ahol a kapcsolat létrejön, akár a profil, akár a kezelő tárolt beállításai. Ezután indítsa újra a kapcsolatot egyszer szándékosan, ahelyett hogy a viselkedést egy hívás közben fedezné fel. Egy profil, amely csak a következő újracsatlakozásig működik, nincs kész.
Gyakoroljon három utat egyszerre: egy irodai gazdagépet a szó szerinti címmel, ugyanazt a gazdagépet névvel, és egy közönséges nyilvános webhelyet. A középső a névszolgáltatástól függ, amelyet a tolt DNS-beállítások elhagyása után konfigurált, és az az, amelyik csendben elbukik.