A documentación do túnel dividido necesita unha regra DNS xunto a cada ruta
Unha ruta decide por enderezo, un resolutor decide por nome. Documente ambos os selectores por fluxo, cada un cunha proba, ou a nota falla cando o DNS se move.
Unha nota de túnel dividido que di "o tráfico de oficina pasa pola VPN" documentou unha decisión e implicou outras tres. Na capa de paquetes, unha táboa de encamiñamento elixe unha interface por enderezo de destino; na capa de nomes, un resolutor elixe un servidor por consulta, e as dúas eleccións fanse de forma independente. Por iso un prefixo correctamente documentado aínda pode producir unha máquina que resolve un nome interno a un enderezo público, ou que non resolve nada mentres a ruta parece perfecta.
Dous selectores, un intento de conexión
Cando unha aplicación se conecta a files.corp.example, ocorren dúas buscas antes de que exista un paquete. O resolutor decide que servidor recibe a consulta, usando dominios de busca, dominios de encamiñamento por ligazón ou unha regra explícita de perfil. A táboa de encamiñamento decide despois a onde vai o enderezo resultante, usando a coincidencia de prefixo máis longa co destino.
Nada conecta esas dúas decisións. Unha zona privada pode responder con 10.20.4.11 mentres a táboa de encamiñamento envía 10.20.0.0/16 ao túnel, e a conexión funciona. Xire calquera das dúas e falla dun xeito que parece a outra: unha política DNS correcta máis unha ruta ausente dá un nome resolto e un tempo de espera, mentres que unha ruta correcta máis un resolutor público dá un enderezo que se encamiña limpiamente ao lugar equivocado.
O DNS de horizonte dividido faino máis agudo. O mesmo nome pode devolver un enderezo privado do resolutor interno e un enderezo público do que mira a internet, así que unha nota que só rexistra o prefixo non pode predicir que enderezo usará realmente o cliente. Escriba a ruta do resolutor ou o enderezo é unha suposición.
Que deixa fóra unha nota só de ruta
Un rexistro só de ruta é inútil para o fallo máis común do túnel dividido: os nomes. O usuario informa de que a intranet non carga, o túnel está levantado e o prefixo está presente. Quen colla o ticket non ten rexistro de que resolutor debería ter respondido, nin forma de distinguir un sufixo de busca incorrecto dun servidor bloqueado, nin unha liña base coa que comparar.
A segunda omisión é a lista de excepcións. Un deseño de túnel dividido defínese tanto polo que queda fóra do túnel como polo que entra nel, e os rangos excluídos adoitan ser os primeiros en romper, porque unha ruta local máis específica ou un filtro do lado do cliente poden anular a intención sen tocar o perfil.
A terceira é o lado afastado do túnel. Unha ruta de cliente só pon o paquete no cable; a pasarela aínda ten que reenvialo e ter un camiño de volta. A guía de reenvío de strongSwan lembra que as regras de reenvío e cortalumes na pasarela son parte da función, non parte da fontanería que se pode dar por suposta.
Os campos que fan executábel a nota
Unha fila por fluxo, e un fluxo é un destino máis un nome máis un propietario. Estes son os campos que sobreviven ao contacto cun incidente 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 |
A fila "onde vive" é a que a xente salta. Un prefixo empurrado polo servidor, unha ruta engadida por un perfil de cliente e unha ruta escrita nun shell difiren en quen as pode cambiar e en se sobreviven a unha reconexión. Sen ese campo, o seguinte enxeñeiro non pode dicir cal das tres está a mirar.
Unha proba por regra, non unha por túnel
Cada fila necesita dúas comprobacións inocuas: unha que exercita a ruta e outra que exercita o nome. Para a ruta, solicite algo que deba cruzar o túnel e confirme a ruta en lugar do alcance, por exemplo tracert -d 10.20.4.11 en Windows ou ip route get 10.20.4.11 en Linux. Para o nome, consulte o nome privado e rexistre que servidor respondeu, usando resolvectl query files.corp.example ou dig files.corp.example contra o resolutor que a nota nomea.
Engada tamén unha expectativa negativa: que debería pasar cando o túnel está caído. Unha aplicación excluída nun dispositivo Android ou iOS co bloqueo sen VPN activado pode non ter conectividade algunha, e un cliente de escritorio pode deixar a mesma aplicación funcionando mentres o túnel se reconecta. Rexistrar a resposta prevista converte "a VPN rompeu a miña aplicación" nunha afirmación comprobable.
Manteña o rexistro coa configuración
Garde a nota xunto ao perfil que describe e versiónea con ese perfil. Un documento nun wiki que ninguén actualiza é un rumor; unha táboa no mesmo repositorio que as rutas empurradas e a política do resolutor pódese revisar no mesmo cambio.
Cando algo rompe, compare a ruta aplicada e o resolutor efectivo co rexistro antes de engadir outra excepción. Dúas das tres causas comúns — unha regra antiga de espazo de nomes e un proceso auxiliar fóra da política da aplicación — parecen exactamente un fallo de VPN e son invisibles se a nota só lista prefixos.
Antes de dar a nota por rematada, confirme que responde por escrito a isto: que prefixo, para que familia de enderezos; que espazo de nomes privado, respondido por que resolutor; que nomes quedan deliberadamente públicos; onde se configura cada regra e quen a posúe; e o único comando que demostra a ruta e o que demostra o nome. Se falta algún, o próximo incidente diagnosticarase desde cero.