VPN site a site ou acesso remoto: o que cada um une
Um une gateways, o outro une dispositivos. Compare os seletores de tráfego com as rotas, planeje o endereçamento e depois teste o encaminhamento e a política a partir de um host real.
Ambos os desenhos são chamados de VPN e resolvem problemas diferentes. Um túnel site a site une dois gateways, de modo que cada host atrás deles pode alcançar os endereços permitidos do outro lado sem instalar nada. Um túnel de acesso remoto une dispositivos individuais a uma rede, um cliente por vez. A comparação importa porque a maioria dos erros de implantação vem de configurar um desenho esperando o comportamento do outro, e o sintoma costuma ser um tempo limite esgotado num serviço que o túnel realmente alcançou.
Dois desenhos, duas fronteiras
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
Nenhum dos desenhos estende um domínio de difusão LAN. Os dispositivos do lado remoto não aparecem numa lista de descoberta local, e esperar que apareçam é a primeira suposição a abandonar. Nomes DNS privados que você publica de propósito são mais previsíveis do que qualquer protocolo de descoberta e sobrevivem a uma troca de fornecedor.
Use 10.10.0.0/24 num site e 10.20.0.0/24 no outro. O gateway A precisa de uma rota ou de um seletor de tráfego que envie o prefixo 10.20.0.0/24 para o túnel, e o gateway B precisa da imagem espelhada. Os hosts dos dois lados passam então a usar conectividade IP comum e nunca ficam sabendo que existe um túnel. Essa invisibilidade é a funcionalidade, e é também a razão pela qual as falhas parecem erros de rede comuns em vez de erros de túnel.
Baseado em política e baseado em rota não são o mesmo túnel
Numa implantação de IPsec baseada em política, os seletores de tráfego negociados definem exatamente quais pares de origem e destino estão protegidos. Se aparecer uma sub-rede nova atrás de um gateway e nenhum seletor a cobrir, o túnel continua ativo e a nova sub-rede simplesmente não é transportada. Num desenho baseado em rota, uma interface recebe o tráfego e a tabela de roteamento decide, o que faz com que adicionar um prefixo seja uma mudança de roteamento e não uma renegociação do túnel.
O StrongSwan expõe as duas visões diretamente, e lê-las em conjunto é como se descobre qual modelo você realmente implantou.
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'Uma lista de seletores que omite o prefixo de que você precisa explica a falha sem qualquer captura de pacotes, e uma rota apontando para a interface errada explica a falha espelho na volta. Leia as duas antes de renegociar qualquer coisa, porque uma renovação de chave não acrescenta um seletor que você nunca configurou.
Planeje o endereçamento antes do túnel
Faixas sobrepostas são o erro de desenho que não se corrige com configuração. Se os dois sites usam 192.168.1.0/24, um host que precisa de 192.168.1.50 tem dois candidatos e nenhuma forma de escolher. O túnel vai autenticar, as associações de segurança serão estabelecidas, e a decisão de roteamento será errada ou ambígua de qualquer maneira.
Escolha uma de três opções honestas: renumerar um site, traduzir a faixa sobreposta no gateway para que cada lado veja um prefixo distinto, ou abrir mão do roteamento direto para esses hosts e publicar o serviço de outra forma. Cada uma tem um custo, e a primeira costuma ser a mais barata num horizonte de dois anos. Decida antes de o túnel existir, porque depois a mudança atinge todo dispositivo que tenha o endereço antigo.
Resolva também a questão da MTU cedo. Um túnel reduz a carga útil, e um desenho que depende de fragmentação se comporta de forma diferente de um que fixa a MSS nos gateways.
O encaminhamento e a política ficam fora do túnel
O gateway precisa estar disposto a encaminhar pacotes entre a interface do túnel e a interface LAN, e ambas as direções precisam de política que permita o serviço. No Linux são dois ajustes separados, mais as regras de firewall que decidem se o fluxo encaminhado é permitido.
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTO host receptor acrescenta uma terceira camada: o próprio firewall dele ainda precisa aceitar um cliente da sub-rede remota. Um servidor de arquivos que só permite sua /24 local vai rejeitar o tráfego encaminhado de 10.20.0.7, por mais saudável que o túnel pareça, e essa rejeição é fácil de ler como falha de roteamento.
Teste a partir de um host, não do gateway
Um ping originado pelo próprio gateway pode seguir um endereço de origem e uma política diferentes do tráfego de usuário encaminhado. Isso o torna um teste fraco e, às vezes, enganoso: ele funciona enquanto a aplicação falha, ou falha enquanto a aplicação funciona.
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullUse um host real, um endereço de origem real e o protocolo real que a aplicação utiliza. Depois leia o caminho de volta separadamente, porque uma direção de ida que funciona sem rota de retorno produz um tempo limite esgotado idêntico ao de um serviço bloqueado.
Escolha o desenho pela pergunta que você responde: você está unindo redes ou admitindo dispositivos? Todo o resto, inclusive qual fornecedor você configura, decorre dessa resposta.