A resposta da VPN de sitio a sitio non atravesa o túnel
Unha resposta que se salta o túnel é unha decisión de encamiñamento do lado remoto. Revise a táboa de hosts, os selectores e rp_filter, e despois escolla ruta ou NAT.
Pasei unha mañá cun túnel que se erguía limpo e movía tráfico exactamente nunha dirección: a sucursal chegaba ao servidor de ficheiros da sede, e cada conexión aberta desde a sede cara á sucursal morría no primeiro SYN. As SA estaban activas, os contadores do túnel subían e o aperto de mans nunca foi o problema. A resposta encamiñábase cara a algún lugar que o túnel non cobre, e esa escolla pertence ao lado remoto. Unha VPN de sitio a sitio só transporta os paquetes que un host entrega á pasarela, e cada host toma esa escolla por separado, en cada dirección, desde a súa propia táboa de encamiñamento.
As dúas direccións encamíñanse por separado
IP non garda memoria da dirección dunha conversa. Cada host que envía un paquete executa a súa propia busca do prefixo máis longo, escolle un único salto seguinte e esquece a decisión. A petición e a resposta son dous paquetes sen relación que casualmente pertencen á mesma conexión, e o túnel é un salto que calquera dos dous pode usar ou non. Nada do intercambio IKE lle ensina ao servidor remoto como chegar á súa subrede; a negociación só acorda que prefixos poden cifrarse.
Ese acordo é a segunda porta. En strongSwan os selectores de tráfico son leftsubnet e rightsubnet, e un paquete cuxa orixe ou destino queda fóra do par negociado non se cifra, diga o que diga a táboa de encamiñamento. Un prefixo que se encamiña cara ao túnel pero falta nos selectores é un fallo silencioso dun só sentido: a ruta parece correcta, o paquete sae igualmente en claro ou descártase, e só o rexistro de charon se queixa.
O host remoto non sabe nada do seu túnel
Dentro da LAN remota a resposta é un paquete normal dirixido ao seu cliente. O host de destino non ve ningunha cabeceira IPsec e non ten motivo para preferir a pasarela VPN; busca o seu prefixo, non atopa nada máis específico ca a súa ruta por defecto e séguena. Se a ruta por defecto apunta a unha devasa central, a devasa ten ou non ten unha ruta de volta ao túnel. Cando non a ten, obtén un descarte silencioso, un ICMP unreachable ou unha resposta que sae pola interface orientada a internet e morre.
Unha segunda interface abonda para romper isto mesmo cando existe unha ruta. Un NAS cunha ligazón de xestión noutra VLAN, un servidor cun uplink de reserva, unha regra de política que envía un rango de orixe a unha segunda táboa: calquera destas cousas pode capturar a resposta. En Linux, ip rule show e ip route show table all mostran regras e táboas que a listaxe por defecto agocha.
Lea a decisión na máquina que envía a resposta
Pregúntelle ao núcleo antes de cambiar nada, e déalle o enderezo de orixe, porque as regras que dependen da orixe cambian a resposta.
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"A saída nomea a interface de saída e o salto seguinte. Se a interface non é a que mira cara á pasarela VPN, atopou o defecto, e o traballo restante é escoller onde debe estar a ruta. Un ping desde a pasarela demostra pouco aquí: responde cun enderezo que o host remoto pode situar, non co enderezo do seu portátil.
En Windows os equivalentes son Find-NetRoute -RemoteIPAddress 10.10.5.10 para a decisión e Get-NetRoute para a táboa. Unha ruta engadida con New-NetRoute que leva unha métrica máis alta ca a de por defecto perde en silencio, así que lea a columna de métrica, non a entrada. Logo confirme con paquetes: tcpdump -ni any "host 10.10.5.10 and tcp port 445" na interface LAN remota mostra a petición, e o mesmo filtro no lado do túnel mostra se volveu unha resposta. Petición visible sen resposta significa que a resposta se encamiñou a outro sitio ou se descartou; unha resposta na interface equivocada dálle o culpable antes de tocar unha ruta.
Cando a pasarela do servidor non é o extremo da VPN
Moitos sitios colocan unha devasa entre os servidores e o concentrador. Esa devasa reenvía a resposta, así que necesita unha ruta para o prefixo do seu cliente apuntando á pasarela VPN, e política de reenvío nas dúas direccións. Os dispositivos con estado empeórano: a petición cruzou a devasa desde un host LAN que permitiu, a resposta agora chega desde outra dirección e a entrada de seguimento de conexións xa non coincide, así que o paquete descártase como non válido en lugar de denegado. Por iso o rexistro de políticas parece baleiro mentres o tráfico desaparece.
A pasarela ten o seu propio segundo filtro. O filtrado de ruta inversa de Linux descarta paquetes cuxa orixe non é alcanzable pola interface pola que chegaron, que é exactamente a forma dun camiño de volta asimétrico lexítimo. a guía de reenvío de strongSwan pide net.ipv4.ip_forward e un net.ipv4.conf.all.rp_filter relaxado por ese motivo. Un valor estrito de 1 en calquera das dúas pasarelas rompe en silencio unha ruta correcta, e nstat -az mostra os descartes se sabe onde mirar.
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
Encamiñe ou traduza, e despois verifique nas dúas direccións
As dúas reparacións non son equivalentes. Engadir unha ruta mantén intacto o enderezo do cliente, así que as regras baseadas na orixe, os rexistros de auditoría e as aplicacións que anotan quen chama seguen funcionando; o prezo é que cada salto que toma a decisión necesita a ruta, que son máis lugares onde equivocarse. Enmascaramento na pasarela remota reduce o camiño de volta a un só salto, porque a resposta agora se dirixe á propia pasarela, e agocha que cliente fixo que.
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEEscóllao a conciencia: en canto os clientes aparecen como o enderezo da pasarela, as ACL baseadas na orixe deixan de distinguilos, e conntrack ten que manter a correspondencia para que a resposta se reescriba de volta ao túnel. Se os selectores seguen excluíndo o prefixo do cliente, NAT non cambia nada, porque a petición nunca entrou no túnel.
Antes de darlo por arranxado, confirme catro cousas en orde: a ruta no host que envía a resposta, a ruta en cada salto que a reenvía, os selectores que cobren ambos os prefixos e unha captura que mostre a resposta entrando no túnel coa orixe que espera. Despois repita a proba desde o outro sitio. Unha dirección que pasa é un deseño entreaberto, e a segunda dirección adoita fallar por un motivo distinto do que acaba de reparar.