Când rutele tunelului divizat se suprapun: ce prefix câștigă

Două profiluri de tunel divizat, două prefixe private și un host pe care ambele îl revendică. Simptomul este rareori o defecțiune curată: un serviciu funcționează luni, expiră după ce al doilea client se reconectează și funcționează din nou după o repornire. Ordinea în care ați conectat clienții nu decide rezultatul, nici ordinea rândurilor din interfața clientului. Efectuați aceste verificări în ordine și opriți-vă la prima care nu se susține, pentru că cele ulterioare au sens doar când cele anterioare sunt adevărate.

1. Notați destinația și sursa

Începeți cu adresa exactă către care merge cererea care eșuează, nu cu numele hostului și nu cu numele aplicației. Rezolvați numele o dată, notați fiecare răspuns și alegeți-l pe cel pe care fluxul care eșuează îl folosește efectiv. Apoi notați adresa locală a aceluiași flux, pentru că adresa sursă poate schimba ce regulă de politică se potrivește și, prin urmare, ce tabel este consultat.

O cerere către unul dintre mai multe înregistrări A poate eșua în timp ce o adresă soră reușește, ceea ce pare un tunel instabil și în realitate sunt două căi diferite. Dacă destinația este un nume cu mai multe răspunsuri, testați fiecare răspuns separat înainte de a schimba ceva.

2. Întrebați nucleul ce rută a ales

Nu citiți tabela de rute și nu deduceți răspunsul. Puneți aceeași întrebare pe care o pune stiva, cu aceeași adresă sursă: ip route get 10.20.4.10 from 10.8.0.2 pe Linux sau Find-NetRoute -RemoteIPAddress 10.20.4.10 în PowerShell. Rezultatul numește ruta care ar fi folosită efectiv, iar aceasta nu este adesea cea la care vă așteptați citind tabela.

Dintre rutele care se potrivesc, de obicei câștigă prefixul mai specific: un /24 bate un /16 pentru o adresă aflată în ambele. Între potriviri de aceeași lungime câștigă metrica mai mică, iar o rută instalată pe un link care este oprit este ignorată. Două tuneluri care anunță același /24 cu aceeași metrică sunt alt caz: nucleul păstrează ambele rute și alege între ele, așa că rezultatul poate alterna în loc să urmeze ordinea în care s-au conectat clienții. Exact această situație produce tiparul luni funcționează și marți eșuează, iar reconectarea într-o altă ordine nu îl schimbă.

3. Verificați dacă o regulă de politică a redirecționat căutarea

Înainte ca tabela de rute să fie consultată, nucleul parcurge regulile sale de politică. O regulă poate trimite traficul de la o anumită sursă, utilizator sau marcaj de firewall către o tabelă complet diferită, așa că prefixul câștigător din tabela principală poate să nu fie niciodată consultat pentru acel flux. ip rule show le listează în ordinea evaluării, iar ip route show table 100 arată ce conține efectiv tabela selectată.

Aici stau două capcane. O regulă care indică o tabelă goală produce o căutare care cade la regula următoare, așa că regula pare să nu facă nimic. Cealaltă este numărul de prioritate în sine: regulile se citesc în ordine crescătoare, iar valorile încorporate sunt 0 local, 32766 main și 32767 default. O regulă cu număr sub 32767 este consultată înaintea regulii implicite care prinde tot. O regulă cu număr peste 32767 stă în spatele ei și este atinsă doar când nicio tabelă anterioară nu răspunde, ceea ce o rută implicită normală din main împiedică, așa că în practică nu este niciodată atinsă și nu face nimic în tăcere în timp ce pare instalată. Dacă clientul a scris o regulă și o rută, verificați-le pe ambele și verificați-le din nou după o reconectare, pentru că un profil rescris poate adăuga o a doua regulă cu altă prioritate.

4. Separați o egalitate de rutare de un plan de adrese duplicat

Uneori prefixul nu este deloc problema. Două locații care folosesc ambele 192.168.1.0/24 înseamnă că aceeași adresă identifică doi hosturi diferiți și nicio rută nu le poate distinge. O rută către host pentru unul dintre cele două răspunsuri funcționează doar până când cealaltă locație răspunde pentru același nume, iar atunci excepția devine în tăcere chiar defectul.

Indiciul este că adresa de destinație este identică pe ambele căi și doar proprietarul dorit diferă. Aceasta este o decizie de plan de adrese, nu o ajustare de rutare: renumerotați o parte, puneți o parte în spatele unui gateway care traduce sau ajungeți la a doua locație printr-un proxy care își rezolvă propriile nume. Coborârea unei rute implicite sau stivuirea excepțiilor pentru hosturi doar mută coliziunea.

5. Confirmați că rezolvatorul este de acord cu ruta

Un nume care se rezolvă la adresa privată greșită produce toate simptomele unui conflict de rutare și niciuna dintre cauzele lui. Comparați răspunsul pe care îl primește hostul cu adresa pe care destinația o folosește efectiv și verificați ce rezolvator a răspuns. Dacă tunelul împinge un rezolvator, clientul ar trebui să îl instaleze pentru fluxurile care folosesc tunelul; dacă nu, hostul continuă să întrebe rezolvatorul local, care poate răspunde dintr-un domeniu de căutare sau dintr-o înregistrare din cache.

Interogați rezolvatorul direct și notați serverul care a răspuns. Un răspuns din cache cu TTL scurt poate explica și de ce prima cerere după o reconectare se comportă diferit de a cincea.

6. Reconectați, inspectați starea aplicată, apoi testați ambele fluxuri

După o corecție, reconectați și inspectați ce a instalat efectiv clientul în loc să vă bazați pe editorul de profiluri. Recitiți regulile, tabelele și răspunsul ip route get care rezultă. Un al doilea client poate reinstala propria rută la conectare și poate recrea conflictul, motiv pentru care verificarea stării trebuie făcută după ce ultimul client se conectează, nu înainte.

Testați două fluxuri, nu unul: cererea care eșua înainte și o resursă care ar trebui să folosească celălalt tunel. Mutarea întregului trafic privat pe o singură conexiune va face primul test să treacă în timp ce îl rupe pe al doilea, iar doar un test pereche prinde asta. Notați fiecare excepție pe care o păstrați, cu destinația și motivul, ca următoarea persoană să poată distinge o rută către host deliberată de una rămasă.