Når ruter i delt tunnel overlapper: hvilket præfiks vinder

To profiler med delt tunnel, to private præfikser og én vært, som begge gør krav på. Symptomet er sjældent en ren fejl: en tjeneste virker om mandagen, timer ud efter at den anden klient har genoprettet forbindelsen, og virker igen efter en genstart. Den rækkefølge, du koblede klienterne i, afgør ikke resultatet, og det gør rækkefølgen af rækkerne i klientens brugerflade heller ikke. Kør disse kontroller i rækkefølge, og stop ved den første, der ikke holder, for de senere giver kun mening, når de tidligere er sande.

1. Skriv destinationen og kilden ned

Begynd med den præcise adresse, som den fejlende anmodning går til, ikke værtsnavnet og ikke programmets navn. Opløs navnet én gang, notér hvert svar, og vælg det, som det fejlende flow faktisk bruger. Notér derefter den lokale adresse for samme flow, for kildeadressen kan ændre, hvilken politikregel der matcher og dermed, hvilken tabel der slås op i.

En anmodning til én af flere A-poster kan fejle, mens en søsteradresse lykkes, hvilket ligner en ustabil tunnel, men i virkeligheden er to forskellige veje. Hvis destinationen er et navn med flere svar, skal du teste hvert svar for sig, før du ændrer noget.

2. Spørg kernen, hvilken rute den valgte

Læs ikke rutetabellen og udled ikke svaret. Stil det samme spørgsmål, som stakken stiller, med den 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. Outputtet angiver den rute, der faktisk ville blive brugt, og det er ofte ikke den, du forventede ved at læse tabellen.

Blandt ruter, der matcher, vinder det mere specifikke præfiks normalt: et /24 slår et /16 for en adresse, der ligger i begge. Mellem match af samme længde vinder den lavere metrik, og en rute, der er installeret på et link, som er nede, springes over. To tunneler, der skubber det samme /24 med samme metrik, er et andet tilfælde: kernen beholder begge ruter og vælger mellem dem, så resultatet kan skifte i stedet for at følge den rækkefølge, klienterne koblede i. Det er præcis den situation, der giver mønstret virker om mandagen og fejler om tirsdagen, og det ændrer sig ikke ved at genoprette forbindelsen i en anden rækkefølge.

3. Kontrollér, om en politikregel omdirigerede opslaget

Før rutetabellen slås op, gennemgår kernen sine politikregler. En regel kan sende trafik fra en given kilde, bruger eller firewall-markering til en helt anden tabel, så det vindende præfiks i hovedtabellen bliver måske aldrig slået op for det flow. ip rule show viser dem i evalueringsrækkefølge, og ip route show table 100 viser, hvad den valgte tabel faktisk indeholder.

Her ligger to fælder. En regel, der peger på en tom tabel, giver et opslag, der falder igennem til den næste regel, så reglen ser ud til ikke at gøre noget. Den anden er selve prioritetsnummeret: regler læses i stigende rækkefølge, og de indbyggede er 0 local, 32766 main og 32767 default. En regel med et nummer under 32767 slås op før standardreglen, der fanger alt. En regel med et nummer over 32767 ligger bag den og nås kun, når ingen tidligere tabel svarer, hvilket en normal standardrute i main forhindrer, så i praksis nås den aldrig og gør lydløst ingenting, mens den ser installeret ud. Hvis klienten har skrevet en regel og en rute, skal du kontrollere begge og kontrollere dem igen efter en genoprettet forbindelse, for en omskrevet profil kan tilføje en anden regel med en anden prioritet.

4. Skel mellem uafgjort routing og en dubleret adresseplan

Nogle gange er præfikset slet ikke problemet. To steder, der begge bruger 192.168.1.0/24, betyder, at den samme adresse identificerer to forskellige værter, og ingen rute kan skelne dem. En værtsrute til et af de to svar virker kun, indtil det andet sted svarer på samme navn, og så bliver undtagelsen stille til fejlen.

Tegnet er, at destinationsadressen er identisk på begge veje, og at kun den tilsigtede ejer er forskellig. Det er en beslutning om adresseplanen, ikke en routingjustering: omnummerér den ene side, sæt den ene side bag en gateway, der oversætter, eller nå det andet sted gennem en proxy, der opløser sine egne navne. At sænke en standardrute eller stable værtsundtagelser flytter bare sammenstødet et andet sted hen.

5. Bekræft, at resolveren er enig med ruten

Et navn, der opløses til den forkerte private adresse, giver alle symptomer på en routingkonflikt og ingen af dens årsager. Sammenlign det svar, værten får, med den adresse, destinationen faktisk bruger, og kontrollér, hvilken resolver der svarede. Hvis tunnelen skubber en resolver, bør klienten installere den for de flows, der bruger tunnelen; hvis ikke, bliver værten ved med at spørge den lokale resolver, som kan svare fra et søgedomæne eller en cachet post.

Spørg resolveren direkte, og notér den server, der svarede. Et cachet svar med en kort TTL kan også forklare, hvorfor den første anmodning efter en genoprettet forbindelse opfører sig anderledes end den femte.

6. Genopret forbindelsen, undersøg den anvendte tilstand, og test derefter begge flows

Efter en rettelse skal du genoprette forbindelsen og undersøge, hvad klienten faktisk installerede, i stedet for at stole på profileditoren. Læs reglerne, tabellerne og det resulterende ip route get-svar igen. En anden klient kan geninstallere sin egen rute ved forbindelse og genskabe konflikten, og derfor skal tilstandskontrollen ske, efter den sidste klient har forbundet, ikke før.

Test to flows, ikke ét: den anmodning, der før fejlede, og en ressource, som skal bruge den anden tunnel. At flytte al privat trafik over på én forbindelse får den første test til at bestå, mens den ødelægger den anden, og kun en parret test fanger det. Notér hver undtagelse, du beholder, med destination og begrundelse, så den næste person kan skelne en bevidst værtsrute fra en efterladt.