Hvorfor en fulltunnel-VPN skjuler de rutede lokale VLAN-ene dine

«Tillat lokalt nettverk»-bryteren i en VPN-klient høres ut som om den dekker alt i bygningen. I praksis legger den vanligvis til noen få unntak for private adresser på tunnelens standardrute og stopper der. Lagrings-VLAN-et ditt er fortsatt bare tilgjengelig hvis en rute for det aktuelle prefikset overlever at tunnelen kommer opp, og på mange klienter gjør den ikke det.

Det er et rutingspørsmål og ikke en VPN-innstilling, noe som er gode nyheter: det har et konkret svar.

Hva «tillat lokalt nettverk» faktisk dekker

Klientene implementerer valget ulikt. Noen legger til ruter for subnettet maskinen er koblet til, noen legger til RFC 1918-områdene, og noen få utelukker bare standardgatewayen. Ingen av dem vet at kontorruteren din også betjener et lagrings-VLAN, et labbsegment eller et skrivernett, fordi disse prefiksene ikke ligger på nettet klienten kan se. Les klientens egen dokumentasjon for den nøyaktige oppførselen i stedet for å anta at etiketten beskriver topologien din.

Forskjellen betyr mest i en fulltunnelkonstruksjon, der klienten bevisst erstatter standardruten slik at all trafikk går gjennom VPN-en. Det er hele poenget med konstruksjonen, og det er også det som får de lokalt rutede nettverkene til å forsvinne. De var aldri dekket av en egen rute; de lå på standardruten som nettopp er erstattet. En klient kan ikke rute det den ikke vet eksisterer, og den lærer bare om prefikser som er knyttet til sitt eget grensesnitt. Alt annet må beskrives av noen som kjenner topologien.

Tilkoblede ruter stopper ved den første ruteren

En arbeidsstasjon på 192.168.10.20/24 med gateway 192.168.10.1 får automatisk en tilkoblet rute for 192.168.10.0/24. Lagrings-VLAN-et på 192.168.20.0/24 er et annet prefiks, bare tilgjengelig gjennom den gatewayen, og arbeidsstasjonen har ingen rute for det utover standardruten. Før tunnelen kommer opp, sender den vanlige standardruten lagringstrafikk til 192.168.10.1, og alt fungerer.

Når VPN-en installerer en fulltunnelstandard, følger pakkene for 192.168.20.1 den nye standardruten inn i tunnelen. Den eksterne gatewayen aner ikke hvor det prefikset bor, så den slipper dem eller videresender dem et ubrukelig sted. Ingenting var feilkonfigurert på lagrings-VLAN-et; banen var lånt, og lånet ble krevd tilbake.

Fristelsen er å gripe til et bredt unntak, for eksempel et /1-rutepar eller en ekstra standardrute. Motstå den. Jo smalere unntaket er, jo lettere er det å forklare, revidere og fjerne når nettet endres.

Legg unntaket i tabellen som vinner

Innenfor én rutetabell slår et /24 et /0 eller /1 ved lengste prefiksmatch, så en spesifikk rute til lagrings-VLAN-et via den lokale gatewayen er nok, forutsatt at tabellen i det hele tatt blir konsultert. På Linux er den vanlige formen kort:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

Policy-ruting kompliserer den garantien. En tidligere regel kan sende trafikk til en tabell der standardruten selv peker inn i tunnelen, og hovedtabellen som holder /24-en din blir da aldri nådd. Sjekk reglene før du antar at ruten er autoritativ, fordi en riktig utseende oppføring i feil tabell forklarer en feil som ser ut som en ødelagt rute.

Deretter gjør du oppføringen varig gjennom klientens støttede mekanisme eller nettverksbehandleren som eier grensesnittet. En rute skrevet inn i ledeteksten forsvinner ved neste gjenoppkobling, og en rute knyttet til én Wi-Fi-gateway er ikke flyttbar til det neste nettet laptopen besøker.

Navn og policy følger ikke ruter

Å fikse ruten gjenoppretter pakker, ikke navn. Hvis lokale enheter slås opp gjennom en pushet resolver som ikke vet noe om dem, feiler monteringen fortsatt selv om adressen er tilgjengelig. Lokale navn trenger en lokal eller delt DNS-ordning, og det er et eget valg fra ruteunntaket.

Policy er igjen noe annet. Et lokal tilgang-filter i en VPN-klient kan bevisst forby trafikk til private områder, og en rute overstyrer ikke den regelen. På et ubetrodd nett er en privat adresse heller ikke bevis for at målet er lagringsserveren din, så unntaket bør være like spesifikt som ruten selv.

En kontrakt du kan overlevere

Det ferdige designet bør leses som en kort liste: generell internettrafikk følger tunnelen, og disse navngitte lokale prefiksene beholder banen sin gjennom den lokale ruteren. Skriv ned prefiksene, neste hopp og DNS-suffikset som hører til, og hold listen kort nok til at noen kan verifisere den uten å lese en rutetabell.

Se opp for overlapp mellom lokale og eksterne områder. Et lagrings-VLAN som deler prefiks med noe bak VPN-en, blir slått opp til den ruten som er mer spesifikk, og oppførselen som følger er forvirrende på en måte som virker periodisk. Å nummerere om én side er vanligvis billigere enn å feilsøke den tvetydigheten for alltid.

Test kontrakten to ganger: én gang med tunnelen oppe og én gang med den nede. Hvis den lokale banen bare virker i én av tilstandene, er unntaket ennå ikke en kontrakt.