Enderezo VPN fronte á concesión DHCP da LAN: quen asigna o IP do túnel?

O seu cliente VPN mostra un enderezo que nunca aparece nun ficheiro de concesións da LAN. Lea o cliente, a carga de IKEv2 e o grupo da pasarela para atopar o asignador real.

Conecte o cliente e mire o adaptador en lugar da icona de Wi-Fi. Un enderezo como 10.80.0.14 pode estar nun túnel aínda que ningún servidor DHCP da LAN da oficina rexistrase nunca esa concesión. O proceso que escolleu o número decide onde comeza o diagnóstico.

No cliente todo parece igual: un enderezo IPv4, unha máscara, ás veces unha pasarela predeterminada. A diferenza só aparece cando pregunta quen responde por ese enderezo e quen garda un rexistro del.

Lea o enderezo do túnel desde o lado do cliente

Windows mostra a distinción se le todo o bloque e non a primeira liña. ipconfig /all imprime unha descrición do adaptador, un enderezo físico e unha liña DHCP. Un adaptador de marcación PPP ou IKEv2 adoita informar DHCP como desactivado, porque a conexión negociou o seu enderezo durante a marcación en lugar de tomalo dun servidor da LAN. Un adaptador de túnel con DHCP activado é pouco habitual e merece unha investigación á parte.

Linux reparte a mesma información entre dúas ferramentas. ip -4 addr show dev tun0 dá o enderezo e a lonxitude do prefixo. nmcli -f IP4 connection show work revela se o valor veu do perfil de conexión, dun intercambio DHCP na ligazón ou dunha configuración empurrada. WireGuard é o caso máis claro, porque wg-quick aplica a liña Address do ficheiro de configuración cando aparece a interface e ningún par asigna nada ao conectarse.

O prefixo tamén di algo. Un /32, ou unha máscara de 255.255.255.255, significa que a pasarela espera encamiñar a un só enderezo de host, mentres que unha máscara máis ampla suxire unha subrede na ligazón nalgún lugar detrás do túnel.

Que transporta a carga de configuración de IKEv2

IKEv2 ten un mecanismo dedicado a esta tarefa. A carga de configuración descrita en RFC 7296, sección 3.15.1 transporta atributos como INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS e os seus equivalentes IPv6. O cliente envía un atributo de lonxitude cero cando non ten preferencia, e o respondedor devolve o valor que quere que se use. Ese intercambio viaxa dentro de IKE_AUTH, xa cifrado, así que ningunha difusión DHCP cruza nunca o túnel.

Séguense dúas consecuencias. Primeira, o enderezo escolleuno o respondedor ou calquera backend de autorización que consulte, e por iso un grupo pode vivir na pasarela, nunha resposta RADIUS ou nunha asignación do provedor de identidade. Segunda, o atributo DNS está separado do atributo de enderezo. Recibir 10.80.0.14 non di nada sobre que resolución volveu, nin se volveu algunha.

O atributo de máscara de rede é opcional na práctica. Moitos despregamentos devolven só un enderezo e deixan que o cliente instale unha ruta de host, e por iso o mesmo grupo pode parecer un /32 nun cliente e un /24 noutro.

Onde chocan un ámbito DHCP da LAN e un grupo de VPN

O problema comeza cando ambos asignadores apuntan ao mesmo rango. Un servidor DHCP para 10.20.30.0/24 non sabe nada dun grupo de VPN configurado para 10.20.30.128/25, así que nada lle impide conceder 10.20.30.140 a unha impresora mentres a pasarela entrega o mesmo enderezo a un cliente remoto. O choque permanece silencioso durante días e logo aparece como un duplicado intermitente.

Un deseño encamiñado de sitio a sitio evita o choque por construción. Un host na sucursal conserva o enderezo que lle deu o seu servidor DHCP local. As interfaces de túnel das dúas pasarelas levan os seus propios enderezos de ligazón, e a táboa de rutas decide como viaxan os paquetes. Os enderezos dos clientes de acceso remoto son unha terceira categoría e non deben mesturarse cos enderezos de ligazón da pasarela.

Pontear o túnel cara á LAN elimina esa separación. Se o deseño necesita de verdade un só dominio de difusión, o extremo da VPN ten que participar nas mesmas decisións de asignación que o servidor DHCP, mediante un relé ou unha fonte autoritativa compartida, en lugar de emitir enderezos pola súa conta.

Verifique que proceso posúe o enderezo

Demostre a propiedade antes de cambiar un ámbito. No cliente, anote o enderezo e o prefixo. Na LAN, busque na base de datos de concesións. Na pasarela, liste os grupos que está configurada para repartir. Un enderezo atopado no ficheiro de concesións pertence a un servidor DHCP, o que significa que o túnel está ponteado ou relayado; un enderezo atopado só no grupo da pasarela pertence ao extremo do 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

Anote catro cousas cando a resposta estea clara: que compoñente asigna o enderezo do cliente, que rango está reservado para el, como chega o tráfico de volta a ese rango e que recursos o aceptan. Esas catro entradas converten unha liña de adaptador virtual nun feito operativo.

Repita a comprobación do atributo DNS mentres está alí. Un grupo que reparte enderezos pero ningún resolutor deixa o cliente no seu DNS local, o que é un fallo distinto dun grupo que reparte un enderezo que a LAN xa usa.

Artigos relacionados