Por que os clientes de OpenVPN perden os selectores IPsec da pasarela

Fai ping a un host detrás do túnel IPsec remoto desde a pasarela e responde limpo, así que o túnel parece san e o tícket avanza. Despois un cliente conectado proba o mesmo host e non recibe nada. Ese ping nunca foi unha proba do fluxo do cliente, porque saíu coa propia dirección de orixe da pasarela e coincidiu con outro selector IPsec. Entender por que os dous casos diverxen é a maior parte da solución.

O ping da pasarela proba un fluxo que o teu cliente nunca usa

A dirección de orixe decide que política se aplica. Un paquete xerado na pasarela sae cunha dirección da súa LAN local ou do seu extremo do túnel, e a política que coincide con el escribiuse exactamente para ese caso. O paquete dun cliente chega á interface OpenVPN cunha dirección do pool de clientes, que é un selector completamente distinto.

Por iso o fallo parece un problema de encamiñamento cando en realidade é un problema do alcance da política. A accesibilidade desde a pasarela demostra que o par está activo e que as propostas se negociaron, e non demostra nada sobre se o pool está protexido.

Empurra o prefixo remoto que a aplicación necesita de verdade

Toma o par ilustrativo 10.8.0.0/24 para os clientes conectados e 172.30.239.0/25 para a rede remota protexida. O que un cliente necesita é unha ruta cara a ese segundo prefixo, non cara á LAN da pasarela nin cara a outra dirección de túnel. Unha ruta empurrada ao pool é o que fai que o cliente entregue ese tráfico á pasarela. Sen ela, o paquete nunca chega á decisión de política que estás depurando.

Nun servidor Community que acepta rutas empurradas, a directiva toma a máscara real: push "route 172.30.239.0 255.255.255.128". Access Server configura o mesmo destino mediante os axustes de rede privada ou de regras de acceso da versión instalada, co modo encamiñado ou traducido elixido deliberadamente. Editar as cadeas de devasa xeradas en lugar da configuración propietaria é como unha instalación funcional se volve imposible de reproducir.

Despois de conectar, le a táboa de rutas do cliente e non a intención do servidor. Unha ruta que só cobre o pool significa que o empurrón nunca chegou, e unha ruta por defecto polo túnel é máis ampla que este requisito e sorprenderate máis adiante. Comproba a máscara e tamén o prefixo, porque un /25 empurrado como /24 envía o tráfico de direccións veciñas por un camiño que non o pode levar. Despois confirma que o cliente escolleu a interface do túnel para ese destino.

Fai que os selectores inclúan o pool de clientes

Para o acceso encamiñado que conserva as direccións dos clientes, a política IPsec ten que protexer o tráfico entre o pool e o prefixo remoto. Os selectores escritos para a LAN propia da pasarela admiten o ping e descartan a petición do cliente, e esa é exactamente a asimetría que iniciou esta investigación.

Inspecciona a política negociada e tamén as propostas configuradas, por exemplo con ipsec statusall en strongSwan ou a orde de estado equivalente da túa implementación. Con IPsec baseado en políticas, a ruta ordinaria pode apuntar a unha interface física mentres o tráfico coincidente segue cifrado, así que un dispositivo de túnel ausente non demostra nada. Compara os pares de selectores co pool e o prefixo que anotaches.

O NAT de orixe xenérico na pasarela tamén pode romper a coincidencia. Se unha regra de masquerade reescribe a orixe do cliente antes da comprobación de política, o paquete xa non se parece ao selector que escribiches. É unha razón pola que unha regra de masquerade ampla é unha mala solución para un segundo VPN: cambia que política se aplica e que dirección rexistra o lado remoto. Exime o tráfico que pretendes encamiñar, ou tradúceo a propósito e actualiza os selectores.

Escolle encamiñamento ou tradución a propósito

O encamiñamento mantén a dirección do cliente visible para o lado remoto, así que os rexistros remotos e as regras por orixe seguen tendo sentido, e esixe que a pasarela remota coñeza o camiño de volta ao pool. A tradución agocha o pool detrás dunha soa dirección, o que elimina o problema da ruta de volta e destrúe a identidade por cliente.

Escolle un deseño e escríbeo, porque os dous necesitan selectores distintos e unha orde de devasa distinta. Un masquerade aplicado a medias queda entre ambos e non satisfai ningún. A elección escrita é tamén o que permite ao seguinte enxeñeiro distinguir un fallo dunha decisión deliberada.

Pecha o bucle co reenvío e a resposta

A pasarela ten que reenviar o protocolo e o destino que pretendes, o que significa reenvío IP activado e unha cadea de reenvío que permita o par. Despois o lado remoto ten que devolver as respostas polo camiño IPsec, e iso é unha decisión de encamiñamento na súa pasarela e non na túa. As dúas metades son configuración corrente, e as dúas son fáciles de deixar a medias. Probaas por separado para que unha regra de reenvío ausente non se confunda cun túnel roto.

Verifica cunha petición real de cliente a aplicación, observando como cruza a interface OpenVPN, a decisión IPsec e o host remoto. Inspecciona a resposta como unha observación aparte, porque unha petición que chega e unha resposta que nunca volve vense iguais desde o asento do cliente. Unha petición trazada vale máis que calquera número de pings desde a pasarela.

Mantén estreita a autorización de destino mentres probas, e confirma que un cliente sen a regra non pode chegar ao servizo. Unha ruta instalada máis unha asociación establecida non é o mesmo que un acceso concedido.