Os usuarios remotos non chegan ao segundo sitio a través do concentrador VPN

Un usuario remoto conéctase ao concentrador, chega ao servidor de ficheiros da propia LAN do concentrador e todo parece san. Despois abre un recurso compartido en 10.20.0.50 na sede central, ao que o concentrador chega por un túnel independente entre sedes, e expira. Ambos os túneles están activos e ambos os contadores soben, así que ningún túnel está roto. Cruzar o concentrador son tres decisións de encamiñamento en tres dispositivos, e un túnel só transporta os prefixos para os que se construíu. Esta é a orde que comprobo, e o comando que mostra se cada paso é certo.

O tránsito necesita tres consultas, non un só túnel

Cada dispositivo fai a súa propia coincidencia de prefixo máis longo e olvídaa. O portátil debe enviar 10.20.0.50 ao túnel en lugar de ao seu router local. O concentrador debe coller un paquete que chegou pola interface de acceso remoto e entregalo á interface entre sedes. A sede central debe enviar unha resposta para o enderezo do usuario de volta polo túnel. Que falle calquera das tres cousas vese igual no navegador: silencio.

Por iso probar cada túnel por separado demostra tan pouco. Facer ping ao enderezo LAN do concentrador exercita a primeira decisión, e facer ping ao concentrador desde a sede central exercita a terceira. O paquete que falla ten o grupo de usuarios como orixe e o segundo sitio como destino, así que anota eses prefixos primeiro. Aquí o grupo é 10.80.0.0/24, a LAN do concentrador é 10.10.0.0/24 e a sede central é 10.20.0.0/24.

Empurra o prefixo remoto ao cliente remoto

Nun OpenVPN servidor de acceso remoto o cliente aprende as rutas ao conectarse. Sen un push, un cliente con túnel dividido envía 10.20.0.50 ao seu propio portal e o paquete nunca entra no túnel.

push "route 10.20.0.0 255.255.255.0"

Unha ruta empurrada aplícase cando o cliente se conecta, así que un usuario que segue en liña non ve nada ata que se reconecta. Compróbao no cliente: ip route get 10.20.0.50 en Linux, route print en Windows. A saída debe nomear a interface do túnel.

O push non axuda ao concentrador. É unha mensaxe ao cliente, non unha ruta no servidor nin un permiso para reenviar, así que un concentrador coa liña push perfecta segue descartando o fluxo un salto despois. É a razón habitual pola que a xente conclúe que o push fallou.

Dálle ao concentrador unha ruta de saída real

O concentrador necesita o seu propio seguinte salto para o prefixo da sede central. Nun túnel encamiñado é unha ruta ordinaria pola interface entre sedes, e un só comando mostra tanto a ruta escollida como a orixe escollida:

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

Cando o treito entre sedes é á súa vez OpenVPN, a ruta pode vivir nesa configuración co enderezo de túnel do par como portal: route 10.20.0.0 255.255.255.0 172.30.0.2. O portal non é opcional. Se o omitís, o seguinte salto cae nun valor por defecto da implementación, que difire entre un cliente dun só par e un concentrador con varios pares.

O IPsec baseado en políticas é distinto: o núcleo do concentrador envía o paquete ao seu portal LAN habitual e a política captúrao á saída, así que unha ruta de túnel ou non fai nada ou desvía o tráfico máis alá da política. Vixía a orixe no comando anterior, porque 10.10.0.1 en lugar do enderezo do grupo significa que o núcleo escolleu un enderezo que o lado remoto rexeitará. iroute tampouco é a resposta; dille ao servidor que cliente posúe unha subrede detrás do seu propio túnel, non onde enviar o tráfico dun terceiro sitio.

Estende o lado remoto ao grupo de usuarios

A sede central xa cobre a LAN do concentrador, 10.10.0.0/24. O grupo de usuarios é un segundo prefixo e tamén debe estar nos selectores, ou ningunha política cobre unha resposta dirixida a 10.80.0.25. Cada par nomea o mesmo par de conxuntos de prefixos desde o 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 dun dispositivo é o remote_ts do outro. Copia o bloque do concentrador na sede central e o par queda invertido, así que a child SA nunca sobe.

A sintaxe máis antiga de ipsec.conf usa un leftsubnet separado por comas. A asociación de seguridade en curso conserva os selectores que negociou, así que restablece o túnel tras a edición. Un selector cambiado ás 10:00 e probado contra unha SA levantada ás 09:40 segue fallando, mentres o ficheiro de configuración parece correcto todo o tempo.

Despois comproba o último salto. ip route get 10.80.0.25 no extremo remoto debe apuntar ao túnel. Se o servizo usa un router LAN como portal por defecto, ese router tamén necesita a ruta de volta, ou a resposta morre alí. Executar tcpdump -ni eth1 host 10.80.0.25 nese segmento mostra se a resposta saíu do extremo.

Permite o fluxo no concentrador

O reenvío debe estar activado e o camiño permitido. Acouta as regras aos dous prefixos en lugar de aceptar todo 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

O filtrado de ruta inversa é o fallo silencioso ao lado: coas dúas pernas en interfaces distintas, rp_filter=1 pode descartar a resposta mentres o contador da regra de aceptación nunca se move. Compara iptables -vnL FORWARD antes e despois dun intento. Unha regra que nunca incrementa non se alcanza, así que mira unha capa máis abaixo en lugar de reescribila.

Se só un grupo necesita tránsito, pon a ruta nun ficheiro por cliente baixo client-config-dir en lugar de ampliar o push global. O NAT de orixe no concentrador tamén elimina a necesidade dunha ruta de volta remota, pero oculta o enderezo do usuario, así que os rexistros do sitio remoto e as regras baseadas en enderezos deixan de distinguir os usuarios.

Comproba desde o cliente e despois reverte en orde inversa

Proba un porto TCP, non só ICMP, porque un ping pode pasar mentres o servizo segue bloqueado. nc -vz 10.20.0.50 445 e traceroute -n 10.20.0.50 desde o cliente mostran se o segundo salto é o enderezo de túnel do concentrador. No concentrador, tcpdump -ni tun0 host 10.20.0.50 e o mesmo filtro na interface entre sedes: unha petición en ambas sen resposta en ningunha move o problema ao lado remoto.

Despois proba algo que debe seguir bloqueado. Se tamén responde un equipo que o grupo nunca debería alcanzar, abriches máis que o tránsito e deberías estreitar as regras. Un concentrador que reenvía todo a cada rama pasa a primeira proba e falla a segunda.

Mantén unha lista de reversión, porque cambiaron catro obxectos e tres son fáciles de esquecer: a ruta empurrada, a ruta do concentrador, os selectores e as regras da devasa. Desfai en orde inversa, restablece a SA e fai que un usuario se reconecte. Unha reversión parcial deixa unha ruta apuntando a un túnel que xa non coincide, o que é máis difícil de ler que o silencio orixinal. O manual de OpenVPN 2.6 documenta push, route e iroute para a túa versión.