Teljes alagút vagy végponti útvonal: a VPN-kiszolgáló elérhetően tartása

Adjon hozzá egy alapértelmezett útvonalat az alagúton keresztül, és az alagút saját csomagjai követni fogják. A tábla ekkor egy önmagát legyőző szabályt tartalmaz. A kiszolgálóhoz vezető titkosított kapcsolat annak a kapcsolatnak a belsejében próbál haladni, amelyet éppen létre akar hozni.

Két mechanizmus akadályozza meg ezt a hurkot. Az egyik látható az útvonaltáblában, a másik az alkalmazás belsejében él.

A belső és a külső forgalom különböző döntések

Egy alkalmazáscsomag belép a virtuális interfészbe és beágyazódik. Az eredmény egy új csomag, amely a kiszolgáló nyilvános címére van címezve. Ennek a csomagnak útvonalra van szüksége a fizikai hálózaton, mert semmi része nem léphet be az alagútba.

Mindkettő útvonalkezelési döntés, és csak az első tartozik az alagúthoz. Amikor az ügyfél olyan alapértelmezett útvonalat telepít, amely a kiszolgálót is lefedi, a külső csomagot is elkapja.

A tünetek azonnaliak és teljesek. A kézfogás befejeződik, majd semmi nem folyik, vagy a kapcsolat abban a pillanatban megszakad, amikor az útvonal telepítése megtörténik. Mindkét esetben a keepalive már nem tud kijutni.

Első lehetőség: gazdaútvonal a végpont számára

A közvetlen megközelítés útvonalat ad a kiszolgáló címéhez az eredeti átjárón keresztül. Egy sort igényel. Bárki látja, aki olvassa a táblát. Változási rekordban is könnyű elmagyarázni.

A gyengesége akkor jelenik meg, amikor a mögöttes útvonal megváltozik. A mentett útvonal egy átjárót és egy interfészt nevez meg a régi hálózatból. Wi-Fi-váltás után előfordulhat, hogy az az átjáró nem létezik, és az útvonal ott marad, helyesnek látszik és semmit nem tesz.

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

A gazdanév ezt nehezebbé teszi. Ha a végpont olyan név, amely több címre oldódik fel, a kivételnek a ténylegesen használt címet kell lefednie. Egy későbbi lekérdezés olyasmit adhat vissza, amit az útvonal soha nem fedett le.

Második lehetőség: a socket védelme

A másik megközelítés soha nem nyúl az útvonaltáblához. Az ügyfél megjelöli vagy védi az alagutat hordozó socketet, így az operációs rendszer a házirend szerint az alagúton kívülre küldi annak a socketnek a forgalmát. Az Android közvetlenül elérhetővé teszi a mechanizmust a VPN-alkalmazások számára. Az asztali ügyfelek megfelelőket valósítanak meg tűzfal-jelölésekkel vagy eszközhöz kötő hívásokkal.

Az előny az, hogy a kivétel a kapcsolatot követi egy mentett átjáró helyett. Egy hálózatváltás újraírja a mögöttes útvonalat, és a védett socket vele mozog, mert soha nem rögzítették egy címhez. Az útvonaltábla tisztán marad.

Az ár a láthatóság. Semmi nem mutatja a kivételt az útvonaltáblában, így a gazdaútvonalat kereső bíráló semmit nem talál, és arra juthat, hogy a tervezés nem biztonságos. A védelem az ügyfél kódjában és a kód által telepített házirendszabályokban él.

Választás a kettő között

Válassza a socket szintű mechanizmust, ha az ügyfél támogatja, mert túléli azokat a hálózatváltozásokat, amelyek a rögzített útvonalat elrontják. Válassza a gazdaútvonalat, ha a kivételnek más eszközök számára láthatónak kell lennie, vagy ha az ügyfél nem kínál jobbat.

Egyik mechanizmus sem szünteti meg annak szükségességét, hogy a kiszolgáló címe egyáltalán elérhető legyen. Egy privát átjárónak van nyilvános figyelőcíme, és éppen ennek a címnek kell az alagúton kívül maradnia. A mögötte lévő belső hálózatok csak azután válnak elérhetővé, hogy az alagút létezik.

Bármelyiket is választja, tartsa az alagutat birtokló komponensnél. A kézzel hozzáadott kóbor gazdaútvonal a következő hálózatig működik, aztán a holnap rejtélyes kimaradásává válik.