As páginas de compra de routers apresentam o encaminhamento VPN como uma caixa de seleção, e a frase esconde três perguntas diferentes. A regra corresponde ao dispositivo que envia o tráfego, ao servidor que o recebe ou aos dois? O que acontece ao tráfego que não corresponde a nenhum? E quando duas regras se sobrepõem, qual ganha? Escrever a resposta como um par de origem e destino transforma uma lista vaga de funções num projeto testável.

O nome da função esconde duas pontas

Um reprodutor de mídia que deve usar o túnel é uma correspondência de origem. Um prefixo de escritório privado que deve ser acessível pelo túnel é uma correspondência de destino. Uma estação de trabalho que deve usar o túnel apenas para um serviço é ambas, e essa interseção é o caso que a maioria do firmware de consumidor trata mal.

Escreva o requisito como um par antes de comparar produtos. Esse par é o que vai testar mais tarde.

Um produto que oferece uma lista de dispositivos ou uma lista global de destinos pode não conseguir expressar «apenas este dispositivo, apenas estes destinos». A diferença não é estética: uma regra global de destino envia o tráfego de todos os dispositivos para esse site pelo túnel, e uma regra de dispositivo envia todo o tráfego desse dispositivo. Nenhuma das duas é o requisito. Teste esse caso com dois dispositivos antes de confiar no ecrã.

Construa a regra como uma interseção

Uma tabela mantém o projeto honesto. Coloque o cenário à esquerda e depois nomeie em separado a correspondência do emissor e a do destino:

ScenarioSender matchTarget matchRule shape
Media player uses the tunnelPlayer addressAny internet destination except the LANSource only
Office prefix reachableAuthorized LAN devices10.40.0.0/16Target only
One app on one laptopLaptop addressThe service address setSource and target
Guest network never tunnelsGuest subnetAnyDeny, evaluated first

A terceira linha é a interessante, porque precisa das duas metades ao mesmo tempo. Se o firmware só consegue expressar um eixo, o requisito tem de ser dividido em duas regras ou movido para um dispositivo que o consiga fazer.

Mantenha estável a identidade da origem. Uma reserva DHCP, um segmento dedicado ou um mecanismo de identidade do dispositivo funcionam, mas um endereço que muda depois de o aluguer expirar não. Inclua IPv6, porque um endereço IPv4 não identifica todo o tráfego de um dispositivo.

A prioridade decide a sobreposição

A sobreposição de regras é normal. Uma regra ampla de dispositivo e uma regra estreita de destino podem descrever o mesmo fluxo, e a ordem de prioridade documentada decide qual ganha. Um ecrã de configurações atraente não lhe diz essa ordem.

Leia o manual para a ordem e para o caso sem correspondência, e depois teste os dois com tráfego que possa observar:

ip rule show
ip route get 203.0.113.10

Se a documentação não indicar a ordem, assuma que a regra mais estreita pode não ganhar e projete com isso em conta. Duas regras que não podem entrar em conflito são mais fáceis de manter do que uma regra astuta com precedência não documentada.

Os nomes precisam de uma política de atualização

Um destino escrito como domínio acrescenta um problema de manutenção. O router tem de o resolver, atualizar o mapeamento, lidar com vários endereços e subdomínios e enfrentar o DNS de aplicações que contorna o resolvedor esperado.

Copiar um único resultado de pesquisa para uma regra IP é um instantâneo, não uma política de domínio.

Decida quanto pode envelhecer uma resposta antes de a regra ficar errada e o que o router faz quando a resolução falha. Uma regra que mantém o último endereço conhecido pode sobreviver a uma migração de serviço; uma regra que descarta a entrada pode parar o túnel em silêncio. Qualquer dos comportamentos é aceitável se estiver escrito junto da regra.

Defina o estado indisponível

Uma preferência de rota não impõe tráfego apenas por VPN. Quando o túnel está em baixo, o router pode bloquear o fluxo, enviá-lo diretamente ou usar outro túnel, e cada escolha tem uma assinatura de falha diferente.

Decida qual é necessário ao requisito e depois verifique-o parando o túnel e observando o fluxo:

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

O tráfego originado pelo próprio router é um âmbito separado. O encaminhamento de DNS, as verificações de atualização e a monitorização podem iniciar novos fluxos a partir do próprio router em vez de herdar a correspondência de origem do dispositivo. Tenha esses fluxos em conta de forma explícita, ou aparecerão como fugas inexplicadas nos registos.

Artigos relacionados