Gateway VPN do Windows: três tarefas, três responsáveis

Três funções juntam-se sempre que alguém diz servidor VPN: terminar o túnel cifrado, mover pacotes entre redes e, opcionalmente, reescrever endereços. No Windows vivem em partes diferentes da pilha, mesmo quando uma só máquina faz as três. Cada uma tem as suas entradas e o seu próprio modo de falhar, e cada uma pode ser entregue a um produto diferente. Separá-las no papel é a forma mais barata de manter compreensível uma implementação pequena.

Um desenho legível nomeia o responsável de cada fluxo em vez de descrever a máquina como um papel.

Terminar, encaminhar, traduzir

O RRAS trata do túnel no caso nativo do Windows: autentica o utilizador, atribui um endereço de um conjunto e decide que destinos são permitidos. Outro produto VPN pode deter o ouvinte e o adaptador virtual, deixando o Windows encaminhar os pacotes decifrados. A documentação Remote Access da Microsoft separa as funções VPN, site a site e de encaminhamento, e instalar a função de encaminhamento não cria uma segunda identidade VPN. Acrescentar outra aplicação VPN também não entrega o seu adaptador a todas as funções de gateway existentes.

A tradução é a terceira tarefa e a mais opcional. Surge depois do encaminhamento e altera o endereço de origem que a rede remota vê. Se precisa dela depende do que a rede de destino aceitar como origem, não do facto de a máquina se chamar gateway VPN.

Quem é dono do adaptador e do conjunto

Quando vários produtos partilham o anfitrião, quatro coisas precisam de um único dono cada: portas de escuta, tempo de vida do adaptador, conjunto de endereços de clientes e rotas. O adaptador é o incómodo, porque um serviço VPN pode criá-lo dinamicamente e destruí-lo ao desligar. Tratar essa interface como uma placa de rede com nome permanente e escrever regras contra o seu nome funciona até à ligação seguinte. Utilize o ponto de integração suportado pelo produto em vez de codificar o nome de uma interface.

O conjunto de endereços é a segunda colisão. Dois produtos que distribuem intervalos sobrepostos produzem encaminhamento que parece correto e não entrega nada. Mantenha os conjuntos no mesmo documento que as rotas, para que uma alteração num seja visível face ao outro.

Preservar a origem ou reescrevê-la

Preservar o endereço de origem do cliente mantém a visibilidade por utilizador: registos, quotas e regras de firewall conseguem distinguir um utilizador de outro. O preço é que a LAN de destino precisa de uma rota de retorno para o gateway, e alguém tem de a manter. Reescrever a origem com NAT elimina esse requisito e elimina a visibilidade com ele. Escolha deliberadamente e anote que informação a reescrita esconde.

O acesso à rede privada, a saída para a internet e as ligações que terminam no próprio gateway são três caminhos diferentes. Não precisam todos do mesmo tratamento.

Descrever o fluxo numa frase

Uma frase deveria descrever o desenho: que clientes este serviço admite, que recursos essa política de encaminhamento concede e como o caminho de regresso completa o fluxo. Se a frase precisar de uma segunda camada de NAT para ser verdadeira, é geralmente sinal de que as peças anteriores não estavam resolvidas. O anfitrião é também uma fronteira partilhada de falha e de confiança, por isso uma alteração de encaminhamento pode afetar tanto o acesso dos utilizadores como a administração. Mantenha um caminho de recuperação independente para esta última.

Mantenha um inventário de funções ao lado da configuração: que produto termina, qual encaminha, qual traduz e quem pode alterar cada um. É essa lista que torna a alteração seguinte verificável.

Quando a frase fica confusa, acrescentar outra camada de tradução raramente a esclarece. Remover uma costuma esclarecer.