Proč se smazaná trasa VPN vrací po opětovném připojení

Trasa, kterou jste smazali ručně, je po dalším opětovném připojení zpět a tabulka vypadá přesně jako předtím. Není to chyba směrování: něco znovu vytváří záznam z konfigurace nebo z akce životního cyklu připojení. Většina runbooků končí u živé tabulky, a proto se zdá, že smazání funguje minutu, a pak selže. Určete vlastníka, změňte ho a dokažte to při opětovném připojení.

Kdo trasu nainstaloval

Začněte seznamem kandidátů, ne opravou. Profil VPN může nést vlastní trasy, server je může odesílat při připojení, profil správce sítě je může deklarovat, bootovací jednotka nebo skript je může přidat a implementace IPsec instalují trasy pro selektory provozu, které vyjednají. Pravidla směrování podle politiky mohou také přesměrovat provoz úplně do jiné tabulky.

Čas je oddělí rychleji než konfigurační archeologie. Záznam, který se objeví v okamžiku, kdy rozhraní naskočí, patří klientovi; ten, který dorazí o sekundu později, obvykle přišel z push serveru; ten, který existuje při bootu, patří uložené konfiguraci. Zaznamenejte tabulku před a po připojení, odpojení a restartu a vzor pojmenuje vlastníka. Trasa, která se vrací jen při restartu služby, ukazuje na jednotku, ne na VPN.

Přečtěte si tabulku, než ji upravíte

Podívejte se na vlastní pohled jádra, ne na uložený soubor. Sloupec protokolu ukazuje, co každý záznam nainstalovalo:

ip route show
ip route show table all
ip rule show

Pole protokolu, metrika a číslo tabulky vám řeknou, zda se díváte na statický záznam, záznam vytvořený jádrem, nebo na něco, co přidal démon. Výpis pravidel je důležitý, protože vyhledání může úplně opustit hlavní tabulku, což učiní úpravu tam neviditelnou pro aplikaci, kterou ladíte. Přečtěte řádek zleva doprava: cíl, brána, zařízení, protokol a metrika.

Pak se jádra zeptejte, kterou trasu by skutečně použilo. Chráněná adresa je lepší sonda než veřejná:

ip route get 10.20.5.7

Změňte vlastníka, ne symptom

Jakmile je vlastník znám, změna patří jemu. Odeberte trasu z profilu klienta, opravte odesílanou trasu na serveru nebo upravte připojení správce sítě, místo abyste přidávali konkurenční trvalou trasu, která vyhraje metrikou. Dvě pravidla, která proti sobě bojují, vytvoří tabulku, kterou už nikdo nedokáže vysvětlit.

Zachovejte vyloučení koncového bodu. Trasa k hostiteli, která posílá vlastní veřejnou adresu serveru VPN přes fyzickou bránu, je to, co udržuje vnější tunelové pakety v pohybu; smažte ji a tunel se pokusí nést sám sebe. U profilu rozděleného tunelu platí stejná péče pro místní podsítě, které mají tunel obejít.

Znovu se připojte a ověřte obě cesty

Znovu se připojte a pak zkontrolujte obě cíle v jednom průchodu. Chráněná adresa a vyloučený koncový bod odpovídají na různé otázky:

ip route get 10.20.5.7
ip route get 198.51.100.20

První by se měla vyřešit přes tunelové rozhraní a druhá přes fyzickou bránu. Pokud se obě vyřeší přes tunel, vyloučení chybí; pokud ani jedna, změna profilu se neprojevila a díváte se na jiného vlastníka, než jste mysleli.

Zapište účel trasy, jejího vlastníka a jak dlouho má žít. Tato poznámka je to, co zabrání dalšímu člověku zopakovat stejný cyklus smazání a opětovného připojení.