Split-tunnel-dokumentasjon trenger en DNS-regel ved hver rute
En rute avgjør etter adresse, en resolver avgjør etter navn. Dokumenter begge velgerne per flyt, hver med én test, ellers feiler notatet når DNS flytter seg.
Et split-tunnel-notat som sier "kontortrafikk går gjennom VPN" har dokumentert én beslutning og antydet tre andre. På pakkenivå velger en rutetabell et grensesnitt etter destinasjonsadresse; på navnenivå velger en resolver en server etter spørring, og de to valgene tas uavhengig. Derfor kan et korrekt dokumentert prefiks fortsatt gi en maskin som løser et internt navn til en offentlig adresse, eller ikke løser noe mens ruten ser perfekt ut.
To velgere, ett tilkoblingsforsøk
Når en applikasjon kobler til files.corp.example, skjer to oppslag før en pakke eksisterer. Resolveren avgjør hvilken server som mottar spørringen, ved hjelp av søkedomener, rutingsdomener per lenke eller en eksplisitt profilregel. Rutetabellen avgjør deretter hvor den resulterende adressen går, ved hjelp av lengste prefikssamsvar med destinasjonen.
Ingenting kobler de to beslutningene. En privat sone kan svare med 10.20.4.11, mens rutetabellen sender 10.20.0.0/16 inn i tunnelen, og tilkoblingen virker. Snu en av dem, og den feiler på en måte som ser ut som den andre: riktig DNS-policy pluss en manglende rute gir et løst navn og tidsavbrudd, mens en riktig rute pluss en offentlig resolver gir en adresse som rutes rent til feil sted.
Split-horizon DNS gjør dette skarpere. Samme navn kan returnere en privat adresse fra den interne resolveren og en offentlig adresse fra den internettvendte, så et notat som bare registrerer prefikset kan ikke forutsi hvilken adresse klienten faktisk bruker. Skriv ned resolverstien, ellers er adressen en gjetning.
Hva et notat bare om ruten utelater
En registrering bare om ruten er ubrukelig for den vanligste split-tunnel-feilen: navn. Brukeren rapporterer at intranettet ikke lastes, tunnelen er oppe, og prefikset er til stede. Den som tar saken har ingen registrering av hvilken resolver som skulle ha svart, ingen måte å skille et feil søkesuffiks fra en blokkert server, og ingen referanse å sammenligne med.
Den andre utelatelsen er unntakslisten. Et split-tunnel-design defineres like mye av det som blir utenfor tunnelen som av det som kommer inn i den, og de ekskluderte områdene er vanligvis de som bryter først, fordi en mer spesifikk lokal rute eller et klientfilter kan overstyre intensjonen uten å røre profilen.
Den tredje er den fjerne siden av tunnelen. En klientrute legger bare pakken på ledningen; gatewayen må fortsatt videresende den og ha en vei tilbake. strongSwans veiledning for videresending er en påminnelse om at videresendings- og brannmurregler på gatewayen er en del av funksjonen, ikke en del av rørleggerarbeidet du kan ta for gitt.
Feltene som gjør notatet kjørbart
Én rad per flyt, og en flyt er en destinasjon pluss et navn pluss en eier. Dette er feltene som overlever møtet med en reell hendelse:
| 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 "hvor den bor" er den folk hopper over. Et prefiks som skyves av serveren, en rute lagt til av en klientprofil og en rute skrevet inn i et skall skiller seg i hvem som kan endre dem og i om de overlever en gjenoppkobling. Uten det feltet kan den neste ingeniøren ikke se hvilken av de tre de ser på.
Én test per regel, ikke én per tunnel
Hver rad trenger to ufarlige kontroller: én som øver ruten og én som øver navnet. For ruten, be om noe som må krysse tunnelen og bekreft stien i stedet for tilgjengeligheten, for eksempel tracert -d 10.20.4.11 på Windows eller ip route get 10.20.4.11 på Linux. For navnet, spør på det private navnet og registrer hvilken server som svarte, ved hjelp av resolvectl query files.corp.example eller dig files.corp.example mot resolveren notatet angir.
Legg til en negativ forventning også: hva som skal skje når tunnelen er nede. En ekskludert applikasjon på en Android- eller iOS-enhet med blokkering uten VPN aktivert har kanskje ingen tilkobling i det hele tatt, og en skrivebordsklient kan la den samme appen virke mens tunnelen kobler til på nytt. Å registrere det tiltenkte svaret gjør "VPN ødela appen min" til en kontrollerbar påstand.
Hold registreringen sammen med konfigurasjonen
Oppbevar notatet ved siden av profilen det beskriver, og versjoner det med den profilen. Et dokument på en wiki som ingen oppdaterer, er et rykte; en tabell i samme repositorium som de skyvede rutene og resolverpolicyen kan gjennomgås i samme endring.
Når noe bryter, sammenlign den anvendte ruten og den effektive resolveren med registreringen før du legger til et nytt unntak. To av de tre vanlige årsakene — en gammel navneromsregel og en hjelpeprosess utenfor app-policyen — ser nøyaktig ut som en VPN-feil og er usynlige hvis notatet bare lister prefikser.
Før du kaller notatet ferdig, bekreft at det svarer skriftlig på disse: hvilket prefiks, for hvilken adressefamilie; hvilket privat navnerom, svart av hvilken resolver; hvilke navn som bevisst forblir offentlige; hvor hver regel er konfigurert og hvem som eier den; og den ene kommandoen som beviser ruten og den som beviser navnet. Hvis noe av dette mangler, vil neste hendelse bli diagnostisert fra bunnen av.