Když se trasy rozděleného tunelu překrývají: který prefix vyhraje

Dva profily rozděleného tunelu, dva privátní prefixy a jeden hostitel, na který si nárokují oba. Příznak málokdy bývá čistá porucha: služba v pondělí funguje, po opětovném připojení druhého klienta přestane odpovídat a po restartu zase funguje. Pořadí, v jakém jste klienty připojili, výsledek neurčuje, stejně jako pořadí řádků v rozhraní klienta. Proveďte tyto kontroly popořadě a zastavte se u první, která neplatí, protože ty další mají smysl jen tehdy, když platí ty předchozí.

1. Zapište cíl a zdroj

Začněte přesnou adresou, na kterou neúspěšný požadavek míří, ne názvem hostitele a ne názvem aplikace. Přeložte jméno jednou, poznamenejte každou odpověď a vyberte tu, kterou neúspěšný tok skutečně používá. Potom poznamenejte lokální adresu téhož toku, protože zdrojová adresa může změnit, které pravidlo zásad odpovídá, a tím i to, která tabulka se prohlíží.

Požadavek na jeden z několika záznamů A může selhat, zatímco sousední adresa uspěje, což vypadá jako nestabilní tunel, ale ve skutečnosti jde o dvě různé cesty. Pokud je cílem jméno s několika odpověďmi, otestujte každou odpověď zvlášť, než cokoli změníte.

2. Zeptejte se jádra, kterou trasu zvolilo

Nečtěte tabulku tras a neodvozujte odpověď. Položte stejnou otázku, kterou klade zásobník, se stejnou zdrojovou adresou: ip route get 10.20.4.10 from 10.8.0.2 v Linuxu nebo Find-NetRoute -RemoteIPAddress 10.20.4.10 v PowerShellu. Výstup uvádí trasu, která by se skutečně použila, a ta často není ta, kterou jste při čtení tabulky čekali.

Mezi odpovídajícími trasami obvykle vyhrává konkrétnější prefix: /24 poráží /16 pro adresu uvnitř obou. Mezi shodami stejné délky vyhrává nižší metrika a trasa nainstalovaná na vypnutém rozhraní se přeskakuje. Dva tunely protlačující stejný /24 se stejnou metrikou jsou jiný případ: jádro si ponechá obě trasy a vybírá mezi nimi, takže výsledek se může střídat, místo aby sledoval pořadí, v jakém se klienti připojili. To je přesně situace, která vytváří vzorec v pondělí funguje a v úterý ne, a opětovné připojení v jiném pořadí to nezmění.

3. Zkontrolujte, zda vyhledávání nepřesměrovalo pravidlo zásad

Než se prohlédne tabulka tras, projde jádro svá pravidla zásad. Pravidlo může poslat provoz z daného zdroje, uživatele nebo značky firewallu do úplně jiné tabulky, takže vítězný prefix v hlavní tabulce se pro tento tok nemusí nikdy prohlédnout. ip rule show je vypisuje v pořadí vyhodnocování a ip route show table 100 ukazuje, co vybraná tabulka skutečně obsahuje.

Jsou tu dvě pasti. Pravidlo, které ukazuje na prázdnou tabulku, vytvoří vyhledávání, jež propadne na další pravidlo, takže pravidlo vypadá, že nic nedělá. Druhou je samo číslo priority: pravidla se čtou vzestupně a vestavěné hodnoty jsou 0 local, 32766 main a 32767 default. Pravidlo s číslem pod 32767 se prohlédne před výchozím pravidlem, které zachytí vše. Pravidlo s číslem nad 32767 stojí za ním a dosáhne se jen tehdy, když žádná dřívější tabulka neodpoví, čemuž normální výchozí trasa v main zabrání, takže se v praxi nikdy nedosáhne a tiše nic nedělá, zatímco vypadá nainstalované. Pokud klient zapsal pravidlo i trasu, zkontrolujte obojí a zkontrolujte je znovu po opětovném připojení, protože přepsaný profil může přidat druhé pravidlo s jinou prioritou.

4. Oddělte remízu v trasách od duplikovaného plánu adres

Někdy prefix vůbec není problém. Dvě lokality, které obě používají 192.168.1.0/24, znamenají, že stejná adresa označuje dva různé hostitele a žádná trasa je nerozliší. Trasa k hostiteli na jednu ze dvou odpovědí funguje jen do chvíle, než druhá lokalita odpoví na stejné jméno, a pak se z výjimky tiše stane chyba.

Příznakem je, že adresa cíle je na obou cestách stejná a liší se jen zamýšlený vlastník. To je rozhodnutí o plánu adres, ne úprava směrování: přečíslujte jednu stranu, postavte jednu stranu za bránu, která překládá, nebo se k druhé lokalitě dostáhněte přes proxy, které si svá jména překládá samo. Snížení výchozí trasy nebo vršení výjimek pro hostitele jen přesouvá kolizi jinam.

5. Ověřte, že překladač souhlasí s trasou

Jméno, které se přeloží na špatnou privátní adresu, vytváří všechny příznaky konfliktu směrování a žádnou z jeho příčin. Porovnejte odpověď, kterou hostitel dostane, s adresou, kterou cíl skutečně používá, a zkontrolujte, který překladač odpověděl. Pokud tunel protlačuje překladač, klient by ho měl nainstalovat pro toky, které tunel používají; pokud ne, hostitel se dál ptá lokálního překladače, který může odpovědět z vyhledávací domény nebo z uloženého záznamu.

Zeptejte se překladače přímo a poznamenejte server, který odpověděl. Odpověď v mezipaměti s krátkým TTL také může vysvětlit, proč se první požadavek po opětovném připojení chová jinak než pátý.

6. Připojte se znovu, prohlédněte uplatněný stav a potom otestujte oba toky

Po opravě se připojte znovu a prohlédněte, co klient skutečně nainstaloval, místo abyste věřili editoru profilů. Přečtěte si znovu pravidla, tabulky a výslednou odpověď ip route get. Druhý klient může při připojení přeinstalovat svou vlastní trasu a konflikt obnovit, a proto kontrola stavu musí proběhnout po připojení posledního klienta, ne před ním.

Testujte dva toky, ne jeden: požadavek, který dřív selhával, a zdroj, který má používat druhý tunel. Přesun veškerého privátního provozu na jedno připojení nechá první test projít, ale rozbije druhý, a to zachytí jen párový test. Zapište každou výjimku, kterou ponecháte, s cílem a důvodem, aby další člověk rozeznal záměrnou trasu k hostiteli od zbytkové.