Varför en lokal rutt slår VPN:ens standardrutt

Skrivaren på skrivbordet fortsätter att fungera efter att tunneln kommit upp, medan en server på det andra kontoret tyst löses upp till något lokalt. Båda beteendena kommer från samma regel: den mest specifika rutten vinner, och ett direkt anslutet prefix är så specifikt det kan bli. Det är oftast designen du vill ha, och det är också så ett duplicerat privat område stjäl en fjärradress. Läser du kernens val först blir ett mystiskt fel en prefixjämförelse.

Ett anslutet prefix är mer specifikt än en standardrutt

En tunnel installerar vanligtvis en standardrutt eller en uppsättning prefix, medan ett lokalt gränssnitt bär ett anslutet prefix plus en rutt till hela LAN:et. Mellan dem avgör den längsta prefixmatchningen, så en destination inne i LAN-prefixet når aldrig tunneln. Därför förblir en skrivare, en routers administrationssida och en lokal NAS nåbara medan VPN:en är uppe. Det är också därför en fjärrresurs i ett överlappande område går till fel maskin.

Privat adressutrymme är inte unikt, och att två platser väljer samma prefix är vanligt nog att planera för. När områdena överlappar kommer det lokala svaret snabbt och verkar auktoritativt, så felet läses lätt som ett inloggningsproblem. Destinationen svarade, bara inte den du menade.

Läs det val som kärnan skulle göra

Fråga kärnan vilken rutt den skulle använda för den exakta destinationen i stället för att läsa tabellen uppifrån. Leta sedan efter policyregler som kan välja en annan tabell. Två kommandon svarar på båda frågorna på några sekunder.

ip route get 10.20.30.41
ip route show table all | grep -E '10\.|default'
ip rule show

Den första utskriften namnger gränssnittet, nästa hopp och källadressen som kärnan skulle använda, och det är svaret som betyder något. Ett dev-värde som pekar på den lokala bryggan betyder att paketet aldrig kommer in i tunneln, vad VPN-klientens statuspanel än påstår. Den filtrerade tabellistan visar om en annan tabell håller samma prefix, och regellistan visar i vilken ordning dessa tabeller konsulteras. En policyregel kan skicka ett prefix genom en viss tabell även när huvudtabellen inte håller med, så den ordningen är en del av svaret.

Lokal åtkomst är ett eget tillstånd

Att ha en rutt är inte samma sak som att ha tillstånd att använda den. De flesta klienter kan blockera lokal nätverkskommunikation medan tunneln är uppe, och den inställningen är ett policybeslut, inte en artefakt av routing. När en betrodd närliggande tjänst hör till designen, slå på det stödda alternativet för lokal åtkomst i stället för att hitta på rutter. När enheten är på ett öppet Wi-Fi, låt den vara av.

De två lagren misslyckas olika. En blockerad lokal väg ger en timeout trots att rutten finns, medan en överlappande rutt ger ett svar från fel värd. Att skilja dem kostar en fråga och sparar en eftermiddag av brandväggsändringar, och vidarebefordringsarrangemanget beskrivs i strongSwans anteckningar om vidarebefordran.

Rätta till en överlappning utan att stapla värdrutter

En värdrutt för en adress verkar rätta till en överlappning och fallerar i samma stund som en andra adress i samma område behövs. Tjugo av dem senare kan ingen säga vilket prefix som är auktoritativt. De varaktiga lösningarna är en ändring av adresseringen, en dokumenterad topologi som undviker det duplicerade området, eller översättning i ena änden. Var och en kostar planeringstid en gång i stället för underhåll för alltid.

Om en tillfällig värdrutt verkligen behövs, notera orsaken, ägaren och datumet bredvid den så att den kan tas bort senare. Testa sedan den exakta adressen och tjänsten plus en offentlig destination, eftersom en ändring av lokal åtkomst som tyst utesluter orelaterade program från tunneln är värre än det ursprungliga felet. Håll det lokala prefixet och fjärrprefixet nedskrivna var för sig; den vanan hindrar en fungerande lokal ping från att skickas runt som bevis för att fjärrkontoret är nåbart.