Är full tunnling enklare än en lång split-tunnellista?

En split-tunnellista börjar med tre program och slutar med att täcka det mesta av maskinen, och varje ny rad är någons undantag. Vid det laget har listan tyst blivit en standard med extra steg. Full tunnling vänder på arrangemanget: allt går in i tunneln om inte ett dokumenterat undantag säger annat. Om det är enklare beror på gatewayen och på de lokala tjänster du skulle bryta.

Börja med att räkna reglerna du underhåller

Räkna posterna och räkna sedan hur många som har en namngiven ägare och ett datum för när de senast verifierades. Det andra talet är det som spelar roll, eftersom ett undantag utan ägare inte kan utvärderas när programvaran det refererar till byter namn eller ersätts. Regler kopplade till en körbar filsökväg slutar tyst att fungera efter en uppdatering, och felet ser ut som en instabil VPN snarare än en inaktuell regel. Skriv ner listan innan du har en åsikt om den.

Varje post bör svara på tre frågor: vad som går sönder utan den, vem som beslutade det och hur du skulle märka om skälet upphörde. Poster som inte kan svara på alla tre är kandidater för borttagning snarare än migrering, och att ta bort dem först gör den senare jämförelsen ärlig.

Om de flesta poster dirigerar en stor del av trafiken kör du redan en full tunnel med en underhållsbörda på köpet. Beslutet handlar då om var standarden bor, inte om du ska ha en.

Kontrollera om gatewayen orkar bära standarden

Full tunnling flyttar varje paket till en enda enhet, vilket samtidigt ändrar enhetens CPU-belastning, conntrack-tabell, adresstranslation och krav på uppströms bandbredd. En gateway som bekvämt betjänade några interna subnät är kanske inte dimensionerad för allt en användares surfande. Titta på det största antal samtidiga sessioner du förväntar dig istället för genomsnittet, eftersom toppen brister först.

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

Mät samma arbetsbelastning före och efter ändringen istället för att resonera utifrån specifikationer. En enda eftermiddag med vanlig användning på en maskin visar om gatewayen är nära en gräns, och det kostar ingenting jämfört med att upptäcka det en måndagsmorgon.

Kontrollera också path-MTU hela vägen, eftersom en full standard utsätter varje program för tunnelns maximala paketstorlek. Program som fungerade utanför tunneln kan nu bero på fragmenteringsbeteende du aldrig behövt tänka på.

Bekräfta att lokala tjänster och privat DNS fortfarande fungerar

Räkna upp det som måste stanna lokalt efter protokoll istället för efter programnamn: upptäcktsprotokoll för skrivare och skärmar, en smart hem-brygga, en routers administrationssida, en lokal utvecklingsserver som nås via ett namn som bara löses ut i LAN. De går sönder när standardrutten börjar peka in i en tunnel, och de går sönder tyst eftersom ingenting loggar ett fel hos klienten.

Privat DNS är det andra beroendet. Om interna namn tidigare löstes av tunnelns resolver ändras ingenting; om de löstes lokalt måste en full standard föra dem till en resolver som känner till zonerna. Testa ett internt namn och ett publikt namn efter ändringen istället för att anta att resolverlistan överlevde.

Skriv de lokala undantagen i profilen som äger dem. Ett undantag som bara finns i någons minne är det första nästa migrering tappar.

Migrera en profil och verifiera gränserna

Ändra profilen genom konfigurationen som äger den, istället för att lägga en ny standard ovanpå manuella rutter som tidigare experiment lämnat kvar. De kvarvarande rutterna är den vanliga orsaken till en migrering som ser ut att fungera och beter sig inkonsekvent en dag senare. Håll den gamla profilen tillgänglig så att en återställning är ett val och inte en återuppbyggnad.

Verifiera sedan två gränser var för sig: att både publika och privata destinationer fungerar, och att oönskad trafik inte lämnar tunneln. En lyckad sidladdning bevisar det första och säger ingenting om det andra.

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

Upprepa kontrollen efter en återanslutning och efter ett avbrott, eftersom en kill switch som blockerar trafik under ett avbrott är en annan egenskap än en rutt som återställs korrekt efteråt. Den enklare designen är den vars verkliga täckning du fortfarande kan förklara efter att ett program eller ett nätverk ändrats.