Når ruter i delt tunnel overlapper: hvilket prefiks vinner

To profiler for delt tunnel, to private prefikser og én vert som begge gjør krav på. Symptomet er sjelden en ren feil: en tjeneste virker på mandag, timer ut etter at den andre klienten kobler til på nytt, og virker igjen etter omstart. Rekkefølgen du koblet klientene i, avgjør ikke resultatet, og det gjør heller ikke rekkefølgen av radene i klientens grensesnitt. Kjør disse kontrollene i rekkefølge, og stopp ved den første som ikke holder, for de senere gir bare mening når de tidligere er sanne.

1. Skriv ned destinasjonen og kilden

Begynn med den nøyaktige adressen den feilende forespørselen går til, ikke vertsnavnet og ikke programnavnet. Løs opp navnet én gang, noter hvert svar og velg det den feilende flyten faktisk bruker. Noter deretter den lokale adressen til samme flyt, for kildeadressen kan endre hvilken policyregel som passer og dermed hvilken tabell som slås opp.

En forespørsel til én av flere A-poster kan feile mens en søsteradresse lykkes, noe som ser ut som en ustabil tunnel, men egentlig er to forskjellige veier. Hvis destinasjonen er et navn med flere svar, test hvert svar hver for seg før du endrer noe.

2. Spør kjernen hvilken rute den valgte

Ikke les rutetabellen og utled svaret. Still det samme spørsmålet som stakken stiller, med samme kildeadresse: ip route get 10.20.4.10 from 10.8.0.2 på Linux, eller Find-NetRoute -RemoteIPAddress 10.20.4.10 i PowerShell. Utdata navngir ruten som faktisk ville blitt brukt, og det er ofte ikke den du forventet ved å lese tabellen.

Blant rutene som samsvarer, vinner vanligvis det mer spesifikke prefikset: et /24 slår et /16 for en adresse som ligger i begge. Mellom samsvar av samme lengde vinner den lavere metrikken, og en rute installert på en lenke som er nede hoppes over. To tunneler som skyver det samme /24 med samme metrikk er et annet tilfelle: kjernen beholder begge rutene og velger mellom dem, så resultatet kan veksle i stedet for å følge rekkefølgen klientene koblet til i. Det er nettopp denne situasjonen som gir mønsteret mandag virker og tirsdag feiler, og det endres ikke av å koble til på nytt i en annen rekkefølge.

3. Sjekk om en policyregel omdirigerte oppslaget

Før rutetabellen slås opp, går kjernen gjennom policyreglene sine. En regel kan sende trafikk fra en gitt kilde, bruker eller brannmurmarkering til en helt annen tabell, så det vinnende prefikset i hovedtabellen blir kanskje aldri slått opp for den flyten. ip rule show lister dem i evalueringsrekkefølge, og ip route show table 100 viser hva den valgte tabellen faktisk inneholder.

Her ligger to feller. En regel som peker på en tom tabell gir et oppslag som faller gjennom til neste regel, så regelen ser ut til ikke å gjøre noe. Den andre er selve prioritetsnummeret: regler leses i stigende rekkefølge, og de innebygde verdiene er 0 local, 32766 main og 32767 default. En regel med nummer under 32767 slås opp før standardregelen som fanger alt. En regel med nummer over 32767 ligger bak den og nås bare når ingen tidligere tabell svarer, noe en vanlig standardrute i main forhindrer, så i praksis nås den aldri og gjør stilltiende ingenting mens den ser installert ut. Hvis klienten skrev en regel og en rute, sjekk begge, og sjekk dem igjen etter ny tilkobling, for en omskrevet profil kan legge til en andre regel med en annen prioritet.

4. Skill uavgjort ruting fra en duplisert adresseplan

Noen ganger er prefikset ikke problemet i det hele tatt. To steder som begge bruker 192.168.1.0/24 betyr at samme adresse identifiserer to forskjellige verter, og ingen rute kan skille dem. En vertsrute til ett av de to svarene virker bare til det andre stedet svarer på samme navn, og da blir unntaket stilltiende selve feilen.

Tegnet er at destinasjonsadressen er identisk på begge veier og at bare den tiltenkte eieren er forskjellig. Det er en beslutning om adresseplanen, ikke en rutingjustering: omnummerer den ene siden, sett den ene siden bak en gateway som oversetter, eller nå det andre stedet gjennom en proxy som løser opp sine egne navn. Å senke en standardrute eller stable vertsunntak flytter bare kollisjonen.

5. Bekreft at resolveren er enig med ruten

Et navn som løses opp til feil privat adresse gir alle symptomene på en rutingkonflikt og ingen av årsakene. Sammenlign svaret verten får med adressen destinasjonen faktisk bruker, og sjekk hvilken resolver som svarte. Hvis tunnelen skyver en resolver, bør klienten installere den for flytene som bruker tunnelen; hvis ikke, fortsetter verten å spørre den lokale resolveren, som kan svare fra et søkedomene eller en bufret post.

Spør resolveren direkte og noter serveren som svarte. Et bufret svar med kort TTL kan også forklare hvorfor den første forespørselen etter ny tilkobling oppfører seg annerledes enn den femte.

6. Koble til på nytt, undersøk den anvendte tilstanden, og test deretter begge flytene

Etter en rettelse, koble til på nytt og undersøk hva klienten faktisk installerte i stedet for å stole på profilredigereren. Les reglene, tabellene og det resulterende ip route get-svaret på nytt. En annen klient kan installere sin egen rute på nytt ved tilkobling og gjenopprette konflikten, og derfor må tilstandskontrollen skje etter at den siste klienten har koblet til, ikke før.

Test to flyter, ikke én: forespørselen som før feilet, og en ressurs som skal bruke den andre tunnelen. Å flytte all privat trafikk over på én forbindelse får den første testen til å bestå mens den ødelegger den andre, og bare en paret test fanger det opp. Noter hvert unntak du beholder, med destinasjon og begrunnelse, slik at neste person kan skille en bevisst vertsrute fra en som er igjen.