Når ruter i delt tunnel overlappar: kva prefiks som vinn

To profilar for delt tunnel, to private prefiks og ein vert som begge gjer krav på. Symtomet er sjeldan ein rein feil: ein teneste verkar på måndag, går ut på tid etter at den andre klienten koplar til på nytt, og verkar igjen etter omstart. Rekkjefølgja du kopla klientane i, avgjer ikkje resultatet, og det gjer heller ikkje rekkjefølgja av radene i grensesnittet til klienten. Køyr desse kontrollane i rekkjefølgje, og stopp ved den første som ikkje held, for dei seinare gir berre meining når dei tidlegare er sanne.

1. Skriv ned destinasjonen og kjelda

Byrja med den nøyaktige adressa den feilande førespurnaden går til, ikkje vertsnamnet og ikkje programnamnet. Løys opp namnet ein gong, noter kvart svar og vel det den feilande flyten faktisk brukar. Noter deretter den lokale adressa til same flyt, for kildeadressa kan endre kva policyregel som passar og dermed kva tabell som blir slått opp.

Ein førespurnad til ein av fleire A-postar kan feile medan ei systeradresse lukkast, noko som ser ut som ein ustabil tunnel, men eigentleg er to ulike vegar. Viss destinasjonen er eit namn med fleire svar, test kvart svar kvar for seg før du endrar noko.

2. Spør kjernen kva rute han valde

Ikkje les rutetabellen og leid svaret ut av han. Still det same spørsmålet som stakken stiller, med same 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 namngir ruta som faktisk ville bli brukt, og det er ofte ikkje den du venta ved å lese tabellen.

Blant rutene som samsvarar, vinn vanlegvis det meir spesifikke prefikset: eit /24 slår eit /16 for ei adresse som ligg i begge. Mellom samsvar av same lengd vinn den lågare metrikken, og ei rute installert på ei lenkje som er nede blir hoppa over. To tunnelar som skyv det same /24 med same metrikk er eit anna tilfelle: kjernen held på begge rutene og vel mellom dei, så resultatet kan veksle i staden for å følgje rekkjefølgja klientane kopla til i. Det er nettopp denne situasjonen som gir mønsteret måndag verkar og tysdag feilar, og det blir ikkje endra av å kopie til på nytt i ei anna rekkjefølgje.

3. Sjekk om ein policyregel omdirigerte oppslaget

Før rutetabellen blir slått opp, går kjernen gjennom policyreglane sine. Ein regel kan sende trafikk frå ei gitt kjelde, brukar eller brannmurmarkering til ein heilt annan tabell, så det vinnande prefikset i hovudtabellen blir kanskje aldri slått opp for den flyten. ip rule show listar dei i evalueringsrekkjefølgje, og ip route show table 100 viser kva den valde tabellen faktisk inneheld.

Her ligg to feller. Ein regel som peikar på ein tom tabell gir eit oppslag som fell gjennom til neste regel, så regelen ser ut til å ikkje gjere noko. Den andre er sjølve prioritetsnummeret: reglar blir lesne i stigande rekkjefølgje, og dei innebygde verdiane er 0 local, 32766 main og 32767 default. Ein regel med nummer under 32767 blir slått opp før standardregelen som fangar alt. Ein regel med nummer over 32767 ligg bak han og blir berre nådd når ingen tidlegare tabell svarar, noko ei vanleg standardrute i main hindrar, så i praksis blir han aldri nådd og gjer stilt ingenting medan han ser installert ut. Viss klienten skreiv ein regel og ei rute, sjekk begge, og sjekk dei igjen etter ny tilkopling, for ein omskriven profil kan leggje til ein andre regel med ein annan prioritet.

4. Skil uavgjort ruting frå ein duplisert adresseplan

Nokre gonger er prefikset ikkje problemet i det heile. To stader som begge brukar 192.168.1.0/24 betyr at same adresse identifiserer to ulike vertar, og inga rute kan skilje dei. Ei vertsrute til eitt av dei to svara verkar berre til den andre staden svarar på same namn, og då blir unntaket stilt sjølve feilen.

Teiknet er at destinasjonsadressa er identisk på begge vegane og at berre den tiltenkte eigaren er ulik. Det er eit vedtak om adresseplanen, ikkje ei rutetilpassing: omnummerer den eine sida, set den eine sida bak ein gateway som omset, eller nå den andre staden gjennom ein proxy som løyser opp sine eigne namn. Å senke ei standardrute eller stable vertsunntak flyttar berre kollisjonen.

5. Stadfest at resolvaren er samd med ruta

Eit namn som blir løyst opp til feil privat adresse gir alle symtoma på ein rutekonflikt og ingen av årsakene. Samanlikn svaret verten får med adressa destinasjonen faktisk brukar, og sjekk kva resolvar som svara. Viss tunnelen skyv ein resolvar, bør klienten installere han for flytane som brukar tunnelen; viss ikkje, held verten fram med å spørje den lokale resolvaren, som kan svare frå eit søkjedomene eller ein bufra post.

Spør resolvaren direkte og noter serveren som svara. Eit bufra svar med kort TTL kan også forklare kvifor den første førespurnaden etter ny tilkopling oppfører seg annleis enn den femte.

6. Kopie til på nytt, undersøk den brukte tilstanden, og test deretter begge flytane

Etter ei retting, kopie til på nytt og undersøk kva klienten faktisk installerte i staden for å stole på profilredigeraren. Les reglane, tabellane og det resulterande ip route get-svaret på nytt. Ein annan klient kan installere si eiga rute på nytt ved tilkopling og gjenopprette konflikten, og difor må tilstandskontrollen skje etter at den siste klienten har kopla til, ikkje før.

Test to flytar, ikkje éin: førespurnaden som før feila, og ein ressurs som skal bruke den andre tunnelen. Å flytte all privat trafikk over på éi samband får den første testen til å gå gjennom medan han øydelegg den andre, og berre ein para test fangar det opp. Noter kvart unntak du held på, med destinasjon og grunngiving, slik at neste person kan skilje ei medviten vertsrute frå ei som er att.