Split-tunnel-documentatie heeft een DNS-regel naast elke route nodig
Een route beslist op adres, een resolver beslist op naam. Documenteer beide selectors per stroom, elk met één test, anders faalt de notitie wanneer DNS verschuift.
Een split-tunnel-notitie die zegt "kantoortverkeer gaat via de VPN" heeft één beslissing gedocumenteerd en drie andere geïmpliceerd. Op de pakketlaag kiest een routingtabel een interface op bestemmingsadres; op de naamlaag kiest een resolver een server op query, en de twee keuzes worden onafhankelijk gemaakt. Daarom kan een correct gedocumenteerd prefix nog steeds een machine opleveren die een interne naam naar een openbaar adres oplost, of helemaal niets oplost terwijl de route perfect lijkt.
Twee selectors, één verbindingspoging
Wanneer een toepassing verbinding maakt met files.corp.example, vinden er twee opzoekingen plaats voordat er een pakket bestaat. De resolver beslist welke server de query ontvangt, met zoekdomeinen, routingdomeinen per link of een expliciete profielregel. De routingtabel beslist vervolgens waar het resulterende adres naartoe gaat, met de langste prefixmatch met de bestemming.
Niets verbindt die twee beslissingen. Een privézone kan antwoorden met 10.20.4.11 terwijl de routingtabel 10.20.0.0/16 de tunnel in stuurt, en de verbinding werkt. Draai een van beide om en het faalt op een manier die op de andere lijkt: juist DNS-beleid plus een ontbrekende route geeft een opgeloste naam en een time-out, terwijl een juiste route plus een openbare resolver een adres geeft dat netjes naar de verkeerde plek routeert.
Split-horizon-DNS maakt dit scherper. Dezelfde naam kan een privéadres van de interne resolver en een openbaar adres van de internetgerichte retourneren, dus een notitie die alleen het prefix vastlegt kan niet voorspellen welk adres de client daadwerkelijk gebruikt. Schrijf het resolverpad op, anders is het adres een gok.
Wat een notitie alleen over de route weglaat
Een registratie alleen over de route is onbruikbaar voor de meest voorkomende split-tunnelfout: namen. De gebruiker meldt dat het intranet niet laadt, de tunnel staat en het prefix is aanwezig. Wie het ticket oppakt heeft geen registratie van welke resolver had moeten antwoorden, geen manier om een verkeerd zoeksuffix van een geblokkeerde server te onderscheiden, en geen basislijn om mee te vergelijken.
De tweede weglating is de uitzonderingenlijst. Een split-tunnelontwerp wordt evenzeer bepaald door wat buiten de tunnel blijft als door wat erin komt, en de uitgesloten bereiken zijn meestal de eerste die breken, omdat een specifiekere lokale route of een filter aan de clientkant de bedoeling kan overrulen zonder het profiel aan te raken.
De derde is de verre kant van de tunnel. Een clientroute zet het pakket alleen op de kabel; de gateway moet het nog doorsturen en een terugweg hebben. strongSwans handleiding voor doorsturen herinnert eraan dat doorstuur- en firewallregels op de gateway deel van de functie zijn, niet deel van de loodgieterswerk dat je kunt aannemen.
De velden die de notitie uitvoerbaar maken
Eén rij per stroom, en een stroom is een bestemming plus een naam plus een eigenaar. Dit zijn de velden die contact met een echt incident overleven:
| 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 |
De rij "waar het woont" is degene die mensen overslaan. Een prefix dat door de server wordt geduwd, een route die door een clientprofiel wordt toegevoegd en een route die in een shell wordt getypt verschillen in wie ze kan wijzigen en of ze een herverbinding overleven. Zonder dat veld kan de volgende engineer niet zien welke van de drie hij bekijkt.
Eén test per regel, niet één per tunnel
Elke rij heeft twee onschuldige controles nodig: een die de route oefent en een die de naam oefent. Voor de route vraagt u iets aan dat de tunnel moet passeren en bevestigt u het pad in plaats van de bereikbaarheid, bijvoorbeeld tracert -d 10.20.4.11 op Windows of ip route get 10.20.4.11 op Linux. Voor de naam vraagt u de privénaam op en registreert u welke server antwoordde, met resolvectl query files.corp.example of dig files.corp.example tegen de resolver die de notitie noemt.
Voeg ook een negatieve verwachting toe: wat er moet gebeuren als de tunnel wegvalt. Een uitgesloten toepassing op een Android- of iOS-apparaat met blokkeren zonder VPN ingeschakeld heeft mogelijk helemaal geen connectiviteit, en een desktopclient kan dezelfde app laten werken terwijl de tunnel opnieuw verbinding maakt. Het bedoelde antwoord vastleggen maakt van "de VPN heeft mijn app kapotgemaakt" een controleerbare uitspraak.
Houd de registratie bij de configuratie
Bewaar de notitie naast het profiel dat ze beschrijft en versioneer ze met dat profiel. Een document in een wiki dat niemand bijwerkt is een gerucht; een tabel in dezelfde repository als de geduwde routes en het resolverbeleid kan in dezelfde wijziging worden beoordeeld.
Als er iets breekt, vergelijk dan de toegepaste route en de effectieve resolver met de registratie voordat u nog een uitzondering toevoegt. Twee van de drie veelvoorkomende oorzaken — een oude naamruimteregel en een hulpproces buiten het app-beleid — zien er precies als een VPN-storing uit en zijn onzichtbaar als de notitie alleen prefixen opsomt.
Voordat u de notitie af noemt, bevestig dat ze deze punten schriftelijk beantwoordt: welk prefix, voor welke adresfamilie; welke privé-naamruimte, beantwoord door welke resolver; welke namen bewust openbaar blijven; waar elke regel is geconfigureerd en wie eigenaar is; en het ene commando dat de route bewijst en het dat de naam bewijst. Als een van deze ontbreekt, wordt het volgende incident vanaf nul gediagnosticeerd.