Er full tunnellering enklere enn en lang splitt-tunnelliste?

En splitt-tunnelliste begynner med tre applikasjoner og ender opp med å dekke det meste av maskinen, og hver ny linje er noens unntak. Da har listen stille blitt et standardvalg med ekstra trinn. Full tunnellering snur oppsettet: alt går inn i tunnelen med mindre et dokumentert unntak sier noe annet. Om det er enklere, avhenger av gatewayen og av de lokale tjenestene du ville ødelagt.

Begynn med å telle reglene du vedlikeholder

Tell oppføringene, og tell så hvor mange som har en navngitt eier og en dato for når de sist ble kontrollert. Det er det andre tallet som betyr noe, fordi et unntak uten eier ikke kan vurderes når programvaren det viser til, får nytt navn eller blir byttet ut. Regler som er knyttet til en kjørbar filsti, svikter stille etter en oppdatering, og svikten ser ut som en ustabil VPN heller enn en foreldet regel. Skriv listen ned før du har en formening om den.

Hver oppføring bør besvare tre spørsmål: hva som ryker uten den, hvem som bestemte det, og hvordan du ville oppdage det om begrunnelsen falt bort. Oppføringer som ikke kan svare på alle tre, er kandidater for sletting framfor migrering, og å slette dem først gjør den senere sammenligningen ærlig.

Dersom de fleste oppføringene rutrer en stor del av trafikken, driver du allerede en full tunnel med vedlikeholdsarbeid på kjøpet. Avgjørelsen gjelder da hvor standardvalget bor, ikke hvorvidt du skal ha et.

Sjekk om gatewayen tåler standardvalget

Full tunnellering sender hver pakke til én enhet, og det endrer enhetens CPU-belastning, conntrack-tabell, adresseoversetting og krav til oppstrøms båndbredde på samme tid. En gateway som med letthet betjente noen interne subnett, er kanskje ikke dimensjonert for hele nettlesingen til én bruker. Se på det høyeste antallet samtidige økter du forventer, ikke gjennomsnittet, fordi toppen er det som først gir etter.

ip -s link show dev tun0
conntrack -C
ss -s

Mål den samme belastningen før og etter endringen i stedet for å resonnere fra spesifikasjoner. En ettermiddag med vanlig bruk på én maskin viser om gatewayen er nær en grense, og det koster ingenting mot å oppdage det en mandag morgen.

Kontroller også path-MTU hele veien, fordi et fullt standardvalg utsetter hver applikasjon for tunnelens maksimale pakkestørrelse. Applikasjoner som virket utenfor tunnelen, kan nå være avhengige av fragmenteringsatferd du aldri har trengt å tenke på.

Bekreft at lokale tjenester og privat DNS fortsatt fungerer

Kartlegg det som må forbli lokalt etter protokoll i stedet for applikasjonsnavn: oppdagelsesprotokoller for skrivere og skjermer, en smart hjem-bro, en ruterdministrasjonsside, en lokal utviklingsserver nådd gjennom et navn som bare løses på LAN-et. De bryter sammen når standardruten begynner å peke inn i en tunnel, og de bryter sammen i det stille fordi ingenting logger en feil hos klienten.

Privat DNS er den andre avhengigheten. Hvis interne navn tidligere ble løst av tunnelens resolver, endres ingenting; hvis de ble løst lokalt, må et fullt standardvalg føre dem til en resolver som kjenner sonene. Test ett internt navn og ett offentlig navn etter endringen i stedet for å anta at resolverlisten holdt.

Skriv de lokale unntakene inn i profilen som eier dem. Et unntak som bare finnes i noens minne, er det første den neste migreringen mister.

Migrer én profil og verifiser grensene

Endre profilen gjennom konfigurasjonen som eier den, i stedet for å legge et nytt standardvalg oppå manuelle ruter som er blitt igjen fra tidligere forsøk. De gjenværende rutene er den vanlige årsaken til en migrering som ser ut til å virke, og som oppfører seg inkonsekvent en dag senere. Hold den gamle profilen tilgjengelig slik at en tilbakerulling er et valg og ikke en gjenoppbygging.

Deretter verifiser to grenser hver for seg: at både offentlige og private destinasjoner virker, og at uønsket trafikk ikke forlater tunnelen. En vellykket sideinnlasting beviser det første og sier ingenting om det andre.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Gjenta kontrollen etter en ny tilkobling og etter et avbrudd, fordi en kill switch som blokkerer trafikk under et brudd, er en annen egenskap enn en rute som gjenopprettes riktig etterpå. Det enklere designet er det der du fortsatt kan forklare den reelle dekningen etter at en applikasjon eller et nettverk endres.