Dálle aos equipos da LAN unha ruta de retorno VPN coa opción 121 de DHCP

Os clientes VPN remotos conéctanse, o servidor da LAN responde e a resposta sae polo router de internet habitual e morre alí. Un servidor pódese arranxar cunha ruta estática, pero unha subrede enteira deles xestiónase mellor onde xa reciben a súa configuración de rede. A opción 121 de DHCPv4 distribúe exactamente ese tipo de ruta de destino, e é a parte que a xente adoita facer mal en canto esquece a predeterminada. O síntoma é tráfico nun só sentido: chegan as peticións e desaparecen as respostas.

Nomea primeiro os tres enderezos

Toma unha LAN concreta: 192.168.50.0/24 co router predeterminado habitual en 192.168.50.1 e unha pasarela VPN separada en 192.168.50.2. Os clientes remotos autenticados ocupan 10.90.0.0/24.

A ruta que necesita cada equipo participante é 10.90.0.0/24 via 192.168.50.2. O destino é o grupo de clientes e o seguinte salto é o enderezo LAN da pasarela, non o seu enderezo de túnel.

Codifícaa como ruta estática sen clase

A opción 121 transporta pares de prefixo e seguinte salto, e RFC 3442 define tanto a codificación como o comportamento do cliente que se deriva. Para unha instancia de dnsmasq existente que só serve esta LAN ilustrativa, a forma da configuración é:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

Iso é un fragmento, non un servizo DHCP novo. Nun servidor que atende varios segmentos, limita a opción coas etiquetas ou a política de rede que xa usas. Ten a configuración anterior á man, porque reverter isto significa outra renovación da concesión, non un reinicio.

Non perdas a ruta predeterminada

Esta é a trampa. Un cliente que recibe a opción 121 debe ignorar a opción Router habitual, así que anunciar só a ruta do grupo VPN pode deixar ese equipo sen ningunha ruta predeterminada. A máquina segue parecendo configurada e perde internet en silencio. Os usuarios descríbeno como que a rede está caída mentres todas as interfaces están activas.

Inclúe a predeterminada prevista na mesma lista, como fai o fragmento anterior. Mantén tamén a opción Router habitual para os clientes que non implementan rutas sen clase; o manexo propio de opcións do servidor decide que se envía a quen.

Comproba que aceptará o cliente

Un equipo con enderezo manual nunca recolle isto, porque non pide unha concesión. O soporte dos clientes tamén varía, así que proba no sistema operativo que realmente executas en lugar de supor que cada dispositivo respecta a opción 121. Confirma con quen posúe eses servidores cales teñen enderezo estático. Eses equipos necesitan as súas propias entradas de ruta ou simplemente non participarán.

Os servizos DHCP xestionados son outro límite. Algunhas redes na nube non deixan que os administradores publiquen opcións arbitrarias, e un servidor DHCP competidor no mesmo segmento é peor que non ter ningunha opción.

Verifica a concesión e despois a consulta

Fai que o propietario do DHCP aplique o cambio e logo renova a concesión nun cliente. As concesións existentes manteñen a configuración antiga ata que se renovan, así que os resultados inmediatos non están garantidos.

Nun cliente Linux, le as rutas reais e confirma as dúas entradas:

ip -4 route
ip -4 route get 10.90.0.23

A consulta contextual debería mostrar a ruta do grupo a través de 192.168.50.2 e a predeterminada a través de 192.168.50.1. Se falta a predeterminada, reproduciches a trampa anterior.

Despois proba o intercambio real

A distribución de rutas non é todo o camiño. A pasarela separada aínda necesita reenvío, propiedade dos pares remotos e unha política de acceso que permita o servidor, e DHCP non autentica a ninguén.

Por último, mantén un plan de retirada. Unha ruta estática aprendida non se retira soa cando a VPN cae, así que un seguinte salto obsoleto pode converter ese prefixo nun burato negro moito despois de que o túnel desaparecese.