La documentació del túnel dividit necessita una regla DNS al costat de cada ruta
Una ruta decideix per adreça, un resolutor decideix per nom. Documenteu tots dos selectors per flux, cadascun amb una prova, o la nota falla quan el DNS es mou.
Una nota de túnel dividit que diu "el trànsit d'oficina passa per la VPN" ha documentat una decisió i n'ha implicat tres més. A la capa de paquets, una taula d'encaminament tria una interfície per adreça de destinació; a la capa de noms, un resolutor tria un servidor per consulta, i les dues tries es fan independentment. Per això un prefix correctament documentat encara pot produir una màquina que resol un nom intern a una adreça pública, o que no resol res mentre la ruta sembla perfecta.
Dos selectors, un intent de connexió
Quan una aplicació es connecta a files.corp.example, es fan dues cerques abans que existeixi un paquet. El resolutor decideix quin servidor rep la consulta, utilitzant dominis de cerca, dominis d'encaminament per enllaç o una regla explícita de perfil. La taula d'encaminament decideix després on va l'adreça resultant, utilitzant la coincidència de prefix més llarga amb la destinació.
Res no connecta aquestes dues decisions. Una zona privada pot respondre amb 10.20.4.11 mentre la taula d'encaminament envia 10.20.0.0/16 al túnel, i la connexió funciona. Gireu qualsevol de les dues i falla d'una manera que sembla l'altra: una política DNS correcta més una ruta absent dona un nom resolt i un temps d'espera, mentre que una ruta correcta més un resolutor públic dona una adreça que s'encamina netament al lloc equivocat.
El DNS d'horitzó dividit ho fa més agut. El mateix nom pot retornar una adreça privada del resolutor intern i una adreça pública del que mira a internet, així que una nota que només registra el prefix no pot predir quina adreça farà servir realment el client. Escriviu el camí del resolutor o l'adreça és una suposició.
Què deixa fora una nota només de ruta
Un registre només de ruta és inútil per a la fallada més comuna del túnel dividit: els noms. L'usuari informa que la intranet no es carrega, el túnel està aixecat i el prefix hi és. Qui agafi el tiquet no té cap registre de quin resolutor hauria d'haver respost, ni manera de distingir un sufix de cerca equivocat d'un servidor bloquejat, ni cap línia base per comparar.
La segona omissió és la llista d'excepcions. Un disseny de túnel dividit es defineix tant pel que queda fora del túnel com pel que hi entra, i els rangs exclosos solen ser els primers a trencar-se, perquè una ruta local més específica o un filtre del costat del client poden anul·lar la intenció sense tocar el perfil.
La tercera és el costat llunyà del túnel. Una ruta de client només posa el paquet al cable; la passarel·la encara ha de reenviar-lo i tenir un camí de tornada. La guia de reenviament de strongSwan recorda que les regles de reenviament i tallafocs a la passarel·la formen part de la funcionalitat, no de la fontaneria que podeu donar per feta.
Els camps que fan executable la nota
Una fila per flux, i un flux és una destinació més un nom més un propietari. Aquests són els camps que sobreviuen al contacte amb un incident real:
| 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 |
La fila "on viu" és la que la gent es salta. Un prefix empès pel servidor, una ruta afegida per un perfil de client i una ruta escrita en un shell difereixen en qui les pot canviar i en si sobreviuen a una reconnexió. Sense aquest camp, el següent enginyer no pot dir quina de les tres està mirant.
Una prova per regla, no una per túnel
Cada fila necessita dues comprovacions innòcues: una que exerceix la ruta i una que exerceix el nom. Per a la ruta, demaneu alguna cosa que hagi de creuar el túnel i confirmeu el camí en lloc de l'abast, per exemple tracert -d 10.20.4.11 a Windows o ip route get 10.20.4.11 a Linux. Per al nom, consulteu el nom privat i registreu quin servidor ha respost, utilitzant resolvectl query files.corp.example o dig files.corp.example contra el resolutor que la nota anomena.
Afegiu també una expectativa negativa: què hauria de passar quan el túnel està caigut. Una aplicació exclosa en un dispositiu Android o iOS amb el bloqueig sense VPN activat pot no tenir cap connectivitat, i un client d'escriptori pot deixar la mateixa aplicació funcionant mentre el túnel es reconnecta. Registrar la resposta prevista converteix "la VPN m'ha trencat l'aplicació" en una afirmació comprovable.
Manteniu el registre amb la configuració
Emmagatzemeu la nota al costat del perfil que descriu i versioneu-la amb aquest perfil. Un document en un wiki que ningú no actualitza és un rumor; una taula al mateix repositori que les rutes emeses i la política del resolutor es pot revisar en el mateix canvi.
Quan alguna cosa es trenca, compareu la ruta aplicada i el resolutor efectiu amb el registre abans d'afegir una altra excepció. Dues de les tres causes comunes — una regla antiga d'espai de noms i un procés auxiliar fora de la política de l'aplicació — semblen exactament una fallada de VPN i són invisibles si la nota només llista prefixes.
Abans de donar la nota per acabada, confirmeu que respon per escrit a això: quin prefix, per a quina família d'adreces; quin espai de noms privat, respost per quin resolutor; quins noms es queden deliberadament públics; on es configura cada regla i qui la posseeix; i l'única ordre que demostra la ruta i la que demostra el nom. Si falta qualsevol d'aquests, el proper incident es diagnosticarà des de zero.