När rutter i delad tunnel överlappar: vilket prefix vinner

Två profiler för delad tunnel, två privata prefix och en värd som båda gör anspråk på. Symtomet är sällan ett rent fel: en tjänst fungerar på måndagen, tidsgränsen slås ut efter att den andra klienten ansluter igen och den fungerar igen efter omstart. Ordningen du anslöt klienterna i avgör inte resultatet, och inte heller ordningen på raderna i klientens gränssnitt. Kör dessa kontroller i ordning och stanna vid den första som inte håller, eftersom de senare bara är meningsfulla när de tidigare är sanna.

1. Skriv ned destinationen och källan

Börja med den exakta adressen som den misslyckade begäran går till, inte värdnamnet och inte programnamnet. Slå upp namnet en gång, notera varje svar och välj det som det misslyckade flödet faktiskt använder. Notera sedan den lokala adressen för samma flöde, eftersom källadressen kan ändra vilken policyregel som matchar och därmed vilken tabell som slås upp.

En begäran till en av flera A-poster kan misslyckas medan en systeradress lyckas, vilket ser ut som en instabil tunnel men egentligen är två olika vägar. Om destinationen är ett namn med flera svar, testa varje svar för sig innan du ändrar något.

2. Fråga kärnan vilken rutt den valde

Läs inte routingtabellen och härled inte svaret. Ställ samma fråga som stacken ställer, med samma källadress: 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 namnger rutten som faktiskt skulle användas, och det är ofta inte den du förväntade dig när du läste tabellen.

Bland rutter som matchar vinner vanligtvis det mer specifika prefixet: ett /24 slår ett /16 för en adress som ligger i båda. Mellan matchningar av samma längd vinner den lägre metriken, och en rutt som är installerad på en länk som är nere hoppas över. Två tunnlar som annonserar samma /24 med samma metrik är ett annat fall: kärnan behåller båda rutterna och väljer mellan dem, så resultatet kan växla i stället för att följa ordningen som klienterna anslöt i. Det är precis den situation som ger mönstret måndag-fungerar-tisdag-faller, och det ändras inte av att ansluta igen i en annan ordning.

3. Kontrollera om en policyregel omdirigerade uppslaget

Innan routingtabellen slås upp går kärnan igenom sina policyregler. En regel kan skicka trafik från en viss källa, användare eller brandväggsmarkering till en helt annan tabell, så det vinnande prefixet i huvudtabellen kanske aldrig slås upp för det flödet. ip rule show listar dem i utvärderingsordning, och ip route show table 100 visar vad den valda tabellen faktiskt innehåller.

Här finns två fällor. En regel som pekar på en tom tabell ger ett uppslag som faller igenom till nästa regel, så regeln verkar inte göra något. Den andra är själva prioritetsnumret: regler läses i stigande ordning, och de inbyggda värdena är 0 local, 32766 main och 32767 default. En regel med nummer under 32767 slås upp före standardregeln som fångar allt. En regel med nummer över 32767 ligger bakom den och nås bara när ingen tidigare tabell svarar, vilket en vanlig standardrutt i main förhindrar, så i praktiken nås den aldrig och gör tyst ingenting medan den ser installerad ut. Om klienten skrev en regel och en rutt, kontrollera båda, och kontrollera dem igen efter en ny anslutning, eftersom en omskriven profil kan lägga till en andra regel med en annan prioritet.

4. Skilj på oavgjort routing och en dubblerad adressplan

Ibland är prefixet inte alls problemet. Två platser som båda använder 192.168.1.0/24 innebär att samma adress identifierar två olika värdar, och ingen rutt kan skilja dem åt. En värdrutt till ett av de två svaren fungerar bara tills den andra platsen svarar på samma namn, och då blir undantaget tyst själva felet.

Tecknet är att destinationsadressen är identisk på båda vägarna och att bara den avsedda ägaren skiljer sig. Det är ett beslut om adressplanen, inte en routingjustering: numrera om ena sidan, sätt ena sidan bakom en gateway som översätter, eller nå den andra platsen via en proxy som löser upp sina egna namn. Att sänka en standardrutt eller stapla värdundantag flyttar bara kollisionen.

5. Bekräfta att resolvern håller med rutten

Ett namn som löses upp till fel privata adress ger alla symtom på en routingkonflikt och ingen av dess orsaker. Jämför svaret som värden får med adressen som destinationen faktiskt använder, och kontrollera vilken resolver som svarade. Om tunneln skjuter in en resolver bör klienten installera den för de flöden som använder tunneln; om inte fortsätter värden att fråga den lokala resolvern, som kan svara från en sökdomän eller en cachad post.

Fråga resolvern direkt och notera servern som svarade. Ett cachat svar med kort TTL kan också förklara varför den första begäran efter en ny anslutning beter sig annorlunda än den femte.

6. Anslut igen, granska det tillämpade tillståndet och testa sedan båda flödena

Efter en rättelse, anslut igen och granska vad klienten faktiskt installerade i stället för att lita på profilredigeraren. Läs reglerna, tabellerna och det resulterande ip route get-svaret igen. En andra klient kan installera om sin egen rutt vid anslutning och återskapa konflikten, och därför måste tillståndskontrollen ske efter att den sista klienten anslutit, inte före.

Testa två flöden, inte ett: begäran som tidigare misslyckades, och en resurs som ska använda den andra tunneln. Att flytta all privat trafik till en enda anslutning får det första testet att gå igenom samtidigt som det bryter det andra, och bara ett parat test fångar det. Notera varje undantag du behåller, med destination och skäl, så att nästa person kan skilja en avsiktlig värdrutt från en kvarvarande.