Regras de VPN no router: combine a origem e o destino
Uma regra de VPN no router tem duas pontas: o dispositivo que envia tráfego e o destino que deve usar o túnel. Decida primeiro a interseção e o comportamento de reserva.
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:
| Scenario | Sender match | Target match | Rule shape |
|---|---|---|---|
| Media player uses the tunnel | Player address | Any internet destination except the LAN | Source only |
| Office prefix reachable | Authorized LAN devices | 10.40.0.0/16 | Target only |
| One app on one laptop | Laptop address | The service address set | Source and target |
| Guest network never tunnels | Guest subnet | Any | Deny, 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.