Por que os clientes de Access Server non son accesibles desde a LAN

O portátil conéctase, o túnel está activo e as peticións a un servizo interno quedan colgadas ao conectar. No propio servizo a petición chega desde un enderezo como 10.90.0.25, a resposta sae cara á pasarela predeterminada e non volve nada, porque esa pasarela non ten nin idea de onde vive 10.90.0.25. Desde o outro extremo, o mesmo fallo parece un host interno que non pode facer ping a un cliente conectado. Ambos son un só obxecto que falta: unha ruta de volta ao grupo de clientes VPN, que só a rede privada pode engadir.

Le o enderezo de orixe que ve o servizo

Ese único campo decide todo o demais. Se o servizo interno ve o enderezo do grupo, Access Server encamiña en vez de ocultar o tráfico dos clientes, e cada resposta debe encamiñarse de volta ao grupo. Se en cambio ve o enderezo privado do propio servidor, o servidor fai masquerade e a ruta de volta xa funciona, a costa de perder calquera identidade por cliente nos rexistros e nas regras de acceso do servizo.

Compara ambos os extremos antes de cambiar nada. No servidor, lista as interfaces do túnel e os seus enderezos; no cliente, confirma cal deses enderezos ten realmente; no host interno, mira unha conexión activa.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

O último comando é o que falla no caso roto: ou informa que o prefixo do túnel non é accesible ou, peor, devolve a túa pasarela predeterminada, e así é como as respostas acaban en internet.

Non supoñas un só grupo. Un servidor pode ter un rango dinámico máis asignacións estáticas por usuario, e o enderezo estático pode quedar completamente fóra do prefixo dinámico. Se só encamiñas o rango que recordas, os usuarios con enderezos fixos seguen rotos e todos os demais informan que o problema está resolto.

Engade a ruta onde se decide a resposta

A ruta pertence á pasarela que o servizo interno xa usa, non ao servizo, agás que encamiñe o seu propio tráfico. Apunta á dirección privada accesible de Access Server, que é un valor distinto do enderezo do túnel que ten un cliente.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

Nunha rede de nube a mesma afirmación convértese nunha entrada da táboa de rutas cuxo destino é a instancia ou a interface de rede onde se executa o servidor, coa comprobación de orixe e destino desactivada nesa interface. Fíxate no que esa entrada non fai: unha ruta non é unha concesión de acceso, así que os grupos de seguridade, as ACL de rede e a devasa do host aínda teñen que permitir o tráfico.

Faina persistente e mantén honestos os tamaños dos grupos. Dous grupos non contiguos necesitan dúas rutas, e un grupo que medra máis alá do seu prefixo configurado xera en silencio clientes cuxas respostas non teñen onde ir. Se controlas os rangos dos grupos, escolle un resumo que poidas encamiñar unha vez e deixar tranquilo.

O reenvío e as filtraxes deben coincidir coa ruta

O encamiñamento é só a metade do camiño. Hai que permitir que o servidor reenvíe entre o túnel e a interface privada, o que en Linux significa net.ipv4.ip_forward máis unha cadea de reenvío que permita o par de interfaces, e nun host endurecido normalmente unha regra explícita por dirección.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

A filtraxe con estado explica un síntoma que leva a xente polo camiño equivocado. Unha resposta dentro dun fluxo establecido non necesita unha regra de entrada nova, así que unha conexión que se colga tras o SYN-ACK non está bloqueada por unha regra de aceptación ausente; estase descartando ou encamiñando mal. Mantén esa distinción, porque separa un cambio de encamiñamento dun cambio de devasa.

As rutas de volta asimétricas son a versión máis silenciosa do mesmo problema. Se dúas rutas chegan ao grupo e a resposta toma a que sae por unha interface distinta daquela pola que chegou a petición, a filtraxe estrita de ruta inversa descártaa e o fluxo falla só para algúns clientes.

Encamiñado ou enmascarado: escolle a conciencia

O modo encamiñado conserva o enderezo do grupo do cliente no servizo, o que fai posibles o rexistro e a política por cliente, e a cambio cada rede interna que deba responder a un cliente necesita a ruta do grupo. O modo enmascarado elimina ese requisito porque as respostas volven ao servidor, pero o servizo xa non distingue un cliente doutro e non pode iniciar nada cara a un cliente concreto.

Cambiar ese comportamento nun servidor en produción corta as sesións existentes, así que proba primeiro cun cliente e un fluxo. Se o cambio é a resposta correcta, é unha decisión de configuración no servidor, non algo que se evite engadindo rutas que logo serán innecesarias.

Unha subrede detrás do cliente é unha tarefa aparte

Chegar a un dispositivo na propia LAN do portátil non é o mesmo que chegar ao enderezo do túnel do portátil. Require que o cliente actúe como pasarela de subrede: unha rede declarada no lado do cliente, o reenvío activado no sistema operativo do cliente e unha ruta nesa LAN de volta cara ao cliente. Engadir unha ruta de rede privada para o rango doméstico do portátil non fai isto, e crea conflitos cando dous usuarios teñen o mesmo rango doméstico.

A dirección tamén é unha cuestión de política. O permiso para que un cliente abra unha conexión a un servizo interno non permite automaticamente que un host interno abra unha conexión a ese cliente. Comproba a política de acceso do servidor e a devasa do host do cliente antes de concluír que o camiño está roto.

Verifica cun fluxo e unha captura

Demostra o camiño cunha soa conexión en lugar dunha proba xeral de accesibilidade. Observa o mesmo fluxo nos dous extremos: a petición que chega ao servizo e a resposta que sae del.

tcpdump -ni any host 10.90.0.25 and port 443

Antes da corrección a captura mostra a resposta saíndo cara a unha pasarela que non a encamiñará. Despois da corrección a resposta sae cara ao servidor e o fluxo complétase. Logo confirma a ruta que a pasarela usaría para un segundo enderezo de cliente, para que un grupo que non cubriches apareza agora e non dentro dunha semana.

Remata coas catro comprobacións que pechan o asunto: o enderezo de orixe no servizo coincide co modo que pretendías, a pasarela ten ruta a cada grupo en uso, o reenvío e as filtraxes permiten ambas as direccións, e un fluxo real complétase de extremo a extremo. Preguntas frecuentes de encamiñamento de Access Server expón o mesmo principio para a versión instalada, cuxa interface de configuración admitida pode diferir das guías antigas.