Un cliente VPN cun enderezo LAN non está na LAN

O cliente conéctase, recibe 10.50.0.200 e non pode chegar ao servidor en 10.50.0.20 aínda que ambos os números están na mesma /24. A crenza detrás desa configuración é que un enderezo do prefixo da LAN fai que o cliente forme parte da LAN. Non o fai. O cliente está nunha ligazón punto a punto, o servidor cre que o destino é local, e a peza que falta é unha resposta de veciño que ninguén envía.

O mito: o mesmo prefixo significa o mesmo segmento

Un prefixo de enderezo di a un equipo que destinos pode alcanzar directamente e cales necesitan un encamiñador. Non lle di como está conectado fisicamente o destino, e desde logo non garante que o destino poida responder a unha petición de capa de ligazón. Son preguntas distintas, ás que responden táboas distintas do equipo. A máscara responde á primeira e a táboa de veciños á segunda, e só a primeira está baixo o teu control desde o lado da VPN.

Cando o servidor envía a 10.50.0.200, compara o destino coa súa propia máscara, decide que o enderezo está on-link e pide ao segmento local o enderezo de hardware que o posúe. Esa petición sae pola interface Ethernet, e o cliente VPN non está alí para escoitala.

Nada na configuración do cliente pode arranxalo desde o seu lado. A ruta de resposta depende de que un dispositivo na LAN responda no nome do cliente, ou de que o cliente teña un enderezo que o servidor non considere local.

Que fai realmente o equipo local co enderezo

O comportamento é doado de observar e paga a pena observalo antes de cambiar nada. Mira a táboa de veciños nun equipo da LAN despois de que intente chegar ao cliente: unha entrada incompleta ou fallida é todo o diagnóstico nunha liña. Esa liña tamén che di que a avaría é local ao segmento e non nalgún punto dentro do túnel.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

A consulta de ruta informará o destino como on-link pola interface Ethernet, e ese é exactamente o problema. Se a entrada de veciño segue incompleta mentres a sesión VPN está activa, confirmaches que a peza que falta é a resolución na capa de ligazón e non o encamiñamento ou a política de cortalumes.

Fai a mesma comprobación desde un equipo noutra subrede e compara. Un equipo que chega ao cliente a través dun encamiñador non necesita ningunha entrada de veciño, e esa diferenza é a decisión de deseño en miniatura.

Como o proxy ARP fornece un seguinte salto

O proxy ARP fai que a pasarela responda á petición de capa de ligazón no nome dun destino ao que pode chegar por outra interface. O equipo da LAN recibe un enderezo de hardware, envía a trama á pasarela, e a pasarela reenvía o paquete á sesión VPN. Desde o punto de vista do equipo, o cliente simplemente parece estar detrás da pasarela. Nada da configuración do cliente cambia.

A documentación de ARP de RouterOS de MikroTik describe ese uso para clientes de acceso telefónico que toman prestado o espazo de enderezos da LAN conectada. O mecanismo é unha reparación da resolución de veciños, e funciona porque a pasarela está realmente nos dous camiños.

Iso non é o mesmo que poñer o cliente en ponte dentro da LAN. A pasarela aínda ten que reenviar o paquete á sesión activa correcta, e o seu encamiñamento e a súa política de cortalumes aínda teñen que permitir o servizo. O proxy ARP cambia quen responde á petición de veciño, non quen ten permiso para falar.

Le con coidado os nomes de modo da plataforma. RouterOS separa proxy-arp de local-proxy-arp, e o segundo xestiona o tráfico que entra e sae pola mesma interface. Non son grafías intercambiables, e activar ambos sen criterio non é un atallo.

O que o proxy ARP non che dá

Non fornece descubrimento por broadcast nin multicast. Un cliente que necesita atopar un servizo por broadcast seguirá fallando, porque a pasarela reenvía unicast á sesión e non converte o cliente en membro do dominio de broadcast da LAN. Os protocolos de descubrimento que dependen do broadcast son unha fonte habitual de informes de que funciona para unha cousa e non para outra en deseños con enderezos prestados.

Non reserva o enderezo. Se o número prestado tamén está nun grupo DHCP ou nunha asignación estática, dous dispositivos poden acabar co mesmo enderezo e o comportamento resultante depende do momento. Un inicio de sesión correcto non é unha reserva.

E non elimina a necesidade de coordinarse con quen é dono da LAN. Unha entrada de proxy ARP que sorprende o dono do plan de enderezos é un incidente de soporte agardando unha semana tranquila.

Comparación cun grupo encamiñado por separado

A alternativa é dar aos clientes VPN o seu propio prefixo e deixar que os equipos da LAN encamiñen cara a el. Entón o servidor envía respostas fóra de ligazón á súa pasarela, a pasarela encamiña o prefixo cara ao extremo da VPN, e non se necesita ningunha resolución de veciños no segmento da LAN. Iso son menos pezas móbiles que un enderezo prestado máis unha resposta proxy.

Ese deseño é máis doado de razoar e de auditar, porque o rango de clientes está visiblemente separado do rango da LAN. Custa unha ruta, un camiño de volta e unha regra de acceso, que son as mesmas cousas que o deseño con proxy ARP necesita nun lugar menos obvio.

Escolle entre os modelos a propósito e non por accidente. O proxy ARP repara unha relación concreta; un grupo encamiñado evita necesitar esa reparación. Anota cal escolliches e por que, e a seguinte persoa non terá que redescubrilo a partir dunha entrada de veciño fallida.