Split-tunnel-dokumentasjon treng ein DNS-regel ved kvar rute
Ei rute avgjer etter adresse, ein resolver avgjer etter namn. Dokumenter begge veljarane per flyt, kvar med éin test, elles feilar notatet når DNS flyttar seg.
Eit split-tunnel-notat som seier "kontortrafikk går gjennom VPN" har dokumentert éi avgjerd og antydd tre andre. På pakkenivå vel ei rutetabell eit grensesnitt etter måladresse; på namnenivå vel ein resolver ein tenar etter spørjing, og dei to vala blir tekne uavhengig. Difor kan eit korrekt dokumentert prefiks framleis gje ein maskin som løyser eit internt namn til ei offentleg adresse, eller ikkje løyser noko medan ruta ser perfekt ut.
To veljarar, eitt tilkoplingsforsøk
Når ein applikasjon koplar til files.corp.example, skjer to oppslag før ein pakke finst. Resolveren avgjer kva tenar som får spørjinga, ved hjelp av søkjedomene, rutingsdomene per lenkje eller ei eksplisitt profilregel. Rutetabellen avgjer deretter kvar den resulterande adressa går, ved hjelp av lengste prefikssamsvar med målet.
Ingenting koplar dei to avgjerdene. Ei privat sone kan svare med 10.20.4.11, medan rutetabellen sender 10.20.0.0/16 inn i tunnelen, og tilkoplinga verkar. Snu ein av dei, og han feilar på ein måte som ser ut som den andre: rett DNS-politikk pluss ei manglande rute gjev eit løyst namn og tidsavbrot, medan ei rett rute pluss ein offentleg resolver gjev ei adresse som rutar reint til feil stad.
Split-horizon-DNS gjer dette skarpare. Same namn kan returnere ei privat adresse frå den interne resolveren og ei offentleg adresse frå den internettvendte, så eit notat som berre registrerer prefikset kan ikkje føreseie kva adresse klienten faktisk brukar. Skriv ned resolverstien, elles er adressa eit gjet.
Kva eit notat berre om ruta utelèt
Ei registrering berre om ruta er ubrukeleg for den vanlegaste split-tunnel-feilen: namn. Brukaren rapporterer at intranettet ikkje lastar, tunnelen er oppe, og prefikset er til stades. Den som tek saka har inga registrering av kva resolver som skulle ha svart, ingen måte å skilje eit feil søkjesuffiks frå ein blokkert tenar, og inga referanselinje å samanlikne med.
Den andre utelatinga er unntakslista. Eit split-tunnel-design blir definert like mykje av det som blir utanfor tunnelen som av det som kjem inn i han, og dei utelukka områda er vanlegvis dei som bryt først, fordi ei meir spesifikk lokal rute eller eit klientfilter kan overstyre intensjonen utan å røre profilen.
Den tredje er den fjerne sida av tunnelen. Ei klientrute legg berre pakken på leidninga; gatewayen må framleis senda han vidare og ha ein veg tilbake. strongSwan sin rettleiar for videresending minner om at videresendings- og brannmurreglar på gatewayen er ein del av funksjonen, ikkje ein del av røyrleggjararbeidet du kan ta for gitt.
Felta som gjer notatet køyrbart
Éi rad per flyt, og ein flyt er eit mål pluss eit namn pluss ein eigar. Dette er felta som overlever møtet med ei reell hending:
| 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 |
Rada "kvar han bur" er den folk hoppar over. Eit prefiks som blir dytta av tenaren, ei rute lagd til av ein klientprofil og ei rute skriven inn i eit skal skil seg i kven som kan endre dei og i om dei overlever ei ny tilkopling. Utan det feltet kan den neste ingeniøren ikkje sjå kva av dei tre han ser på.
Éin test per regel, ikkje éin per tunnel
Kvar rad treng to ufarlege kontrollar: éin som øvar ruta og éin som øvar namnet. For ruta, be om noko som må krysse tunnelen og stadfest stien i staden for tilgjenge, til dømes tracert -d 10.20.4.11 på Windows eller ip route get 10.20.4.11 på Linux. For namnet, spør på det private namnet og registrer kva tenar som svarte, ved hjelp av resolvectl query files.corp.example eller dig files.corp.example mot resolveren notatet nemner.
Legg til ei negativ forventing òg: kva som skal skje når tunnelen er nede. Ein utelukka applikasjon på ein Android- eller iOS-eining med blokkering utan VPN slått på har kanskje inga tilkopling i det heile, og ein skrivebordsklient kan la den same appen verke medan tunnelen koplar til på nytt. Å registrere det tiltenkte svaret gjer "VPN øydela appen min" til ei kontrollerbar påstand.
Hald registreringa saman med konfigurasjonen
Oppbevar notatet ved sida av profilen det skildrar, og versjoner det med den profilen. Eit dokument på ein wiki som ingen oppdaterer, er eit rykte; ein tabell i same repositoriet som dei dytta rutene og resolverpolitikken kan gjennomgåast i same endring.
Når noko bryt, samanlikn den brukte ruta og den effektive resolveren med registreringa før du legg til eit nytt unntak. To av dei tre vanlege årsakene — ein gammal namneromsregel og ein hjelpeprosess utanfor app-politikken — ser nøyaktig ut som ein VPN-feil og er usynlege om notatet berre listar prefiks.
Før du kallar notatet ferdig, stadfest at det svarar skriftleg på desse: kva prefiks, for kva adressefamilie; kva privat namnerom, svart av kven resolver; kva namn som med vilje blir verande offentlege; kvar kvar regel er konfigurert og kven som eig han; og den eine kommandoen som beviser ruta og den som beviser namnet. Om noko av dette manglar, vil neste hending bli diagnostisert frå botnen.