Split-tunnel-dokumentation har brug for en DNS-regel ved hver rute
En rute afgør efter adresse, en resolver afgør efter navn. Dokumentér begge selektorer pr. flow, hver med én test, ellers fejler noten, når DNS flytter sig.
En split-tunnel-note, der siger "kontortrafik går gennem VPN", har dokumenteret én beslutning og antydet tre andre. På pakkelaget vælger en routingtabel et interface efter destinationsadresse; på navnelaget vælger en resolver en server efter forespørgsel, og de to valg træffes uafhængigt. Derfor kan et korrekt dokumenteret præfiks stadig give en maskine, der opløser et internt navn til en offentlig adresse, eller slet ikke opløser noget, mens ruten ser perfekt ud.
To selektorer, ét forbindelsesforsøg
Når en applikation opretter forbindelse til files.corp.example, sker der to opslag, før en pakke findes. Resolveren afgør, hvilken server der modtager forespørgslen, ved hjælp af søgedomæner, routingdomæner pr. link eller en eksplicit profilregel. Routingtabellen afgør derefter, hvor den resulterende adresse går hen, ved hjælp af længste præfiks-match mod destinationen.
Intet forbinder de to beslutninger. En privat zone kan svare med 10.20.4.11, mens routingtabellen sender 10.20.0.0/16 ind i tunnelen, og forbindelsen virker. Vend en af dem, og den fejler på en måde, der ligner den anden: korrekt DNS-politik plus en manglende rute giver et opløst navn og en timeout, mens en korrekt rute plus en offentlig resolver giver en adresse, der rent routes til det forkerte sted.
Split-horizon DNS gør dette skarpere. Det samme navn kan returnere en privat adresse fra den interne resolver og en offentlig adresse fra den internetvendte, så en note, der kun registrerer præfikset, kan ikke forudsige, hvilken adresse klienten faktisk bruger. Skriv resolverstien ned, ellers er adressen et gæt.
Hvad en note kun om ruten udelader
En registrering kun om ruten er ubrugelig til den mest almindelige split-tunnel-fejl: navne. Brugeren rapporterer, at intranettet ikke indlæses, tunnelen er oppe, og præfikset er til stede. Den, der tager billetten, har ingen registrering af, hvilken resolver der burde have svaret, ingen måde at skelne et forkert søgesuffiks fra en blokeret server og ingen baseline at sammenligne med.
Den anden udeladelse er undtagelseslisten. Et split-tunnel-design defineres lige så meget af det, der bliver uden for tunnelen, som af det, der kommer ind i den, og de udelukkede områder er normalt dem, der først brækker, fordi en mere specifik lokal rute eller et klient-side-filter kan tilsidesætte hensigten uden at røre profilen.
Den tredje er den fjerne side af tunnelen. En klientrute sætter kun pakken på ledningen; gatewayen skal stadig videresende den og have en vej tilbage. strongSwans guide til videresendelse er en påmindelse om, at videresendelses- og firewallregler på gatewayen er en del af funktionen, ikke en del af det VVS, du kan tage for givet.
Felterne, der gør noten eksekverbar
Én række pr. flow, og et flow er en destination plus et navn plus en ejer. Dette er felterne, der overlever mødet med en rigtig hændelse:
| 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 |
Rækken "hvor den bor" er den, folk springer over. Et præfiks, der skubbes af serveren, en rute, der tilføjes af en klientprofil, og en rute, der tastes i en shell, adskiller sig i, hvem der kan ændre dem, og i om de overlever en genopkobling. Uden det felt kan den næste ingeniør ikke se, hvilken af de tre de kigger på.
Én test pr. regel, ikke én pr. tunnel
Hver række har brug for to harmløse kontroller: en, der prøver ruten, og en, der prøver navnet. For ruten skal du anmode om noget, der skal krydse tunnelen, og bekræfte stien frem for tilgængeligheden, for eksempel tracert -d 10.20.4.11 på Windows eller ip route get 10.20.4.11 på Linux. For navnet skal du forespørge det private navn og registrere, hvilken server der svarede, ved hjælp af resolvectl query files.corp.example eller dig files.corp.example mod den resolver, noten angiver.
Tilføj også en negativ forventning: hvad der skal ske, når tunnelen er nede. En udelukket applikation på en Android- eller iOS-enhed med blokering uden VPN aktiveret har muligvis slet ingen forbindelse, og en desktop-klient kan lade den samme app virke, mens tunnelen genopretter forbindelsen. At registrere det tilsigtede svar gør "VPN ødelagde min app" til et kontrollerbart udsagn.
Hold registreringen sammen med konfigurationen
Opbevar noten ved siden af den profil, den beskriver, og versionér den med den profil. Et dokument på en wiki, som ingen opdaterer, er et rygte; en tabel i samme repository som de skubbede ruter og resolverpolitikken kan gennemgås i samme ændring.
Når noget brækker, skal du sammenligne den anvendte rute og den effektive resolver med registreringen, før du tilføjer endnu en undtagelse. To af de tre almindelige årsager — en gammel navnerumsregel og en hjælpeproces uden for app-politikken — ser præcis ud som en VPN-fejl og er usynlige, hvis noten kun oplister præfikser.
Før du kalder noten færdig, skal du bekræfte, at den besvarer disse skriftligt: hvilket præfiks, for hvilken adressefamilie; hvilket privat navnerum, besvaret af hvilken resolver; hvilke navne der bevidst forbliver offentlige; hvor hver regel er konfigureret, og hvem der ejer den; og den ene kommando, der beviser ruten, og den, der beviser navnet. Hvis noget af det mangler, vil den næste hændelse blive diagnosticeret fra bunden.