Következő ugrás egy VPN-útvonalon: miért kell az átjárónak helyben elérhetőnek lennie

Egy VPN-hálózatba vezető útvonal két címet hordoz, amelyeket könnyű összetéveszteni: a célprefixet, amelyet a csomag el akar érni, és a következő ugrást, amely egy lépéssel közelebb viszi. Egy LAN-gazdagépen ennek a következő ugrásnak olyan útválasztónak kell lennie, amelyet valóban elér ugyanazon a linken. A távoli VPN-cím nem következő ugrás, bármilyen szépen illeszkedik is a fejében lévő célhoz.

Ez a kézikönyv a szokásos esetet tárgyalja: egy laptop a 192.168.20.0/24 címen, egy VPN-átjáró 192.168.20.5 LAN-címmel, és egy távoli hálózat 10.70.0.0/24 e mögött az átjáró mögött. Az alábbi parancsok mind azt feltételezik, hogy a laptopon van, hacsak nem mondják másképp.

Két cím, egy útvonal

A szándékolt bejegyzés a 10.70.0.0/24 via 192.168.20.5. A prefix megmondja, hová megy a csomag; a via-cím megmondja, ki viszi oda. A kernel megtagadja olyan útvonal telepítését, amelynek átjáróját nem éri el az általad megnevezett interfészen keresztül, és ez a megtagadás az egész lényeg: egy következő ugrás, amelynek az elérhetőséghez az alagútra van szüksége, nem lehet az az ugrás, amely az alagutat építi.

Tehát az első ellenőrzés nem az, hogy „működik-e az átjáró”, hanem hogy „ezen a linken van-e az átjáró”. A laptop saját alhálózatának, az ARP- vagy szomszédbejegyzésének és az útvonalban lévő interfésznek mind egyeznie kell. Egy cím, amely csak a 10.70.0.0/24 belsejében létezik, lehet egy második útvonal célja, de soha nem az első via-ja.

Mire kötelezi a következő ugrás az átjárót

Az útvonal laptopon való telepítése csak az első átadást dönti el. Utána az átjárónak saját útra van szüksége: engedélyezett továbbítás, alagútútvonal a 10.70.0.0/24 felé, és minden hozzáférési szabályzat, amely meghatározza, ki használhatja. Linuxon ez a net.ipv4.ip_forward=1 plusz egy alagútútvonal; az előtte lévő tűzfalnak olyan szabályra van szüksége, amely engedélyezi a továbbított folyamot.

A visszirány az a rész, amelyet az emberek elfelejtenek. A távoli oldalnak útvonalra van szüksége vissza a 192.168.20.0/24 felé, vagy a tervezésnek le kell fordítania a laptop forrását valamivé, amit a távoli oldal ismer. Egy működő ping az átjáróról bizonyítja, hogy az átjáró eléri a távoli hálózatot; semmit sem mond arról, hogy a laptop csomagjai túlélik-e a visszautat.

Ellenőrizze a keresést arról a gazdagépről, amely küld

Kérdezze meg a kernelt, melyik következő ugrást választaná, és olvassa el az interfészt a válaszban:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Ha a keresés az átjárót és a LAN-interfészt jelenti, az első szakasz a szándéknak megfelelően van beállítva. Ha az alagúteszközt jelenti, valami korábbi a táblában konkrétabb, és az nyer. Ha az útvonal egyáltalán nem telepíthető, a kernel azt mondja, hogy az átjáró nem érhető el, és ez az üzenet hasznosabb bármely csomagrögzítésnél.

Ezután ismételje meg a tesztet a megfelelő helyről. Az átjárón létrehozott kérés az átjáró saját forráscímét használja, ami elrejthet egy hiányzó visszautat vagy egy szabályzatot, amely csak bizonyos forrásokat engedélyez. Az ip-route kézikönyv szétválasztja a célt, az átjárót és a onlink felülírást, és a felülírást érdemes megérteni, mielőtt használja.

Ne használja az onlinket az elérhetőség színlelésére

onlink arra utasítja a kernelt, hogy hagyja ki az átjáró elérhetőségi ellenőrzését, és mégis küldjön oda. Nem hoz létre utat, nem old fel ARP-t egy nem létező címhez, és nem késztet egy távoli útválasztót, hogy az Ethernet-szegmensén válaszoljon. Legitim olyan átjárók esetében, amelyek válaszolnak, de nem csatlakoztatott alhálózatban ülnek, és csapda, amikor egy meg nem magyarázott hiba elnémítására használják.

Ha az útvonal csak onlink-mal telepíthető, a következő kérdés, hogy miért nincs az átjáró ott, ahol gondolja. Egy rossz VLAN, egy második cím a rossz interfészen vagy egy elírás az utolsó oktettben mindezt előidézi, és mindegyikük a visszautat is elrontja, amint a forgalom elkezd folyni.

A pont-pont alagutak nem Ethernet-hálózatok

Az alagúteszköz nem végez ARP-t, és gyakran nincs értelmes szomszédalhálózata. Az útvonalai gyakran így néznek ki: 10.70.0.0/24 dev tun0, minden via nélkül, mert a partner az egyetlen másik végpont. Egy LAN-stílusú via belemásolása abba a táblába olyan útvonalat eredményez, amelyet a kernel elutasíthat, vagy ami rosszabb, olyat, amely olyan címre mutat, amelyre a partner soha nem válaszol.

Tartsa külön a két modellt a kézikönyvben: a LAN-útvonalnak elérhető átjárója van, az alagútútvonalnak interfésze és partnere. A WireGuard, az OpenVPN és az IPsec mind kissé eltérő formákat mutat, ezért jegyezze fel azt a formát, amelyet ténylegesen használt, ahelyett hogy egyetlen gazdagépből általánosítana.

Adja hozzá, erősítse meg, vonja vissza

Az egész változtatás három parancs és egy ellenőrzés, és ebben a sorrendben kell leírni:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Erősítse meg az utat, erősítse meg egy célt, majd tartsa készen a törlési sort arra az esetre, ha a változtatás olyan módon teszi elérhetetlenné a gazdagépet, amelyet nem jósolt meg. Ha az útvonalnak túl kell élnie egy újraindítást, tegye a gazdagép hálózati konfigurációjába, ne egy shell-profilba, és tesztelje az újraindítást, mielőtt támaszkodna rá. Az az útvonal, amely csak abban a shellben létezik, amely hozzáadta, olyan útvonal, amelyet kétszer fog hibakeresni.