Hvorfor en lokal rute slår VPN-ens standardrute

Skriveren på pulten fortsetter å virke etter at tunnelen er oppe, mens en server på det andre kontoret stille løses opp til noe lokalt. Begge atferdene kommer fra samme regel: den mest spesifikke ruten vinner, og et direkte tilkoblet prefiks er så spesifikt som det kan bli. Det er vanligvis designet du vil ha, og det er også slik et duplikat privatområde stjeler en ekstern adresse. Leser du kjernens valg først, blir en mystisk feil til en prefikssammenligning.

Et tilkoblet prefiks er mer spesifikt enn en standardrute

En tunnel installerer vanligvis en standardrute eller et sett med prefikser, mens et lokalt grensesnitt bærer et tilkoblet prefiks pluss en rute til hele LAN-et. Mellom dem avgjør den lengste prefiksmatchingen, så en destinasjon inne i LAN-prefikset når aldri tunnelen. Derfor forblir en skriver, administrasjonssiden til en ruter og en lokal NAS tilgjengelige mens VPN-en er oppe. Det er også derfor en ekstern ressurs i et overlappende område går til feil maskin.

Privat adresseområde er ikke unikt, og at to steder velger samme prefiks er vanlig nok til å planlegge for. Når områdene overlapper, kommer det lokale svaret raskt og virker autoritativt, så feilen leses lett som et innloggingsproblem. Destinasjonen svarte, bare ikke den du mente.

Les valget kjernen ville tatt

Spør kjernen hvilken rute den ville brukt for den nøyaktige destinasjonen i stedet for å lese tabellen fra toppen. Se deretter etter policyregler som kan velge en annen tabell. To kommandoer svarer på begge spørsmålene på noen sekunder.

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

Den første utskriften navngir grensesnittet, neste hopp og kildeadressen kjernen ville brukt, og det er svaret som betyr noe. En dev-verdi som peker på den lokale broen betyr at pakken aldri går inn i tunnelen, uansett hva statuspanelet til VPN-klienten påstår. Den filtrerte tabelloversikten viser om en annen tabell holder samme prefiks, og regellisten viser rekkefølgen disse tabellene konsulteres i. En policyregel kan sende et prefiks gjennom en bestemt tabell selv når hovedtabellen er uenig, så den rekkefølgen er en del av svaret.

Lokal tilgang er en egen tillatelse

Å ha en rute er ikke det samme som å ha lov til å bruke den. De fleste klienter kan blokkere lokal nettverkskommunikasjon mens tunnelen er oppe, og den innstillingen er en policybeslutning, ikke et rutingartefakt. Når en klarert tjeneste i nærheten hører hjemme i designet, slå på det støttede lokal tilgang-alternativet i stedet for å finne opp ruter. Når enheten er på offentlig Wi-Fi, la den være av.

De to lagene feiler ulikt. En blokkert lokal vei gir tidsavbrudd selv om ruten finnes, mens en overlappende rute gir et svar fra feil vert. Å skille dem koster én spørring og sparer en ettermiddag med brannmur-endringer, og videresendingsordningen er beskrevet i strongSwans notater om videresending.

Rett opp en overlapp uten å stable vertsruter

En vertsrute for én adresse ser ut til å rette opp en overlapp og feiler i det øyeblikket en annen adresse i samme område trengs. Tjue av dem senere kan ingen si hvilket prefiks som er autoritativt. De varige løsningene er en endring av adressering, en dokumentert topologi som unngår det dupliserte området, eller oversettelse i den ene enden. Hver av dem koster planleggingstid én gang i stedet for vedlikehold for alltid.

Hvis en midlertidig vertsrute virkelig er nødvendig, noter årsaken, eieren og datoen ved siden av den, slik at den kan fjernes senere. Test deretter den nøyaktige adressen og tjenesten pluss en offentlig destinasjon, fordi en endring i lokal tilgang som stille utelukker urelaterte programmer fra tunnelen er verre enn den opprinnelige feilen. Hold det lokale prefikset og det eksterne prefikset skrevet opp hver for seg; den vanen hindrer at en fungerende lokal ping sendes rundt som bevis for at det eksterne kontoret er tilgjengelig.