Er fuld tunneling enklere end en lang split-tunnel-liste?

En split-tunnel-liste starter med tre applikationer og ender med at dække det meste af maskinen, og hver ny linje er nogens undtagelse. På det tidspunkt er listen stille blevet en standard med ekstra trin. Fuld tunneling vender arrangementet om: alt går i tunnelen, medmindre en dokumenteret udelukkelse siger andet. Om det er enklere afhænger af gatewayen og af de lokale tjenester, du ville ødelægge.

Start med at tælle de regler, du vedligeholder

Tæl posterne, og tæl derefter hvor mange der har en navngivet ejer og en dato for sidste verifikation. Det andet tal er det, der betyder noget, fordi en undtagelse, ingen ejer, ikke kan vurderes, når det software, den peger på, omdøbes eller udskiftes. Regler, der er knyttet til en eksekverbar sti, fejler lydløst efter en opdatering, og fejlen ligner en ustabil VPN snarere end en forældet regel. Skriv listen ned, før du har en holdning til den.

Hver post bør svare på tre spørgsmål: hvad går i stykker uden den, hvem besluttede det, og hvordan ville du opdage, at årsagen er bortfaldet. Poster, der ikke kan svare på alle tre, er kandidater til sletning frem for migrering, og at slette dem først gør den senere sammenligning ærlig.

Hvis de fleste poster sender en stor del af trafikken, kører du allerede en fuld tunnel med en ekstra vedligeholdelsesbyrde. Beslutningen handler så om, hvor standarden bor, ikke om hvorvidt der skal være en.

Undersøg, om gatewayen kan bære standarden

Fuld tunneling flytter hver pakke til én enhed, hvilket ændrer enhedens CPU-belastning, conntrack-tabel, adresseoversættelse og kravet til opstrøms båndbredde på samme tid. En gateway, der komfortabelt betjente nogle få interne undernet, er måske ikke dimensioneret til al en brugers browsing. Se på det største antal samtidige sessioner, du forventer, frem for gennemsnittet, fordi toppen er det, der først knækker.

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

Mål den samme belastning før og efter ændringen i stedet for at ræsonnere ud fra specifikationer. En enkelt eftermiddag med almindelig brug på én maskine vil vise, om gatewayen er tæt på en grænse, og det koster intet sammenlignet med at opdage det en mandag morgen.

Kontroller også MTU på stien ende til ende, fordi en fuld standard udsætter hver applikation for tunnelens maksimale pakkestørrelse. Applikationer, der virkede uden for tunnelen, kan nu afhænge af fragmenteringsadfærd, du aldrig har skullet overveje.

Bekræft, at lokale tjenester og privat DNS stadig virker

List op, hvad der skal forblive lokalt efter protokol frem for efter appnavn: opdagelsesprotokoller til printere og skærme, en smart-home-bro, en routers administrationsside, en lokal udviklingsserver, der nås via et navn, som kun opløses på LAN’et. De går i stykker, når standardruten begynder at pege ind i en tunnel, og de går i stykker lydløst, fordi intet logger en fejl på klienten.

Privat DNS er den anden afhængighed. Hvis interne navne før blev opløst af tunnelens resolver, ændrer intet sig; hvis de blev opløst lokalt, skal en fuld standard bære dem til en resolver, der kender zonerne. Test ét internt og ét offentligt navn efter ændringen i stedet for at antage, at resolverlisten overlevede.

Skriv de lokale undtagelser ind i den profil, der ejer dem. En undtagelse, der kun findes i nogens hukommelse, er det første, den næste migrering mister.

Migrér én profil, og verificér grænserne

Ændr profilen gennem dens egen konfiguration i stedet for at lægge en ny standard oven på manuelle ruter, som tidligere eksperimenter har efterladt. Disse resterende ruter er den sædvanlige årsag til en migrering, der ser ud til at virke og opfører sig inkonsistent en dag senere. Hold den gamle profil tilgængelig, så en tilbagerulning er et valg og ikke en genopbygning.

Verificér derefter to grænser separat: at både offentlige og private destinationer virker, og at uønsket trafik ikke forlader tunnelen. En vellykket sideindlæsning beviser det første og siger intet om det andet.

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

Gentag kontrollen efter en genopkobling og efter et udfald, fordi en kill switch, der blokerer trafik under et udfald, er en anden egenskab end en rute, der bagefter gendannes korrekt. Det enklere design er det, hvis reelle dækning du stadig kan forklare, efter at en applikation eller et netværk ændres.