Er full tunnellering enklere enn en lang splitt-tunnelliste?

En splitt-tunnelliste starter med tre applikasjoner og ender med å dekke mesteparten av maskinen, og hver nye linje er noens unntak. På det punktet har listen stille blitt en standard med ekstra steg. Full tunnellering snur ordningen: 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 bryte.

Start med å telle reglene du vedlikeholder

Tell oppføringene, og tell deretter hvor mange som har en navngitt eier og en dato for når de sist ble verifisert. Det andre tallet er det som betyr noe, fordi et unntak ingen eier, ikke kan vurderes når programvaren det peker på får nytt navn eller blir erstattet. Regler som er knyttet til en kjørbar filbane, feiler stille etter en oppdatering, og feilen ser ut som en ustabil VPN snarere enn en utdatert regel. Skriv ned listen før du har en mening om den.

Hver oppføring bør svare på tre spørsmål: hva som går i stykker uten den, hvem som bestemte det, og hvordan du ville merke det om begrunnelsen utløp. Oppføringer som ikke kan svare på alle tre, er kandidater for sletting snarere enn migrering, og å slette dem først gjør den senere sammenligningen ærlig.

Hvis de fleste oppføringene ruter en stor del av trafikken, kjører du allerede en full tunnel med en vedlikeholdsbyrde på slep. Beslutningen handler da om hvor standarden bor, ikke om du skal ha en.

Sjekk om gatewayen kan bære standarden

Full tunnellering flytter hver pakke til én enhet, noe som endrer den enhetens CPU-last, conntrack-tabell, adresseoversetting og krav til oppstrøms båndbredde samtidig. En gateway som komfortabelt betjente noen få interne subnett, er kanskje ikke dimensjonert for all nettlesingen til en bruker. Se på det største antallet samtidige økter du forventer, ikke gjennomsnittet, fordi toppen er det som ryker først.

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

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

Sjekk også path-MTU ende til ende, fordi en full standard utsetter hver applikasjon for tunnelens maksimale pakkestørrelse. Applikasjoner som fungerte utenfor tunnelen, kan nå være avhengige av fragmenteringsatferd du aldri har trengt å tenke på.

Bekreft at lokale tjenester og privat DNS fortsatt virker

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

Privat DNS er den andre avhengigheten. Hvis interne navn ble løst av tunnelens resolver før, endres ingenting; hvis de ble løst lokalt, må en full standard 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 overlevde.

Skriv de lokale unntakene inn i profilen som eier dem. Et unntak som bare finnes i noens hukommelse, 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 en ny standard oppå manuelle ruter som er igjen fra tidligere eksperimenter. De gjenværende rutene er den vanlige årsaken til en migrering som ser ut til å virke og oppfører seg inkonsekvent en dag senere. Hold den gamle profilen tilgjengelig, slik at en tilbakerulling er et valg og ikke en gjenoppbygging.

Verifiser deretter 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 gjenoppkobling 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 hvis reelle dekning du fortsatt kan forklare etter at en applikasjon eller et nettverk endres.