El vostre pool de VPN no és el rang DHCP de la LAN: per què es trenca

La drecera temptadora és lliurar als clients VPN adreces del mateix rang que fa servir el servidor DHCP de l'oficina, amb la teoria que tot és una sola xarxa. No ho és. Un túnel encaminat transporta paquets unicast entre dos extrems, mentre que el pool de la LAN existeix per respondre sol·licituds de difusió en un segment físic. Reutilitzar els números posa dos assignadors al càrrec d'un sol espai d'adreces i deixa el camí de retorn indefinit.

Dos assignadors, un espai d'adreces

El servidor DHCP de la LAN sap quines adreces ha llogat i a quina adreça MAC, i les defensa amb ARP. El servidor VPN té el seu propi pool i no sap res d'aquests lloguers. Cap dels dos no s'equivoca; senzillament no se'ls ha presentat mai.

Una adreça del pool de la LAN que el servidor VPN assigna pot pertànyer ja a una impressora. Ara dos dispositius reclamen una adreça al mateix prefix, i la taula de reenviament del commutador decideix quin respon.

Aquesta és la fallada amb què la gent es troba primer: un client que es connecta correctament i després arriba a la màquina equivocada, o arriba a la correcta de manera intermitent.

Per què l'encaminador no lliura adreces VPN

El descobriment DHCP és una difusió, i les difusions s'aturen en una frontera encaminada. Si el disseny no pontifica el túnel o no executa un relé DHCP amb l'autoritat corresponent, la sol·licitud del client no arriba mai al servidor de la LAN.

Per tant, el servidor VPN assigna l'adreça ell mateix: un pool a la configuració del servidor, una adreça per parell en una instal·lació WireGuard, o una adreça empenyuda per la capa d'autenticació en un desplegament IKEv2. Aquests mecanismes són independents de la base de dades de lloguers de la LAN, i és exactament per això que necessiten un rang propi.

El mateix raonament explica per què canviar l'abast DHCP no arregla un client VPN que no obté mai una adreça. El client no pregunta al servidor de la LAN, i cap quantitat d'edició de l'abast no el farà preguntar.

La superposició es mostra com un conflicte, no com una xarxa lenta

Dues xarxes que comparteixen un prefix sense un disseny compatible són un problema diferent del doble propietari, i sovint es confonen. Si el pool de VPN és un prefix separat, la superposició només importa quan una ruta envia el trànsit al costat equivocat. Si el pool és dins del prefix de la LAN, el conflicte és immediat i local.

A la pràctica veieu respostes ARP del dispositiu equivocat, connexions que es reinicien a mig camí i un client l'adreça del qual reclama algú altre. Res d'això no sembla un problema d'encaminament, i per això la correcció s'aplica a la capa equivocada. Un lloguer duplicat és fàcil de confirmar i molest de suportar. També sobreviu als reinicis, perquè tots dos assignadors continuen insistint en la mateixa adreça.

El camí de retorn és un problema a part

Fins i tot amb un pool net i diferent, els amfitrions de la LAN han de saber com respondre a un client. La seva passarel·la per defecte és l'encaminador, i l'encaminador necessita una ruta per al pool que apunti al servidor VPN, tret que el disseny tradueixi el trànsit del client.

Llegiu el camí en tots dos sentits abans de canviar res. A la passarel·la, pregunteu quina interfície faria servir el nucli per a una adreça de client; al client, pregunteu quina ruta fa servir per a una adreça de la LAN.

Aquestes ordres mostren la decisió de reenviament a la passarel·la i les entrades de veïnatge que revelen un duplicat:

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

Si la primera ordre respon amb la interfície del túnel, la ruta de retorn existeix. Si respon amb la interfície de la LAN, l'encaminador creu que el client és al cable i intentarà fer ARP per a ell.

Els dissenys pontificats existeixen, però cal triar-los

Pontificar un túnel cap a la LAN és un disseny real, utilitzat quan els clients han de rebre difusions o han de ser descoberts per protocols que pressuposen un sol segment. Requereix que el servidor posseeixi aquest comportament de pont i la gestió d'adreces que hi va lligada.

El que no funciona és imitar el resultat copiant números. Un pool compartit sense pont us dona el conflicte sense el descobriment, que és el pitjor de les dues disposicions.

Trieu la capa tres amb un pool diferent tret que l'aplicació necessiti realment el segment, i documenteu el pool perquè el proper administrador no reutilitzi el rang DHCP per pura pulcritud.