Adreça VPN o concessió DHCP de la LAN: qui assigna la IP del túnel?

Connecta el client i mira l'adaptador en lloc de la icona del Wi-Fi. Una adreça com 10.80.0.14 pot seure en un túnel mentre cap servidor DHCP de la LAN de l'oficina no ha registrat mai aquella concessió. El procés que va triar el número decideix on comença la diagnosi.

Al client tot sembla igual: una adreça IPv4, una màscara, de vegades una passarel·la per defecte. La diferència només apareix quan preguntes qui respon per aquella adreça i qui en guarda un registre.

Llegeix l'adreça del túnel des del costat del client

Windows mostra la distinció si llegeixes tot el bloc i no la primera línia. ipconfig /all imprimeix una descripció de l'adaptador, una adreça física i una línia DHCP. Un adaptador de marcatge PPP o IKEv2 normalment informa que el DHCP està desactivat, perquè la connexió va negociar la seva adreça durant el marcatge en lloc d'obtenir-la d'un servidor de la LAN. Un adaptador de túnel amb DHCP activat és inusual i val la pena investigar-lo per si mateix.

Linux reparteix la mateixa informació entre dues eines. ip -4 addr show dev tun0 dona l'adreça i la longitud del prefix. nmcli -f IP4 connection show work revela si el valor va venir del perfil de connexió, d'un intercanvi DHCP a l'enllaç o d'una configuració empenyuda. WireGuard és el cas més clar, perquè wg-quick aplica la línia Address del fitxer de configuració quan apareix la interfície i cap parell no assigna res en connectar.

El prefix també diu alguna cosa. Un /32, o una màscara de 255.255.255.255, vol dir que la passarel·la espera encaminar cap a una sola adreça d'amfitrió, mentre que una màscara més ampla suggereix una subxarxa a l'enllaç en algun lloc darrere del túnel.

Què porta la càrrega de configuració d'IKEv2

IKEv2 té un mecanisme dedicat a aquesta feina. La càrrega de configuració descrita a RFC 7296, secció 3.15.1 porta atributs com INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS i els seus homòlegs IPv6. El client envia un atribut amb un valor de longitud zero quan no té preferència, i el responedor retorna el valor que vol que s'utilitzi. Aquest intercanvi viatja dins d'IKE_AUTH, ja xifrat, així que cap difusió DHCP travessa mai el túnel.

Se'n deriven dues conseqüències. Primera, l'adreça la tria el responedor o qualsevol backend d'autorització que consulti, i per això un pool pot viure a la passarel·la, en una resposta RADIUS o en un mapatge del proveïdor d'identitat. Segona, l'atribut DNS és separat de l'atribut d'adreça. Rebre 10.80.0.14 no diu res sobre quin resolutor va tornar, ni si en va tornar cap.

L'atribut de màscara de xarxa és opcional a la pràctica. Molts desplegaments només retornen una adreça i deixen que el client instal·li una ruta d'amfitrió, i per això el mateix pool pot semblar un /32 en un client i un /24 en un altre.

On xoquen un abast DHCP de la LAN i un pool VPN

El problema comença quan tots dos assignadors apunten al mateix rang. Un servidor DHCP per a 10.20.30.0/24 no sap res d'un pool VPN configurat per a 10.20.30.128/25, així que res no li impedeix concedir 10.20.30.140 a una impressora mentre la passarel·la dona la mateixa adreça a un client remot. El xoc resta silenciós durant dies i després apareix com un duplicat intermitent.

Un disseny encaminat de lloc a lloc evita el xoc per construcció. Un amfitrió a la sucursal conserva l'adreça que li va donar el seu servidor DHCP local. Les interfícies de túnel de les dues passarel·les porten les seves pròpies adreces d'enllaç, i la taula d'encaminament decideix com viatgen els paquets. Les adreces dels clients d'accés remot són una tercera categoria i no s'han de barrejar amb les adreces d'enllaç de la passarel·la.

Pontar el túnel a la LAN elimina aquesta separació. Si el disseny necessita de debò un sol domini de difusió, el punt final de la VPN ha de participar en les mateixes decisions d'assignació que el servidor DHCP, mitjançant un relé o una font autoritativa compartida, en lloc d'emetre adreces pel seu compte.

Verifica quin procés posseeix l'adreça

Demostra la propietat abans de canviar un abast. Al client, captura l'adreça i el prefix. A la LAN, cerca a la base de dades de concessions. A la passarel·la, llista els pools que està configurada per repartir. Una adreça trobada al fitxer de concessions pertany a un servidor DHCP, cosa que vol dir que el túnel està pontat o relayat; una adreça trobada només al pool de la passarel·la pertany al punt final del túnel.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

Anota quatre coses quan la resposta sigui clara: quin component assigna l'adreça del client, quin rang hi està reservat, com arriba el trànsit de tornada a aquest rang i quins recursos l'accepten. Aquestes quatre entrades converteixen una línia d'adaptador virtual en un fet operatiu.

Repeteix la comprovació de l'atribut DNS mentre hi ets. Un pool que reparteix adreces però cap resolutor deixa el client al seu DNS local, cosa que és una fallada diferent d'un pool que reparteix una adreça que la LAN ja utilitza.