O teu pool de VPN non é o rango DHCP da LAN: por que falla

O atallo tentador é entregar aos clientes VPN direccións do mesmo rango que usa o servidor DHCP da oficina, coa teoría de que todo é unha soa rede. Non o é. Un túnel encamiñado transporta paquetes unicast entre dous extremos, mentres que o pool da LAN existe para responder solicitudes de difusión nun segmento físico. Reutilizar os números pon dous asignadores ao cargo dun mesmo espazo de direccións e deixa a ruta de retorno sen definir.

Dous asignadores, un espazo de direccións

O servidor DHCP da LAN sabe que direccións arrendou e a que dirección MAC, e deféndeas con ARP. O servidor VPN ten o seu propio pool e non sabe nada deses arrendamentos. Ningún dos dous se equivoca; sinxelamente nunca lles presentaron un ao outro.

Unha dirección do pool da LAN que o servidor VPN entrega pode pertencer xa a unha impresora. Agora dous dispositivos reclaman unha dirección no mesmo prefixo, e a táboa de reenvío do conmutador decide cal responde.

Ese é o fallo co que a xente se atopa primeiro: un cliente que se conecta con éxito e despois chega á máquina equivocada, ou chega á correcta de forma intermitente.

Por que o encamiñador non reparte direccións VPN

O descubrimento DHCP é unha difusión, e as difusións detéñense nun límite encamiñado. Salvo que o deseño ponte o túnel ou execute un relé DHCP coa autoridade correspondente, a solicitude do cliente nunca chega ao servidor da LAN.

Por iso o servidor VPN asigna a dirección el mesmo: un pool na configuración do servidor, unha dirección por par nunha instalación de WireGuard, ou unha dirección empurrada pola capa de autenticación nun despregamento de IKEv2. Eses mecanismos son independentes da base de datos de arrendamentos da LAN, e é exactamente por iso que necesitan un rango propio.

O mesmo razoamento explica por que cambiar o ámbito DHCP non arranxa un cliente VPN que nunca obtén unha dirección. O cliente non pregunta ao servidor da LAN, e ningunha edición do ámbito fará que pregunte.

O solapamento maniféstase como conflito, non como rede lenta

Dúas redes que comparten un prefixo sen un deseño admitido son un problema distinto da propiedade duplicada, e a miúdo confúndense. Se o pool VPN é un prefixo separado, o solapamento só importa cando unha ruta envía o tráfico ao lado equivocado. Se o pool está dentro do prefixo da LAN, o conflito é inmediato e local.

Na práctica ves respostas ARP do dispositivo equivocado, conexións que se reinician a metade de camiño e un cliente cuxa propia dirección reclama outro. Nada deso parece un problema de encamiñamento, por iso a corrección se aplica na capa equivocada. Un arrendamento duplicado é fácil de confirmar e molesto de soportar. Tamén sobrevive aos reinicios, porque ambos asignadores seguen insistindo na mesma dirección.

A ruta de retorno é un problema á parte

Incluso cun pool limpo e distinto, os equipos da LAN necesitan saber como responder a un cliente. A súa pasarela predeterminada é o encamiñador, e o encamiñador necesita unha ruta para o pool que apunte ao servidor VPN, salvo que o deseño traduza o tráfico do cliente.

Le a ruta en ambos sentidos antes de cambiar nada. Na pasarela, pregunta que interface usaría o núcleo para unha dirección de cliente; no cliente, pregunta que ruta usa para unha dirección da LAN.

Estes comandos mostran a decisión de reenvío na pasarela e as entradas de veciños que revelan un duplicado:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

Se o primeiro comando responde coa interface do túnel, a ruta de retorno existe. Se responde coa interface da LAN, o encamiñador cre que o cliente está no cable e intentará facer ARP por el.

Hai deseños con ponte, pero hai que escollelos

Pór unha ponte nun túnel cara á LAN é un deseño real, usado cando os clientes deben recibir difusións ou ser descubertos por protocolos que supoñen un só segmento. Esixe que o servidor sexa dono dese comportamento de ponte e do manexo de direccións que o acompaña.

O que non funciona é imitar o resultado copiando números. Un pool compartido sen ponte dálle o conflito sen o descubrimento, que é o peor de ambas as dúas disposicións.

Escolle a capa tres cun pool distinto salvo que a aplicación necesite de verdade o segmento, e documenta o pool para que o seguinte administrador non reutilice o rango DHCP por pura pulcritude.