Miért vágja le a teljes alagút útvonala az azt szállító szervert

Kapcsoljon be egy teljes alagutat, és most minden cél a VPN-interfészhez tartozik, beleértve azt a gépet is, amely lezárja. Az alagutat szállító külső csomagok ehhez a géphez vannak címezve, így az útvonal végül felemészti azt az átvitelt, amelytől függ. Egyetlen további konkrét útvonal megoldja, és az okot érdemes megérteni. E nélkül az ok nélkül a következő újraépítés visszahozza a hibát.

Egy útvonal, amely megeszi a saját átvitelét

A beágyazás minden csomagot egy második fejlécbe csomagol. A külső a helyi fizikai címről a szerver nyilvános címére van címezve, és át kell haladnia a fizikai kapcsolaton, mielőtt bármilyen alagút létezhetne.

Most engedje, hogy a nyilvános cím keresése az alagutat válassza. A csomag elküldéséhez a gépnek be kell ágyaznia, amihez útvonal kell ugyanahhoz a címhez, ami visszaadja az alagutat. Az ügyfelek ezt kétféleképpen kezelik. Az óvatos megtagadja az alapértelmezett útvonal telepítését, és hibát jelent, míg a kevésbé óvatos sikert jelent, majd semmit sem mozgat. A csendes kudarc az, amely egy délutánba kerül.

A leghosszabb előtag egyezése dönti el a keresést, mielőtt bármilyen metrikát megnéznének, így az egycímű útvonal felülmúlja a gép összes alapértelmezett útvonalát. Ez a teljes mechanizmus a javítás mögött.

Telepítse a kivételt az alapértelmezett előtt

Hozzon létre egycímű útvonalat a szerverhez, a fizikai átjáróval következő ugrásként, mielőtt az alapértelmezett útvonal elmozdul. A sorrend számít: utólag telepíteni annyit tesz, mint törött alagúttal élni gépelés közben.

A legtöbb ügyfél ezt kérés nélkül teszi. OpenVPN megkeresi a távoli címet, és rögzíti, mielőtt átírná az alapértelmezett átjárót, és a route-delay opciója azokra a platformokra létezik, ahol ez a sorrend versenyez. A wg-quick teljesen más utat választ, megjelölve a csomagokat és házirend-szabályt kérdezve ahelyett, hogy kivételt adna hozzá. Különböző mechanizmusok, ugyanaz a követelmény: a külső csomagnak ki kell szöknie az általa létrehozott alagútból.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

A keresés kimenete az elfogadási teszt. Meg kell neveznie a fizikai eszközt és a fizikai következő ugrást. Az alagúteszköz ebben a válaszban azt jelenti, hogy a kivétel hiányzik, vagy valami olyan után került, ami felülírja.

A tükörkép a szerveren

Ugyanaz a csapda vár a másik oldalon, fordítva. Adjon a szervernek alapértelmezett útvonalat egy másik alagúton keresztül, vagy toljon felé egy útvonalat, amely lefedi az ügyfelek nyilvános címeit, és a válaszai rossz irányú szokást vesznek fel.

Képzeljen el egy ügyfelet, amely csatlakozik és kérést küld. A válasz annak az ügyfélnek a nyilvános címére van címezve, amely most egy alagútútvonalnak felel meg, így egy másik interfészen indul útnak, olyan forrást hordozva, amelyet az ügyfél soha nem tárcsázott. Az ügyfél megkaphatja ezt a csomagot, és mégis eldobhatja, mert semmi sem köti az elküldött kéréshez. A szerver útválasztási döntéséből induljon ki, ne az ügyfél időtúllépéséből, mivel csak az egyik mutatja a tényleges választást.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Három javítás létezik, és nem egyenlők. A szolgáltatás fizikai címhez rögzítése vagy a forrás fordítása mindkettő elrejti az útválasztási döntést ahelyett, hogy kijavítaná. Az alagútfürdő válaszforgalmának dedikált táblán keresztüli küldése kijavítja az okot, a másik kettő pedig csak addig elfogadható, amíg az útválasztási terv fagyasztva van.

Kivételek, amelyeket az alagút folyton lop

Maroknyi feladatnak nyílt internetre van szüksége akkor is, amikor az alagút birtokolja az alapértelmezett útvonalat, és mindegyiknek saját kivétel kell. A dinamikus DNS-frissítő általában az első, amely eltörik.

Feloldja a szolgáltatót, kapcsolatot nyit, és azt találja, hogy a saját csomagjai olyan alagúton haladnak, amelynek címe másodpercekkel ezelőtt megváltozott, így a frissítés meghiúsul vagy a rossz címet teszi közzé. Három kiút: rögzítse a szolgáltatót gazdagép-útvonallal a fizikai átjárón keresztül, futtassa a frissítést, mielőtt az alagút felemelkedik, vagy adjon a frissítőnek olyan házirend-táblát, amelyet az alagút soha nem érint. Az időszinkronizálás ugyanennek a kitettségnek van kitéve egy feloldó nélkül induló eszközön, és a tanúsítvány-érvényesítési végpontok ugyanezen okból tartoznak a listára.

Az a kivétel, amelyet senki nem írt le, olyan kivétel, amelyet a következő újraépítés csendben elhullajt.

Újracsatlakozás után bizonyítsa, ne előtte

Három célt teszteljen, ne egyet: a végpontot, az alagút mögötti privát címet és az azon túli nyilvános címet. Egyetlen sikeres keresés szinte semmit sem mond a másik kettőről.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Aztán indítsa újra a kapcsolatot, mert az az ügyfél, amely újracsatlakozáskor újraépíti a tábláját, eldobja a kézzel beírt útvonalat. Ha kill switch van játékban, ellenőrizze, hogy a végpont engedélyezett-e, különben az alagút hálózatváltozás után nem tud visszatérni, és a tünet kiesésnek látszik. A kivételt a profilban vagy az unit-fájlban tárolja, ne a shell előzményeiben, hogy az újracsatlakozás újra létrehozza, ne törölje.