Hvorfor en lokal rute slår VPN'ens standardrute

Printeren på skrivebordet bliver ved med at virke, efter tunnelen er oppe, mens en server på det andet kontor stille opløses til noget lokalt. Begge adfærd kommer fra samme regel: den mest specifikke rute vinder, og et direkte tilsluttet præfiks er så specifikt, som det bliver. Det er som regel det design, du vil have, og det er også sådan et duplikat privat område stjæler en fjernadresse. Læser du kernens valg først, bliver en mystisk fejl til en præfikssammenligning.

Et tilsluttet præfiks er mere specifikt end en standardrute

En tunnel installerer typisk en standardrute eller et sæt præfikser, mens en lokal grænseflade bærer et tilsluttet præfiks plus en rute til hele LAN'et. Det længste præfiks afgør det, så en destination inde i LAN-præfikset når aldrig tunnelen. Derfor forbliver en printer, en routers administrationsside og en lokal NAS tilgængelige, mens VPN'et er oppe. Det er også derfor en fjernressource i et overlappende område går til den forkerte maskine.

Privat adresseområde er ikke unikt, og at to steder vælger samme præfiks er almindeligt nok at planlægge efter. Når områderne overlapper, kommer det lokale svar hurtigt og virker autoritativt, så fejlen læses let som et loginproblem. Destinationen svarede faktisk, bare ikke den, du mente.

Læs det valg, kernen ville træffe

Spørg kernen, hvilken rute den ville bruge til den præcise destination, i stedet for at læse tabellen fra toppen. Led derefter efter politikregler, der kan vælge en anden tabel. To kommandoer besvarer begge spørgsmål på få sekunder.

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

Det første output angiver grænsefladen, næste hop og kildeadressen, som kernen ville bruge, og det er det svar, der betyder noget. En dev-værdi, der peger på den lokale bro, betyder, at pakken aldrig kommer ind i tunnelen, uanset hvad VPN-klientens statuspanel påstår. Den filtrerede tabeloversigt viser, om en anden tabel holder samme præfiks, og regellisten viser den rækkefølge, tabellerne konsulteres i. En politikregel kan sende et præfiks gennem en bestemt tabel selv når hovedtabellen er uenig, så den rækkefølge er en del af svaret.

Lokal adgang er en separat tilladelse

At have en rute er ikke det samme som at have lov til at bruge den. De fleste klienter kan blokere lokal netværkskommunikation, mens tunnelen er oppe, og den indstilling er en politikbeslutning, ikke et routingartefakt. Når en betroet nær tjeneste hører til designet, skal du aktivere den understøttede lokale adgangsmulighed i stedet for at opfinde ruter. Når enheden er på offentligt Wi-Fi, så lad den være slået fra.

De to lag fejler forskelligt. En blokeret lokal vej giver en timeout, selv om ruten findes, mens en overlappende rute giver et svar fra den forkerte vært. At skelne dem koster én forespørgsel og sparer en eftermiddag med firewall-ændringer, og videresendelsesopsætningen er beskrevet i strongSwans noter om videresendelse.

Ret et overlap uden at dynge værtsruter på

En værtsrute til én adresse ser ud til at rette et overlap og fejler i det øjeblik, en anden adresse i samme område er nødvendig. Tyve af dem senere kan ingen sige, hvilket præfiks der er autoritativt. De holdbare løsninger er en ændring af adresseringen, en dokumenteret topologi, der undgår det duplikerede område, eller oversættelse i den ene ende. Hver af dem koster planlægningstid én gang i stedet for vedligeholdelse for evigt.

Hvis en midlertidig værtsrute virkelig er nødvendig, så noter årsagen, ejeren og datoen ved siden af den, så den kan fjernes senere. Test derefter den præcise adresse og tjeneste plus en offentlig destination, for en ændring af lokal adgang, der stille udelukker urelaterede programmer fra tunnelen, er værre end den oprindelige fejl. Hold det lokale præfiks og fjernpræfikset skrevet op hver for sig; den vane forhindrer, at en fungerende lokal ping sendes rundt som bevis for, at det fjerne kontor er tilgængeligt.