Proč hostitelská trasa /32 udržuje koncový bod VPN dostupný

Po připojení otevřete směrovací tabulku a najdete jednu adresu směrovanou tunelem, zatímco podsíť kolem ní stále míří na místní bránu. Tento záznam je hostitelská trasa: jedna adresa, shodná s prefixem samých jedniček. Záleží na tom, protože směrovací rozhodnutí používají nejdelší shodný prefix, takže /32 může přebít /24 nebo výchozí trasu, aniž by se některá z nich změnila. Zda je to pečlivá výjimka, nebo budoucí výpadek, závisí na tom, kterou adresu pojmenovává a kdo ji udržuje.

Jedna adresa, jeden záznam v tabulce

Hostitelská trasa IPv4 nese prefix /32 a hostitelská trasa IPv6 nese /128, což znamená, že záznam může odpovídat přesně jedné cílové adrese. Nic jiného v tabulce se nehýbe: krycí podsíť a výchozí trasa zůstávají tam, kde byly. Úzký záznam vyhrává pro tuto adresu proto, že jeho prefix je delší, ne proto, že byl přidán později.

Tato vlastnost dělá z hostitelské trasy dobrou výjimku a špatný zvyk. Dva záznamy /32 pojmenovávající vstupní bránu služby nepokrývají její druhou adresu, její adresu IPv6 ani adresu, na kterou se příští měsíc přesune. Tabulka plná nevysvětlených záznamů s jednou adresou obvykle znamená, že někdo pořád záplatoval kolem rozhodnutí o podsíti, místo aby ho učinil. Přečtěte si nejdřív délku prefixu a pak se ptejte, co má záznam chránit.

Čtěte záznam od klienta směrem ven

Začněte u stroje s problémem, protože stejná adresa může být směrována jinak na notebooku a na bráně před ním. Zeptejte se jádra, kterou cestu by zvolilo pro přesnou adresu, kterou aplikace používá, místo čtení tabulky odshora. Odpověď obsahuje rozhraní a další skok, což dohromady je to rozhodnutí.

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

Zopakujte dotaz pro rodinu adres, kterou aplikace skutečně volí, protože klient může upřednostnit IPv6 a tiše obejít výjimku IPv4. Porovnejte výsledek před vztyčením tunelu a po něm a oba výstupy si ponechte. Toto srovnání ukáže, zda klient záznam přidal při připojení, nebo zda tam už byl.

Trvalý záznam a běhový záznam selhávají různě. Běhový zmizí se sezením, zatímco trvalý přežije restart a dál posílá provoz bráně, která už neexistuje.

Výjimka pro koncový bod a past rekurze

Klienti VPN obvykle instalují hostitelskou trasu na vnější adresu serveru přes původní bránu, než přesměrují výchozí trasu. Bez tohoto záznamu by se šifrované pakety posílaly do tunelu, který se snaží postavit, a spojení by se točilo v cyklu, dokud by nevypršel časový limit.

Past se objeví, když přijímané podsítě tunelu náhodou zahrnou tuto adresu koncového bodu, nebo když druhý profil později přidá širší trasu. Záznam koncového bodu pak prohraje s delším prefixem a sezení se zhroutí, jakmile začne propouštět provoz. Zapsat adresu koncového bodu vedle přijímaných podsítí je nejlevnější způsob, jak si kolize všimnout dřív než uživatelé. Vysvětluje to také, proč stejný profil funguje z jedné sítě a z jiné selhává.

Ověřte cestu, kterou aplikace skutečně používá

Úspěšný ping na název hostitele je slabý důkaz, když se aplikace připojuje na jinou adresu nebo jinou rodinu. Ověřte přesnou kombinaci adresy, rodiny, portu a rozhraní ze stroje, který klienta spouští.

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

Pokud je cesta špatná, rozhodněte, zda je požadavek síť, nebo jedna adresa, než cokoli upravíte. Požadavek na jednu adresu ospravedlňuje hostitelskou trasu s komentářem a vlastníkem; služba s rotujícími adresami potřebuje směrování založené na doméně nebo poctivé rozhodnutí o podsíti.

Odstraňujte záznamy, které už neodpovídají skutečnému cíli, a ty, které si ponecháte, poznamenejte. Nevysvětlená /32 je za tři měsíce nerozeznatelná od chyby a další člověk ji smaže, aniž by věděl, co na ní záviselo.