Adicionar uma segunda sub-rede a uma VPN site a site: dois caminhos

Adicionar uma segunda sub-rede a um túnel site a site em funcionamento leva cinco minutos num desenho e quase uma tarde inteira no outro. Quando o túnel instala rotas para os prefixos que você nomeia, você adiciona uma rota e o tráfego a segue. Quando negocia um par fixo de seletores, o novo prefixo fica sem proteção até os dois lados concordarem com um par correspondente. Três coisas decidem: o que a configuração de cada lado realmente descreve, se o tráfego negociado se estreita ao menor par correspondente e quem é o dono da rota de retorno do novo intervalo.

Leia o kernel, não o rótulo de estado

Um túnel que informa conexão instalou pelo menos uma associação filha, mas não necessariamente a que você pensa. No Linux o kernel mostra o que é aplicado: ip xfrm policy lista os pares de seletores e swanctl --list-sas (ou o antigo ipsec statusall) mostra o que os lados negociaram, incluindo os seletores de tráfego em cada direção. Se o novo prefixo não aparece em nenhum, ele está sem proteção, diga o que disser o arquivo de configuração.

Compare com a tabela de rotas. Num desenho baseado em rota, o dispositivo do túnel é o próximo salto dos prefixos protegidos. Um desenho baseado em política muitas vezes não tem rota específica para a sub-rede remota, apenas a rota padrão, porque a política escolhe o tráfego e não a tabela.

Baseado em política: os dois lados devem listar o novo prefixo

Em termos de strongSwan o seletor fica em local_ts e remote_ts na configuração filha, sucessores de leftsubnet e rightsubnet. O novo prefixo deve aparecer nos dois lados em espelho: o que o site A chama local, o site B chama remoto. A divergência raramente dá um erro limpo. Os lados estreitam-se à interseção, o prefixo antigo continua a funcionar e só o novo falha em silêncio.

swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policy

No pfSense ou OPNsense isso significa uma segunda entrada Phase 2 que emparelha a nova sub-rede local com a nova remota, e depois aplicar. Mantenha a entrada antiga; substituí-la move a sub-rede original em vez de adicionar. Se uma Phase 2 existente já cobre uma super-rede como 0.0.0.0/0 ou um intervalo resumido, não acrescente uma entrada mais estreita ao lado: seletores sobrepostos instalam políticas concorrentes e a ordem de avaliação decide qual vence.

O IKEv1 torna cada par de sub-redes a sua própria Phase 2, e um lado que aceita um par por troca descarta o resto. O IKEv2 pode transportar vários pares de seletores num filho, mas só se as duas implementações os aceitarem. A lista de swanctl --list-sas é a verdade; o que você digitou é um pedido.

Baseado em rota: a rota é a política

Uma interface XFRM ou um dispositivo VTI transporta tráfego conforme a tabela de rotas. Você aponta o novo prefixo para o dispositivo nos dois sites, e o estado ligado à transformação da interface aplica-se. Não há par de seletores para sincronizar, por isso este desenho escala melhor quando as sub-redes se multiplicam. O guia de encaminhamento do strongSwan detalha o lado do kernel.

ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10

O WireGuard leva a ideia mais longe. AllowedIPs é ao mesmo tempo a lista branca criptográfica e, através de wg-quick, a entrada na tabela de rotas. Adicione o prefixo só de um lado e terá aperto de mão, pacotes de saída e silêncio, porque o outro lado descarta pacotes cuja origem não está na lista. A forma wg set substitui a lista inteira, por isso repita os prefixos que já funcionavam ou vai cortá-los:

wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0

Esse segundo comando não é opcional quando usou wg set em vez de wg-quick. O kernel aceita a nova lista de imediato, mas nada acrescenta uma rota para ela, por isso o tráfego gerado localmente continua a sair pela gateway padrão. É a razão mais comum de uma nova sub-rede WireGuard funcionar a partir do host do túnel e não de um portátil.

A rota de retorno falha mais vezes que o túnel

Os hosts da nova sub-rede remota têm de enviar as respostas pela gateway VPN. Quando essa gateway não é o router padrão deles, a resposta vai para o router da LAN, que a descarta ou a reencaminha para a internet com um endereço de origem privado. Teste a partir de um host do lado remoto e não da gateway: ip route get 10.30.20.15 no Linux ou Find-NetRoute -RemoteIPAddress 10.30.20.15 no PowerShell mostra o próximo salto que o host usa de facto. Se a resposta não for o extremo do túnel, acrescente aí uma rota estática para o novo prefixo.

O NAT de origem no site que não tem a rota de retorno é uma alternativa legítima e a forma como muitas implementações hub-and-spoke evitam tocar em cada servidor. Aplique-o também ao novo prefixo na gateway do lado de destino:

iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADE

O custo é real. Os registos remotos deixam de mostrar endereços de origem individuais e as regras de firewall ligadas à sub-rede original colapsam numa só regra para a gateway. Escolha isso de propósito, não porque faltava uma rota.

As firewalls são a outra metade da rota de retorno. Os dispositivos por zonas não estendem automaticamente a zona de uma interface de túnel existente a uma nova sub-rede, e uma regra escrita para o prefixo antigo não vai corresponder. Acrescente a nova sub-rede à zona ou ao par de regras nos dois sentidos antes de culpar o IPsec.

Decida com três perguntas e verifique com tráfego

A versão curta: a configuração do lado nomeia prefixos (baseada em política) ou o tráfego é encaminhado para uma interface (baseada em rota)? Os dois extremos listam o novo prefixo? Existe um caminho de volta da nova sub-rede ao intervalo de origem original?

A verificação é onde a maioria das alterações é fechada cedo demais. Um ping a partir da gateway prova pouco, porque a gateway envia de si mesma e muitas vezes corresponde a uma política diferente da de um host. Faça ping a partir de um host na nova sub-rede, execute depois a aplicação que motivou a alteração e olhe para contadores, não para um ícone de estado.

tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg show

Num túnel baseado em política os contadores de ip xfrm state devem subir nos dois sentidos; contadores parados significam que o pacote é encaminhado mas não selecionado. No WireGuard o wg show reporta a transferência por lado, e um aperto de mão sem bytes recebidos aponta para a lista do outro lado ou para a sua rota de retorno.

Termine registando o prefixo, o seletor ou a rota do lado, a decisão sobre a rota de retorno e a entrada da firewall junto com o resto do inventário do túnel. Depois reinicie uma gateway e teste de novo: uma rota adicionada à mão desaparece e a próxima pessoa não devia ter de redescobrir isso.