Escreva o caminho do pacote antes de configurar a VPN

A maioria das instalações de VPN começa com um cliente e um perfil, e quando o túnel está de pé ninguém consegue dizer qual pacote deveria atravessá-lo. A primeira página de trabalho custa menos do que a terceira hora de depuração: descreva uma conexão pretendida de ponta a ponta, no papel, antes de existir um arquivo de configuração. O exercício costuma resolver uma pergunta que você ainda não tinha feito, como se o requisito é uma saída para a internet, um acesso remoto a uma sub-rede ou um link entre dois sites.

Uma conexão basta para começar. Três páginas de topologia costumam esconder a mesma resposta que falta.

Descreva uma requisição, não um diagrama

Comece pelo emissor: uma faixa de endereços, uma família de endereços e a aplicação que origina o tráfego. Depois nomeie o prefixo de destino e o serviço nele, até a porta e o protocolo, porque uma regra que permite a sub-rede mas não o serviço é uma regra que não faz nada. Os dois endereços são o ponto central, e tudo abaixo é a engrenagem que precisa concordar com eles.

Liste o caminho em ordem: o link físico, o endpoint da VPN em cada ponta, o próprio túnel e a rede além dele. Escreva os nomes das interfaces se você os conhece, porque esse detalhe é o que transforma uma descrição em algo que você pode comparar com uma tabela de roteamento depois. Acrescente o endereço que cada interface usa no lado do túnel. Sem esses dois dados, ninguém mais consegue conferir o registro contra o dispositivo.

Agora nomeie a única conexão pretendida em uma só frase no topo da página. Se essa frase precisar da palavra ou, você tem dois projetos e deve tratá-los separadamente.

Siga a resposta antes da requisição

Um caminho que descreve apenas a direção de saída é meio documento. Siga a resposta de volta e identifique qual dispositivo conhece a faixa do emissor, se uma tradução muda a origem na saída e onde se espera que o pacote de retorno entre. É na resposta que a maioria das instalações falha, porque a requisição é fácil de observar e a resposta não.

Anote explicitamente qualquer tradução de endereços, inclusive onde ela acontece e o que a outra ponta vê depois. Um par que registra um endereço e roteia para outro está descrevendo dois projetos diferentes.

Trate a resolução de nomes como uma troca própria, e não como parte da rota da aplicação. Um registro interno pode precisar de um resolver que só é alcançável pelo túnel, e um registro de caminho que para no prefixo da aplicação não vai revelá-lo. O mesmo vale para qualquer validação de certificado que dependa de alcançar uma autoridade interna.

Dê um responsável a cada decisão

Para cada rota, regra de firewall, seletor e credencial, anote qual configuração a contém e qual pessoa pode alterá-la. Um responsável por linha é o que faz o documento sobreviver ao primeiro pedido de mudança, porque a alternativa é um documento que descreve a intenção e uma rede que descreve o histórico.

Atenção a dois responsáveis por um mesmo padrão. Um script de cliente e um gerenciador de rede podem instalar rotas sem que um saiba do outro, e uma permissão de escuta no gateway não é a mesma permissão que o encaminhamento. Os dois casos produzem um registro de caminho correto no papel e errado no cabo.

Onde um valor é decidido por um provedor em vez de por você, diga isso na mesma linha. Um prefixo delegado por uma empresa de hospedagem tem um processo de mudança diferente de um que você escolheu. Essa nota poupa ao próximo engenheiro um chamado de suporte durante um incidente. Ela também explica por que uma mudança que você aprovou não teve efeito.

Descreva o que quebra e como você se recupera

Para cada etapa do caminho, diga o que para quando o túnel desaparece e qual conexão de saída precisa continuar alcançável para você consertar. Um projeto que perde o acesso de gestão junto com o túnel é um projeto que exige uma visita ao local.

Túnel completo e túnel dividido pertencem a esta página como uma escolha explícita e não como uma caixa de seleção, porque mudam tanto o modo de falha quanto o caminho de recuperação.

Nomeie um teste inofensivo para cada etapa

Alcançabilidade do endpoint, estabelecimento do túnel, endereço privado, nome privado e permissão da aplicação são cinco observações diferentes, e cada uma precisa de um teste que não possa ser confundido com outro. Um ping ao gateway prova as duas primeiras, no máximo. Uma conexão à porta da aplicação prova a quarta e a quinta só se o nome foi resolvido pelo resolver pretendido.

Escreva o teste ao lado da etapa que ele cobre, incluindo o comando e a saída esperada. Uma página de caminhos precisos vale mais do que uma página de comandos que nunca diz quais pacotes eles deveriam afetar.