Keď sa trasy rozdeleného tunela prekrývajú: ktorý prefix vyhrá

Dva profily rozdeleného tunela, dva privátne prefixy a jeden hostiteľ, na ktorý si nárokujú oba. Príznak je málokedy čistá porucha: služba v pondelok funguje, po opätovnom pripojení druhého klienta prestane odpovedať a po reštarte zase funguje. Poradie, v akom ste klientov pripojili, výsledok neurčuje, rovnako ako poradie riadkov v rozhraní klienta. Vykonajte tieto kontroly po poradí a zastavte sa pri prvej, ktorá neplatí, pretože tie ďalšie majú zmysel len vtedy, keď platia tie predchádzajúce.

1. Zapíšte cieľ a zdroj

Začnite presnou adresou, na ktorú neúspešná požiadavka smeruje, nie názvom hostiteľa a nie názvom aplikácie. Preložte meno raz, poznamenajte každú odpoveď a vyberte tú, ktorú neúspešný tok skutočne používa. Potom poznamenajte lokálnu adresu toho istého toku, pretože zdrojová adresa môže zmeniť, ktoré pravidlo politiky sedí, a tým aj to, ktorá tabuľka sa prezerá.

Požiadavka na jeden z niekoľkých záznamov A môže zlyhať, kým susedná adresa uspeje, čo vyzerá ako nestabilný tunel, ale v skutočnosti sú to dve rôzne cesty. Ak je cieľom meno s viacerými odpoveďami, otestujte každú odpoveď samostatne, než čokoľvek zmeníte.

2. Spýtajte sa jadra, ktorú trasu si vybralo

Nečítajte tabuľku trás a neodvodzujte odpoveď. Položte rovnakú otázku, akú kladie zásobník, s tou istou zdrojovou adresou: ip route get 10.20.4.10 from 10.8.0.2 v Linuxe alebo Find-NetRoute -RemoteIPAddress 10.20.4.10 v PowerShelli. Výstup pomenúva trasu, ktorá by sa skutočne použila, a to často nie je tá, ktorú ste pri čítaní tabuľky očakávali.

Medzi zodpovedajúcimi trasami zvyčajne vyhráva konkrétnejší prefix: /24 poráža /16 pre adresu, ktorá leží v oboch. Medzi zhodami rovnakej dĺžky vyhráva nižšia metrika a trasa nainštalovaná na vypnutom prepojení sa preskakuje. Dva tunely, ktoré ohlasujú ten istý /24 s tou istou metrikou, sú iný prípad: jadro si ponechá obe trasy a vyberá medzi nimi, takže výsledok sa môže striedať namiesto toho, aby sledoval poradie pripojenia klientov. Práve tento stav vytvára vzorec v pondelok funguje a v utorok nie, a opätovné pripojenie v inom poradí to nezmení.

3. Skontrolujte, či pravidlo politiky nepresmerovalo vyhľadávanie

Skôr než sa prezrie tabuľka trás, jadro prejde svoje pravidlá politiky. Pravidlo môže poslať prevádzku z daného zdroja, používateľa alebo značky firewallu do úplne inej tabuľky, takže víťazný prefix v hlavnej tabuľke sa pre tento tok nemusí nikdy prezrieť. ip rule show ich vymenúva v poradí vyhodnocovania a ip route show table 100 ukazuje, čo vybraná tabuľka skutočne obsahuje.

Sú tu dve pasce. Pravidlo, ktoré ukazuje na prázdnu tabuľku, vytvorí vyhľadávanie, ktoré prepadne na ďalšie pravidlo, takže pravidlo vyzerá, že nič nerobí. Druhou je samotné číslo priority: pravidlá sa čítajú vzostupne a vstavané hodnoty sú 0 local, 32766 main a 32767 default. Pravidlo s číslom pod 32767 sa prezrie pred predvoleným pravidlom, ktoré zachytí všetko. Pravidlo s číslom nad 32767 stojí za ním a dosiahne sa len vtedy, keď žiadna skoršia tabuľka neodpovie, čomu normálna predvolená trasa v main zabraňuje, takže v praxi sa nikdy nedosiahne a ticho nič nerobí, pričom vyzerá nainštalované. Ak klient zapísal pravidlo aj trasu, skontrolujte oboje a skontrolujte ich znova po opätovnom pripojení, pretože prepísaný profil môže pridať druhé pravidlo s inou prioritou.

4. Oddeľte remízu v trasách od duplikovaného plánu adries

Niekedy prefix vôbec nie je problém. Dve lokality, ktoré obe používajú 192.168.1.0/24, znamenajú, že tá istá adresa označuje dvoch rôznych hostiteľov a žiadna trasa ich nedokáže rozlíšiť. Trasa k hostiteľovi na jednu z dvoch odpovedí funguje len dovtedy, kým druhá lokalita neodpovie za to isté meno, a potom sa z výnimky ticho stane samotná chyba.

Príznakom je, že adresa cieľa je na oboch cestách rovnaká a líši sa iba zamýšľaný vlastník. To je rozhodnutie o pláne adries, nie úprava smerovania: prečíslujte jednu stranu, postavte jednu stranu za bránu, ktorá prekladá, alebo sa k druhej lokalite dostanete cez proxy, ktoré si svoje mená prekladá samo. Zníženie predvolenej trasy alebo kopírovanie výnimiek pre hostiteľov len presúva kolíziu inam.

5. Overte, že prekladač súhlasí s trasou

Meno, ktoré sa preloží na nesprávnu privátnu adresu, vytvára všetky príznaky konfliktu smerovania a žiadnu z jeho príčin. Porovnajte odpoveď, ktorú hostiteľ dostane, s adresou, ktorú cieľ skutočne používa, a skontrolujte, ktorý prekladač odpovedal. Ak tunel pretláča prekladač, klient by ho mal nainštalovať pre toky, ktoré tunel používajú; ak nie, hostiteľ sa naďalej pýta lokálneho prekladača, ktorý môže odpovedať z vyhľadávacej domény alebo z uloženého záznamu.

Spýtajte sa prekladača priamo a poznamenajte server, ktorý odpovedal. Odpoveď v medzipamäti s krátkym TTL môže tiež vysvetliť, prečo sa prvá požiadavka po opätovnom pripojení správa inak ako piata.

6. Pripojte sa znova, prezrite uplatnený stav a potom otestujte oba toky

Po oprave sa pripojte znova a prezrite, čo klient skutočne nainštaloval, namiesto dôvery v editor profilov. Prečítajte si znova pravidlá, tabuľky a výslednú odpoveď ip route get. Druhý klient môže pri pripojení preinštalovať svoju vlastnú trasu a konflikt znova vytvoriť, a preto kontrola stavu musí prebehnúť po pripojení posledného klienta, nie pred ním.

Testujte dva toky, nie jeden: požiadavku, ktorá predtým zlyhávala, a zdroj, ktorý by mal používať druhý tunel. Presun všetkej privátnej prevádzky na jedno pripojenie nechá prvý test prejsť, ale rozbije druhý, a to zachytí len párový test. Zapíšte každú výnimku, ktorú ponecháte, s cieľom a dôvodom, aby ďalší človek dokázal rozlíšiť zámernú trasu k hostiteľovi od zvyškovej.