Usuario de pasarela en Access Server: encamiñar a LAN da sucursal dun cliente

Pode facer ping ao enderezo de túnel dun cliente OpenVPN e aínda así non chegar a ningún host da LAN que hai detrás. Access Server dálle ao cliente un enderezo do pool de VPN, e o enderezo do pool é o único que o servidor sabe que posúe. O prefixo da sucursal é un feito aparte que cómpre declarar, e aínda así a sucursal necesita un reenviador e a central unha ruta de volta. Unha ruta escrita no lugar equivocado parece unha solución e non cambia nada.

Dous enderezos, dúas reclamacións de propiedade distintas

Cando un cliente se conecta, Access Server asígnalle un enderezo do pool de VPN configurado, por exemplo 10.90.0.0/24. Esa asignación é un arrendamento para un só host. Nada na conexión di que o mesmo cliente tamén estea diante de 10.60.0.0/24, e o servidor non vai adiviñar: un prefixo LAN só é alcanzable a través dun cliente concreto se un administrador o declara.

Por iso unha ruta estática noutra máquina non serve. A ruta di envía 10.60.0.0/24 a este enderezo, pero se o enderezo pertence a un cliente que nunca se marcou como pasarela, o servidor non ten motivo para entregar alí eses paquetes, e a pila do cliente pode descartalos. A declaración e a ruta son dúas metades dun mesmo mecanismo.

Que instala realmente o axuste de pasarela

Na interface de administración a declaración é unha propiedade de usuario: active Configure VPN gateway no usuario conector e introduza o prefixo real da sucursal en Network on the VPN client side. Ese usuario autentícase coma calquera outro, así que necesita unha política de credenciais axeitada para un dispositivo sen supervisión, e o seu perfil de inicio automático é un segredo, non un ficheiro de comodidade.

Detrás desa caixa o servidor trata o prefixo como alcanzable a través do enderezo do pool dese cliente, e a configuración de encamiñamento en Access Controls decide que se anuncia aos demais clientes: as rutas que se envían aos clientes normais e as regras de acceso que permiten tráfico desde as redes da central cara a enderezos e subredes de clientes. Active o encamiñamento para as redes que deben chegar á sucursal e manteña curta a lista de redes permitidas.

Unha directiva ao estilo Community pegada nun ficheiro xerado non participa neste modelo. O produto é dono da táboa de encamiñamento que envía; unha liña editada a man sobrescríbese na seguinte xeración ou ignórase.

Complete as rutas de volta de ambas as redes

Un plan concreto: central 10.40.0.0/24, sucursal 10.60.0.0/24, pool de VPN 10.90.0.0/24 e Access Server accesible nun enderezo privado do lado da central. O router da central necesita rutas para o prefixo da sucursal e para o pool, ambas cara a Access Server. Sen elas o túnel leva a petición e a resposta sae pola pasarela predeterminada, o que produce a clásica conexión semiaberta.

Na sucursal o conector debe reenviar os paquetes que non van dirixidos a él: reenvío IP no seu sistema operativo máis un permiso de reenvío limitado ás interfaces de túnel e LAN; en Linux é net.ipv4.ip_forward=1 xunto coas regras da cadea forward, en Windows é routing and remote access. Despois os host da sucursal necesitan unha ruta de volta: ou o conector é a súa pasarela predeterminada, ou a pasarela existente leva rutas específicas para os prefixos da central e do pool.

A táboa de encamiñamento do conector non reconfigura todos os host da LAN da sucursal. Se os host apuntan a outro router, as rutas de volta pertencen alí, e ese router debe aceptar que o enderezo de orixe que ve non é un veciño da subrede local.

Lea un fallo como un camiño, non como un permiso

Probe nunha orde fixa. Primeiro un servizo permitido desde Access Server cara a un host da sucursal, despois o mesmo servizo desde un host normal da central, despois a dirección inversa se a política o permite. Se o primeiro pasa e o segundo falla, o problema son as rutas enviadas ou as regras de acceso. Se ambos pasan pero non chegan respostas, examine o reenvío na sucursal e a ruta de volta na central.

A devasa do host é o seguinte sospeitoso, porque con acceso encamiñado o destino ve como orixe un enderezo da central ou do pool. Unha regra escrita para a subrede local non coincidirá e o paquete descártase despois de que o encamiñamento funcionase perfectamente.

Dous deseños necesitan máis ca este patrón. Os prefixos solapados entre sitios fan ambigua a destino e esixen renumeración ou tradución, e un Access Server en clúster necesita que cada nodo teña un camiño funcional cara ao conector da sucursal, non un só nodo que reteña a ruta. Aplique os cambios pola vía normal de gardado e actualización, reconecte o conector e verifique de novo desde ambos os extremos; reiniciar por completo cada máquina non forma parte do procedemento.

O titorial site-to-site de Access Server enumera os mesmos axustes na orde do produto; paga a pena seguilo unha vez antes de adaptar o deseño aos seus propios prefixos.