Miért tartja elérhetőnek a VPN-végpontot egy /32-es gazdagép-útvonal

Csatlakozás után megnyitja az útválasztási táblázatot, és egyetlen címet talál, amely az alagúton keresztül megy, miközben a körülötte lévő alhálózat továbbra is a helyi átjáró felé tart. Ez a bejegyzés gazdagép-útvonal: egy cím, amelyet csupa egyesből álló előtag illeszt. Azért számít, mert az útválasztási döntések a leghosszabb egyező előtagot használják, így egy /32 felülírhat egy /24-et vagy egy alapértelmezett útvonalat anélkül, hogy bármelyiket megváltoztatná. Hogy ez gondos kivétel vagy jövőbeli kimaradás, attól függ, melyik címet nevezi meg, és ki tartja karban.

Egy cím, egy bejegyzés a táblázatban

Az IPv4 gazdagép-útvonal /32 előtagot hordoz, az IPv6 gazdagép-útvonal /128-at, ami azt jelenti, hogy a bejegyzés pontosan egy célcímhez illeszkedhet. Semmi más nem mozdul a táblázatban: a lefedő alhálózat és az alapértelmezett útvonal ott marad, ahol volt. A szűk bejegyzés azért nyer annál a címnél, mert az előtagja hosszabb, nem azért, mert később adták hozzá.

Ez a tulajdonság teszi a gazdagép-útvonalat jó kivétellé és rossz szokássá. Két /32-es bejegyzés, amely egy szolgáltatás bejárati ajtaját nevezi meg, nem fedi le annak második címét, IPv6-címét vagy azt a címet, ahová a következő hónapban költözik. Az ismeretlen egycímes bejegyzésekkel teli táblázat általában azt jelenti, hogy valaki folyton foltozott egy alhálózati döntés körül ahelyett, hogy meghozta volna. Először olvassa el az előtag hosszát, aztán kérdezze meg, mit kell a bejegyzésnek védenie.

Olvassa a bejegyzést az ügyféltől kifelé

Kezdje a problémás gépen, mert ugyanaz a cím másként útválasztható egy laptopon és az előtte lévő átjárón. Kérdezze meg a kerneltől, melyik utat választaná az alkalmazás által használt pontos címhez, ahelyett hogy felülről olvasná a táblázatot. A válasz tartalmazza az interfészt és a következő ugrást, amelyek együtt a döntést adják.

ip route get 203.0.113.25
ip -6 route get 2001:db8:4::25
ip route show | grep -F 203.0.113.25
Find-NetRoute -RemoteIPAddress 203.0.113.25

Ismételje meg a lekérdezést arra a címcsaládra, amelyet az alkalmazás valóban kiválaszt, mert az ügyfél előnyben részesítheti az IPv6-ot, és csendben megkerülheti az IPv4-kivételt. Hasonlítsa össze az eredményt az alagút felállása előtt és után, és őrizze meg mindkét kimenetet. Ez az összehasonlítás megmutatja, hogy az ügyfél a kapcsolódáskor adta-e hozzá a bejegyzést, vagy már ott volt.

Az állandó bejegyzés és a futásidejű bejegyzés másként hibázik. A futásidejű eltűnik a munkamenettel, míg az állandó túléli az újraindítást, és továbbra is forgalmat küld egy már nem létező átjáró felé.

A végpont kivétele és a rekurzió csapdája

A VPN-ügyfelek általában gazdagép-útvonalat telepítenek a kiszolgáló külső címére az eredeti átjárón keresztül, mielőtt átirányítanák az alapértelmezett útvonalat. E bejegyzés nélkül a titkosított csomagok abba az alagútba kerülnének, amelyet éppen építeni próbálnak, és a kapcsolat hurkolna, amíg le nem jár.

A csapda akkor jelenik meg, amikor az alagút elfogadott alhálózatai véletlenül tartalmazzák azt a végpontcímet, vagy amikor egy második profil később szélesebb útvonalat ad hozzá. Ekkor a végpont bejegyzése alulmarad egy hosszabb előtaggal szemben, és a munkamenet összeomlik, amint elkezd forgalmat átengedni. A végpontcím felírása az elfogadott alhálózatok mellé a legolcsóbb módja annak, hogy az ütközést a felhasználók előtt észrevegye. Azt is megmagyarázza, miért működik ugyanaz a profil az egyik hálózatból, és miért nem a másikból.

Ellenőrizze az utat, amelyet az alkalmazás valóban használ

A hosztnévre mért sikeres ping gyenge bizonyíték, ha az alkalmazás más címre vagy más címcsaládra csatlakozik. Ellenőrizze a cím, a család, a port és az interfész pontos kombinációját azon a gépen, amely az ügyfelet futtatja.

ip route get 203.0.113.25
sudo nft list ruleset | grep -A 4 'chain output'
curl -sS --max-time 8 -o /dev/null -w '%{remote_ip}
' https://app.example.net

Ha az útvonal rossz, döntse el, hogy a követelmény hálózat vagy egy cím, mielőtt bármit szerkesztene. Az egycímes követelmény indokolja a megjegyzéssel és gazdával ellátott gazdagép-útvonalat; a forgó címekkel rendelkező szolgáltatásnak tartományalapú útválasztásra vagy őszinte alhálózati döntésre van szüksége.

Távolítsa el azokat a bejegyzéseket, amelyek már nem valós célra mutatnak, és jegyezze fel azokat, amelyeket megtart. Az ismeretlen /32 három hónap múlva nem különböztethető meg egy hibától, és a következő ember törölni fogja anélkül, hogy tudná, mi függött tőle.