Utilizadores remotos não chegam ao segundo site através do concentrador VPN

Um utilizador remoto liga-se ao concentrador, alcança o servidor de ficheiros na própria LAN do concentrador e tudo parece saudável. Depois abre uma partilha em 10.20.0.50 na sede, à qual o concentrador chega por um túnel site-to-site separado, e o pedido expira. Os dois túneis estão ativos e ambos os contadores sobem, pelo que nenhum túnel está avariado. Atravessar o concentrador são três decisões de encaminhamento em três equipamentos, e um túnel transporta apenas os prefixos para os quais foi criado. Aqui está a ordem que verifico, e o comando que mostra se cada passo é verdadeiro.

O trânsito exige três consultas, não um túnel

Cada equipamento faz a sua própria correspondência de prefixo mais longo e esquece-a. O portátil tem de enviar 10.20.0.50 para o túnel e não para o seu router local. O concentrador tem de receber um pacote que chegou pela interface de acesso remoto e entregá-lo à interface site-to-site. A sede tem de enviar uma resposta para o endereço do utilizador de volta pelo túnel. Qualquer uma das três falhas parece igual no navegador: silêncio.

É por isso que testar cada túnel isoladamente prova tão pouco. Fazer ping ao endereço LAN do concentrador exercita a primeira decisão, e fazer ping ao concentrador a partir da sede exercita a terceira. O pacote que falha tem a pool de utilizadores como origem e o segundo site como destino, por isso anote primeiro esses prefixos. Aqui a pool é 10.80.0.0/24, a LAN do concentrador é 10.10.0.0/24 e a sede é 10.20.0.0/24.

Empurre o prefixo remoto para o cliente remoto

Num servidor de acesso remoto OpenVPN o cliente aprende rotas no momento da ligação. Sem push, um cliente com túnel dividido envia 10.20.0.50 para o seu próprio gateway e o pacote nunca entra no túnel.

push "route 10.20.0.0 255.255.255.0"

Uma rota empurrada entra em vigor quando o cliente se liga, por isso um utilizador que fica online não vê nada até se voltar a ligar. Verifique no cliente: ip route get 10.20.0.50 em Linux, route print em Windows. A saída deve indicar a interface do túnel.

O push não ajuda o concentrador. É uma mensagem para o cliente, não uma rota no servidor nem uma permissão de encaminhamento, por isso um concentrador com uma linha push perfeita continua a deixar cair o fluxo um salto depois. É a razão habitual pela qual as pessoas concluem que o push falhou.

Dê ao concentrador uma rota de saída real

O concentrador precisa do seu próprio próximo salto para o prefixo da sede. Num túnel encaminhado isso é uma rota comum pela interface site-to-site, e um comando mostra tanto a rota escolhida como a origem escolhida:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

Quando a perna site-to-site é ela própria OpenVPN, a rota pode viver nessa configuração com o endereço de túnel do par como gateway: route 10.20.0.0 255.255.255.0 172.30.0.2. O gateway não é opcional. Se o omitir, o próximo salto cai num valor por defeito da implementação, que difere entre um cliente de um único remoto e um concentrador com vários pares.

O IPsec baseado em políticas é diferente: o kernel do concentrador envia o pacote para o seu gateway LAN normal e a política apanha-o à saída, por isso a rota do túnel ou não faz nada ou desvia o tráfego para fora da política. Repare na origem no comando acima, porque 10.10.0.1 em vez do endereço da pool significa que o kernel escolheu um endereço que o lado remoto vai rejeitar. iroute também não é a resposta; diz ao servidor qual cliente possui uma sub-rede atrás do seu próprio túnel, não para onde enviar tráfego de um terceiro site.

Estenda o lado remoto à pool de utilizadores

A sede já cobre a LAN do concentrador, 10.10.0.0/24. A pool de utilizadores é um segundo prefixo e também tem de estar nos seletores, senão nenhuma política cobre uma resposta dirigida a 10.80.0.25. Cada par nomeia o mesmo par de conjuntos de prefixos do seu lado:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

O local_ts de um equipamento é o remote_ts do outro. Copie o bloco do concentrador para a sede e o par inverte-se, por isso a SA filha nunca sobe.

A sintaxe mais antiga ipsec.conf usa leftsubnet separado por vírgulas. A associação de segurança em execução mantém os seletores que negociou, por isso restabeleça o túnel após a edição. Um seletor alterado às 10:00 e testado contra uma SA que subiu às 09:40 continua a falhar, embora o ficheiro de configuração pareça correto o tempo todo.

Depois verifique o último salto. ip route get 10.80.0.25 no extremo remoto deve apontar para o túnel. Se o serviço usar um router LAN como gateway predefinido, esse router também precisa da rota de retorno, senão a resposta morre ali. Executar tcpdump -ni eth1 host 10.80.0.25 nesse segmento mostra se a resposta chegou a sair do extremo.

Permita o fluxo no concentrador

O encaminhamento tem de estar ativo e o caminho autorizado. Limite as regras aos dois prefixos em vez de aceitar tudo entre as interfaces.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

A filtragem de caminho inverso é a falha silenciosa ao lado: com as duas pernas em interfaces diferentes, rp_filter=1 pode deixar cair a resposta enquanto o contador da regra de aceitação nunca se move. Compare iptables -vnL FORWARD antes e depois de uma tentativa. Uma regra que nunca aumenta não está a ser atingida, por isso olhe uma camada abaixo em vez de a reescrever.

Se apenas um grupo precisa de trânsito, coloque a rota num ficheiro por cliente em client-config-dir em vez de alargar o push global. O Source NAT no concentrador também remove a necessidade de uma rota de retorno no lado remoto, mas esconde o endereço do utilizador, por isso os registos do site remoto e as regras baseadas em endereços deixam de distinguir os utilizadores.

Verifique a partir do cliente e depois reverta na ordem inversa

Teste uma porta TCP, não apenas ICMP, porque um ping pode passar enquanto o serviço continua bloqueado. nc -vz 10.20.0.50 445 e traceroute -n 10.20.0.50 a partir do cliente mostram se o segundo salto é o endereço do túnel do concentrador. No concentrador, tcpdump -ni tun0 host 10.20.0.50 e o mesmo filtro na interface site-to-site: um pedido nos dois sem resposta em nenhum move o problema para o lado remoto.

Depois teste algo que deve permanecer bloqueado. Se um anfitrião a que a pool nunca deveria chegar também responder, abriu mais do que o trânsito e deve restringir as regras. Um concentrador que encaminha tudo para todos os ramos passa o primeiro teste e falha o segundo.

Mantenha uma lista de reversão, porque quatro objetos mudaram e três são fáceis de esquecer: a rota empurrada, a rota do concentrador, os seletores e as regras da firewall. Desfaça-os na ordem inversa, restabeleça a SA e faça um utilizador voltar a ligar-se. Uma reversão parcial deixa uma rota a apontar para um túnel que já não corresponde, o que é mais difícil de ler do que o silêncio original. O manual do OpenVPN 2.6 documenta push, route e iroute para a sua versão.