Dona una ruta de retorn VPN als equips de la LAN amb l'opció 121 de DHCP

Els clients VPN remots es connecten, el servidor de la LAN respon, i la resposta surt pel router d'internet habitual i mor allà. Un servidor es pot arreglar amb una ruta estàtica, però una subxarxa sencera és millor gestionar-la on ja reben la seva configuració de xarxa. L'opció 121 de DHCPv4 distribueix exactament aquest tipus de ruta de destí, i és la part que la gent sol equivocar en el moment que oblida la ruta per defecte. El símptoma és tràfic en un sol sentit: les peticions arriben i les respostes desapareixen.

Primer anomeneu les tres adreces

Preneu una LAN concreta: 192.168.50.0/24 amb el router per defecte habitual a 192.168.50.1 i una passarel·la VPN separada a 192.168.50.2. Els clients remots autenticats ocupen 10.90.0.0/24.

La ruta que necessita cada equip participant és 10.90.0.0/24 via 192.168.50.2. La destinació és el pool de clients, i el següent salt és l'adreça LAN de la passarel·la, no la seva adreça de túnel.

Codifiqueu-la com a ruta estàtica sense classe

L'opció 121 porta parells de prefix i següent salt, i RFC 3442 defineix tant la codificació com el comportament del client que se'n deriva. Per a una instància de dnsmasq existent que només serveix aquesta LAN il·lustrativa, la forma de la configuració és:

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

Això és un fragment, no un servei DHCP nou. En un servidor que gestiona diversos segments, limiteu l'opció amb les etiquetes o la política de xarxa que ja feu servir. Tingueu la configuració anterior a mà, perquè tornar enrere vol dir una altra renovació de la concessió, no un reinici.

No perdeu la ruta per defecte

Aquesta és la trampa. Un client que rep l'opció 121 ha d'ignorar l'opció Router habitual, així que anunciar només la ruta del pool VPN pot deixar aquell equip sense cap ruta per defecte. La màquina encara sembla configurada i perd internet en silenci. Els usuaris ho descriuen com que la xarxa està caiguda mentre totes les interfícies estan actives.

Incloeu la ruta per defecte prevista a la mateixa llista, com fa el fragment anterior. Manteniu també l'opció Router habitual per als clients que no implementen rutes sense classe; el tractament propi d'opcions del servidor decideix què s'envia a cadascú.

Comproveu què acceptarà el client

Un equip amb adreça manual mai no ho recull, perquè no demana cap concessió. El suport dels clients també varia, així que proveu-ho al sistema operatiu que realment feu servir en lloc de suposar que cada dispositiu respecta l'opció 121. Confirmeu amb qui posseeix aquests servidors quins tenen adreça estàtica. Aquests equips necessiten les seves pròpies entrades de ruta o simplement no hi participaran.

Els serveis DHCP gestionats són un altre límit. Algunes xarxes de núvol no deixen que els administradors publiquin opcions arbitràries, i un servidor DHCP competidor al mateix segment és pitjor que no tenir cap opció.

Verifiqueu la concessió, després la consulta

Feu que el propietari del DHCP apliqui el canvi i després renoveu la concessió en un client. Les concessions existents mantenen la configuració antiga fins que es renoven, així que els resultats immediats no estan garantits.

En un client Linux, llegiu les rutes reals i confirmeu les dues entrades:

ip -4 route
ip -4 route get 10.90.0.23

La consulta contextual hauria de mostrar la ruta del pool a través de 192.168.50.2 i la per defecte a través de 192.168.50.1. Si falta la ruta per defecte, heu reproduït la trampa anterior.

Després proveu l'intercanvi real

La distribució de rutes no és tot el camí. La passarel·la separada encara necessita reenviament, propietat dels parells remots i una política d'accés que permeti el servidor, i DHCP no autentica ningú.

Finalment, tingueu un pla de retirada. Una ruta estàtica apresa no es retira sola quan la VPN cau, així que un següent salt obsolet pot convertir aquell prefix en un forat negre molt després que el túnel hagi desaparegut.