Split-tunnel-dokumentation behöver en DNS-regel intill varje rutt
En rutt avgör efter adress, en resolver avgör efter namn. Dokumentera båda väljarna per flöde, var och en med ett test, annars faller anteckningen när DNS flyttar sig.
En split-tunnel-anteckning som säger "kontorstrafik går genom VPN" har dokumenterat ett beslut och antytt tre andra. På paketnivån väljer en routingtabell ett gränssnitt efter destinationsadress; på namnivån väljer en resolver en server efter fråga, och de två valen görs oberoende av varandra. Därför kan ett korrekt dokumenterat prefix fortfarande ge en maskin som löser ett internt namn till en offentlig adress, eller inte löser något medan rutten ser perfekt ut.
Två väljare, ett anslutningsförsök
När en applikation ansluter till files.corp.example, sker två uppslag innan ett paket finns. Resolvern avgör vilken server som får frågan, med sökdomäner, routingdomäner per länk eller en explicit profilregel. Routingtabellen avgör sedan vart den resulterande adressen tar vägen, med längsta prefixmatchning mot destinationen.
Ingenting förbinder de två besluten. En privat zon kan svara med 10.20.4.11, medan routingtabellen skickar 10.20.0.0/16 in i tunneln, och anslutningen fungerar. Vänd på något av dem och det misslyckas på ett sätt som ser ut som det andra: korrekt DNS-policy plus en saknad rutt ger ett löst namn och en tidsgräns, medan en korrekt rutt plus en offentlig resolver ger en adress som routas rent till fel ställe.
Split-horizon-DNS gör detta skarpare. Samma namn kan returnera en privat adress från den interna resolvern och en offentlig adress från den internetvända, så en anteckning som bara registrerar prefixet kan inte förutsäga vilken adress klienten faktiskt använder. Skriv ner resolvervägen, annars är adressen en gissning.
Vad en anteckning bara om rutten utelämnar
En registrering bara om rutten är oanvändbar för det vanligaste split-tunnel-felet: namn. Användaren rapporterar att intranätet inte laddas, tunneln är uppe och prefixet finns. Den som tar ärendet har ingen registrering av vilken resolver som borde ha svarat, inget sätt att skilja ett felaktigt söksuffix från en blockerad server och ingen baslinje att jämföra med.
Den andra utelämningen är undantagslistan. En split-tunnel-design definieras lika mycket av det som stannar utanför tunneln som av det som kommer in i den, och de uteslutna intervallen är oftast de som går sönder först, eftersom en mer specifik lokal rutt eller ett klientfilter kan åsidosätta avsikten utan att röra profilen.
Den tredje är den bortre sidan av tunneln. En klientrutt lägger bara paketet på tråden; gatewayen måste fortfarande vidarebefordra det och ha en väg tillbaka. strongSwans guide för vidarebefordran påminner om att vidarebefordrings- och brandväggsregler på gatewayen är en del av funktionen, inte en del av rörmokeri du kan ta för given.
Fälten som gör anteckningen körbar
En rad per flöde, och ett flöde är en destination plus ett namn plus en ägare. Det här är fälten som överlever mötet med en verklig incident:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
Raden "var den bor" är den folk hoppar över. Ett prefix som skjuts av servern, en rutt som läggs till av en klientprofil och en rutt som skrivs in i ett skal skiljer sig i vem som kan ändra dem och i om de överlever en återanslutning. Utan det fältet kan nästa ingenjör inte se vilken av de tre de tittar på.
Ett test per regel, inte ett per tunnel
Varje rad behöver två ofarliga kontroller: en som övar rutten och en som övar namnet. För rutten, begär något som måste korsa tunneln och bekräfta vägen i stället för nåbarheten, till exempel tracert -d 10.20.4.11 på Windows eller ip route get 10.20.4.11 på Linux. För namnet, fråga efter det privata namnet och registrera vilken server som svarade, med resolvectl query files.corp.example eller dig files.corp.example mot resolvern som anteckningen anger.
Lägg också till en negativ förväntan: vad som ska hända när tunneln är nere. En utesluten applikation på en Android- eller iOS-enhet med blockering utan VPN aktiverad har kanske ingen anslutning alls, och en skrivbordsklient kan låta samma app fungera medan tunneln återansluter. Att registrera det avsedda svaret gör "VPN förstörde min app" till ett kontrollerbart påstående.
Behåll registreringen med konfigurationen
Förvara anteckningen bredvid profilen den beskriver och versionshantera den med den profilen. Ett dokument på en wiki som ingen uppdaterar är ett rykte; en tabell i samma repository som de skjutna rutterna och resolverpolicyn kan granskas i samma ändring.
När något går sönder, jämför den tillämpade rutten och den effektiva resolvern med registreringen innan du lägger till ett nytt undantag. Två av de tre vanliga orsakerna — en gammal namnrymdsregel och en hjälpprocess utanför app-policyn — ser exakt ut som ett VPN-fel och är osynliga om anteckningen bara listar prefix.
Innan du kallar anteckningen färdig, bekräfta att den svarar skriftligt på detta: vilket prefix, för vilken adressfamilj; vilken privat namnrymd, besvarad av vilken resolver; vilka namn som medvetet förblir offentliga; var varje regel är konfigurerad och vem som äger den; och det enda kommandot som bevisar rutten och det som bevisar namnet. Om något av detta saknas kommer nästa incident att diagnostiseras från grunden.