A documentação do túnel dividido precisa de uma regra DNS ao lado de cada rota
Uma rota decide por endereço, um resolvedor decide por nome. Documente os dois seletores por fluxo, cada um com um teste, ou a nota falha quando o DNS se desloca.
Uma nota de túnel dividido que diz "o tráfego do escritório passa pela VPN" documentou uma decisão e implicou outras três. Na camada de pacotes, uma tabela de roteamento escolhe uma interface pelo endereço de destino; na camada de nomes, um resolvedor escolhe um servidor pela consulta, e as duas escolhas são feitas de forma independente. Por isso um prefixo corretamente documentado ainda pode produzir uma máquina que resolve um nome interno para um endereço público, ou que não resolve nada enquanto a rota parece perfeita.
Dois seletores, uma tentativa de conexão
Quando uma aplicação se conecta a files.corp.example, ocorrem duas consultas antes de existir um pacote. O resolvedor decide qual servidor recebe a consulta, usando domínios de busca, domínios de roteamento por link ou uma regra explícita de perfil. A tabela de roteamento decide então para onde vai o endereço resultante, usando a correspondência de prefixo mais longa com o destino.
Nada conecta essas duas decisões. Uma zona privada pode responder com 10.20.4.11 enquanto a tabela de roteamento envia 10.20.0.0/16 para o túnel, e a conexão funciona. Inverta qualquer uma e ela falha de um modo que parece a outra: política DNS correta mais uma rota ausente dá um nome resolvido e um tempo limite, enquanto uma rota correta mais um resolvedor público dá um endereço que é roteado limpo para o lugar errado.
O DNS de horizonte dividido torna isso mais agudo. O mesmo nome pode devolver um endereço privado do resolvedor interno e um endereço público do voltado à internet, então uma nota que registra apenas o prefixo não pode prever qual endereço o cliente realmente usará. Escreva o caminho do resolvedor ou o endereço é um palpite.
O que uma nota só de rota deixa de fora
Um registro só de rota é inútil para a falha mais comum do túnel dividido: os nomes. O usuário relata que a intranet não carrega, o túnel está ativo e o prefixo está presente. Quem assume o chamado não tem registro de qual resolvedor deveria ter respondido, nem forma de distinguir um sufixo de busca errado de um servidor bloqueado, nem linha de base para comparar.
A segunda omissão é a lista de exceções. Um desenho de túnel dividido é definido tanto pelo que fica fora do túnel quanto pelo que entra nele, e as faixas excluídas costumam ser as primeiras a quebrar, porque uma rota local mais específica ou um filtro do lado do cliente pode anular a intenção sem tocar no perfil.
A terceira é o lado distante do túnel. Uma rota de cliente só coloca o pacote no fio; o gateway ainda precisa encaminhá-lo e ter um caminho de volta. O guia de encaminhamento do strongSwan lembra que as regras de encaminhamento e firewall no gateway fazem parte da funcionalidade, não do encanamento que se pode presumir.
Os campos que tornam a nota executável
Uma linha por fluxo, e um fluxo é um destino mais um nome mais um proprietário. Estes são os campos que sobrevivem ao contato com um 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 linha "onde vive" é a que as pessoas pulam. Um prefixo empurrado pelo servidor, uma rota adicionada por um perfil de cliente e uma rota digitada em um shell diferem em quem pode alterá-las e em se sobrevivem a uma reconexão. Sem esse campo, o próximo engenheiro não consegue dizer qual das três está olhando.
Um teste por regra, não um por túnel
Cada linha precisa de duas verificações inofensivas: uma que exercita a rota e outra que exercita o nome. Para a rota, peça algo que deva atravessar o túnel e confirme o caminho em vez do alcance, por exemplo tracert -d 10.20.4.11 no Windows ou ip route get 10.20.4.11 no Linux. Para o nome, consulte o nome privado e registre qual servidor respondeu, usando resolvectl query files.corp.example ou dig files.corp.example contra o resolvedor que a nota nomeia.
Adicione também uma expectativa negativa: o que deve acontecer quando o túnel está fora. Uma aplicação excluída em um dispositivo Android ou iOS com o bloqueio sem VPN ativado pode não ter conectividade alguma, e um cliente de desktop pode deixar a mesma aplicação funcionando enquanto o túnel se reconecta. Registrar a resposta pretendida transforma "a VPN quebrou meu aplicativo" em uma afirmação verificável.
Mantenha o registro com a configuração
Guarde a nota ao lado do perfil que ela descreve e versione-a com esse perfil. Um documento em um wiki que ninguém atualiza é um boato; uma tabela no mesmo repositório das rotas empurradas e da política do resolvedor pode ser revisada na mesma mudança.
Quando algo quebra, compare a rota aplicada e o resolvedor efetivo com o registro antes de acrescentar outra exceção. Duas das três causas comuns — uma regra antiga de espaço de nomes e um processo auxiliar fora da política do aplicativo — parecem exatamente uma falha de VPN e são invisíveis se a nota lista apenas prefixos.
Antes de dar a nota por concluída, confirme que ela responde por escrito a isto: qual prefixo, para qual família de endereços; qual espaço de nomes privado, respondido por qual resolvedor; quais nomes permanecem deliberadamente públicos; onde cada regra está configurada e quem a possui; e o único comando que prova a rota e o que prova o nome. Se faltar algum desses, o próximo incidente será diagnosticado do zero.