Er full tunnellering enklare enn ei lang splitt-tunnelliste?

Ei splitt-tunnelliste byrjar med tre applikasjonar og endar med å dekkje det meste av maskina, og kvar ny linje er nokon sitt unntak. På det punktet har lista stille blitt eit standardval med ekstra steg. Full tunnellering snur ordninga: alt går inn i tunnelen med mindre eit dokumentert unntak seier noko anna. Om det er enklare, kjem an på gatewayen og på dei lokale tenestene du ville bryte.

Byrja med å telje reglane du vedlikeheld

Tel oppføringane, og tel deretter kor mange som har ein namngjeven eigar og ein dato for når dei sist vart stadfesta. Det andre talet er det som tel, fordi eit unntak ingen eig, ikkje kan vurderast når programvara det viser til, får nytt namn eller blir bytt ut. Reglar som er knytte til ein køyrbar filsti, feilar stille etter ei oppdatering, og feilen ser ut som ein ustabil VPN snarare enn ein forelda regel. Skriv ned lista før du har ei meining om ho.

Kvar oppføring bør svare på tre spørsmål: kva som bryt saman utan ho, kven som avgjorde det, og korleis du ville merke det om grunngjevinga fall bort. Oppføringar som ikkje kan svare på alle tre, er kandidatar for sletting snarare enn migrering, og å slette dei først gjer den seinare samanlikninga ærleg.

Viss dei fleste oppføringane rutar ein stor del av trafikken, køyrer du allereie ein full tunnel med vedlikehaldsbyrde på slep. Avgjerda handlar då om kvar standardvalet bur, ikkje om du skal ha eit.

Sjekk om gatewayen kan bere standardvalet

Full tunnellering flyttar kvar pakke til éi eining, noko som endrar CPU-lasta, conntrack-tabellen, adresseomsetjinga og kravet til oppstraums bandbreidd på den eininga samstundes. Ein gateway som komfortabelt tente nokre få interne subnett, er kanskje ikkje dimensjonert for all nettlesinga til ein brukar. Sjå på det største talet samtidige økter du ventar, ikkje gjennomsnittet, fordi toppen er det som ryker først.

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

Mål den same arbeidsmengda før og etter endringa i staden for å resonnere ut frå spesifikasjonar. Ein einaste ettermiddag med vanleg bruk på éi maskin vil vise om gatewayen er nær ei grense, og det kostar ingenting samanlikna med å oppdage det ein måndagsmorgon.

Sjekk òg path-MTU ende til ende, fordi eit fullt standardval utset kvar applikasjon for den største pakkestorleiken til tunnelen. Applikasjonar som fungerte utanfor tunnelen, kan no vere avhengige av fragmenteringsåtferd du aldri har trengt å tenkje på.

Stadfest at lokale tenester og privat DNS framleis verkar

Kartlegg det som må halde seg lokalt etter protokoll i staden for etter applikasjonsnamn: oppdagingsprotokollar for skrivarar og skjermar, ei smartheim-bru, administratorsida til ein ruter, ein lokal utviklingsserver nådd via eit namn som berre blir løyst på LAN-et. Dei bryt saman når standardruta byrjar å peike inn i ein tunnel, og dei bryt stille fordi ingenting loggar ein feil hjå klienten.

Privat DNS er den andre avhengigheita. Viss interne namn før vart løyste av resolvaren til tunnelen, endrar ingenting seg; viss dei vart løyste lokalt, må eit fullt standardval føre dei til ein resolver som kjenner sonene. Test eitt internt namn og eitt offentleg namn etter endringa i staden for å gå ut frå at resolverlista overlevde.

Skriv dei lokale unntaka inn i profilen som eig dei. Eit unntak som berre finst i minnet til nokon, er det første den neste migreringa mistar.

Migrer éin profil og stadfest grensene

Endre profilen gjennom konfigurasjonen som eig han, i staden for å leggje eit nytt standardval oppå manuelle ruter som er att etter tidlegare eksperiment. Dei attverande rutene er den vanlege årsaka til ei migrering som ser ut til å verke og oppfører seg inkonsekvent ein dag seinare. Hald den gamle profilen tilgjengeleg, slik at ein tilbakerulling er eit val og ikkje ein gjenoppbygging.

Stadfest deretter to grenser kvar for seg: at både offentlege og private destinasjonar verkar, og at uønskt trafikk ikkje forlét tunnelen. Ei vellukka sideinnlasting provar det første og seier 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 ei attkopling og etter eit avbrot, fordi ein kill switch som blokkerer trafikk under eit brot, er ein annan eigenskap enn ei rute som blir rett gjenoppretta etterpå. Det enklare designet er det der du framleis kan forklare den reelle dekninga etter at ein applikasjon eller eit nettverk endrar seg.