O cliente VPN encamiñado chega ao servidor pero non aos equipos da LAN

O túnel levanta, o cliente fai ping ao servidor VPN e un recurso compartido nunha máquina a un salto de distancia nunca responde. Nada na configuración do cliente o explica, porque a petición si saíu do cliente e si chegou. O que fallou é a viaxe de volta, e o dispositivo que fallou adoita ser a pasarela da LAN e non o host VPN. Rastrexar o paquete de resposta explica toda esta clase de síntomas.

Siga a resposta, non a petición

O servidor VPN descifra o paquete do cliente e reenvíao á LAN co enderezo do cliente aínda no campo de orixe. O host de destino responde a ese enderezo, e agora a súa propia táboa de rutas decide todo. A súa pasarela predeterminada non sabe nada do grupo do túnel, así que a resposta sae cara ao provedor de internet e descártase nalgún punto dese camiño.

No cliente o síntoma é un tempo de espera silencioso: sen rexeitamento, sen reinicio, só nada. A exploración dun recurso compartido colga, o ping informa de que non hai resposta e os rexistros do servidor parecen sans porque o servidor fixo o seu traballo.

Poña a ruta de volta onde miran os equipos

Cada equipo da LAN consulta a súa pasarela predeterminada, así que a pasarela é o único dispositivo que necesita saber onde vive o grupo do túnel. Engada alí unha ruta estática e cada equipo herda o camiño correcto sen que se lle toque.

Se a pasarela reparte o seu propio enderezo como opción DHCP, distribúa a ruta desa forma para que as máquinas novas a collan automaticamente. Se non, a ruta vive nun ficheiro de configuración e desaparece na seguinte reconstrución.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Por que o NAT de orixe parece reparalo

Enmascarar o grupo de clientes detrás do enderezo do servidor VPN elimina o problema ao eliminar o enderezo do cliente do paquete. As respostas volven entón ao servidor, que xa sabe como chegar ao túnel, e todo funciona. O custo é que os equipos internos xa non poden ver quen é o cliente, e cada conexión parece orixinarse nunha soa máquina.

Ese intercambio ás veces é correcto, por exemplo cando a un dispositivo dun provedor non se lle pode dar unha ruta estática. Faga a regra non máis ampla que o grupo actual, porque unha regra escrita para un /24 deixa de coincidir o día en que o grupo se renumera a un /16, e o primeiro sinal é un lote de clientes novos que se conectan e non chegan a nada.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

O camiño na nube necesita tres axustes

Nunha VPC a mesma lagoa volve con outra forma, porque a subrede non ten ningunha ruta para o rango de clientes. A táboa de rutas necesita unha entrada para o grupo do túnel que apunte á interface de rede da instancia, e a interface necesita desactivada a comprobación de orixe e destino para que a plataforma acepte paquetes cuxa orixe non é o seu propio enderezo. Os grupos de seguridade e as ACL de rede tamén deben admitir o grupo en ambos os sentidos.

Cada omisión produce un fallo parcial distinto. Omita a entrada da táboa de rutas e as instancias privadas responden nunha subrede que non pode levar a resposta de volta ao grupo. Coa comprobación aínda activa, a plataforma descarta a resposta despois de que a instancia xa a enviase. Sen a regra do grupo de seguridade, a petición mesma nunca chega, e o cliente ve o tempo de espera unha capa antes.

Execute as comprobacións nesta orde

Confirme o reenvío e a política de filtrado antes de culpar o encamiñamento, porque un equipo que non reenviará falla do mesmo xeito silencioso. Despois lea o axuste efectivo de ruta inversa na interface que leva o túnel, xa que un filtro estrito pode descartar respostas que chegan dunha dirección inesperada.

Remate cunha captura tomada no equipo da LAN mentres o cliente lle fai ping. Unha petición que chega sen resposta correspondente demostra o camiño de volta, e unha petición que nunca chega devolve a culpa ao servidor ou ao túnel.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

A comprobación de orixe e destino está documentada na guía da interface de rede elástica. Configúrea na interface que realmente leva o tráfico do túnel, non nun adaptador non relacionado conectado á mesma instancia.