Un client VPN amb adreça LAN no és a la LAN

El client es connecta, rep 10.50.0.200 i no pot arribar al servidor a 10.50.0.20 tot i que tots dos números són a la mateixa /24. La creença darrere d’aquesta configuració és que una adreça del prefix de la LAN fa que el client formi part de la LAN. No ho fa. El client és en un enllaç punt a punt, el servidor creu que la destinació és local, i la peça que falta és una resposta de veí que ningú no envia.

El mite: mateix prefix vol dir mateix segment

Un prefix d’adreça diu a un amfitrió quines destinacions pot assolir directament i quines necessiten un encaminador. No diu a l’amfitrió com està connectada físicament la destinació, i de cap manera no garanteix que la destinació pugui respondre una petició de capa d’enllaç. Són preguntes diferents, respostes per taules diferents a l’amfitrió. La màscara respon la primera i la taula de veïns la segona, i només la primera és sota el vostre control des del costat de la VPN.

Quan el servidor envia a 10.50.0.200, compara la destinació amb la seva pròpia màscara, decideix que l’adreça és on-link i demana al segment local l’adreça de maquinari que la posseeix. Aquesta petició surt per la interfície Ethernet, i el client VPN no és allà per sentir-la.

Res a la configuració del client no pot arreglar-ho des del seu costat. El camí de resposta depèn que un dispositiu a la LAN respongui en nom del client, o que el client tingui una adreça que el servidor no consideri local.

Què fa realment l’amfitrió local amb l’adreça

El comportament és fàcil d’observar i val la pena observar-lo abans de canviar res. Mireu la taula de veïns en un amfitrió de la LAN després que intenti arribar al client: una entrada incompleta o fallida és tot el diagnòstic en una línia. Aquesta línia també us diu que la fallada és local al segment i no en algun lloc dins del 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

La consulta de ruta informarà la destinació com a on-link per la interfície Ethernet, i això és exactament el problema. Si l’entrada de veí continua incompleta mentre la sessió VPN és activa, heu confirmat que la peça que falta és la resolució de capa d’enllaç i no l’encaminament o la política de tallafocs.

Feu la mateixa comprovació des d’un amfitrió en una altra subxarxa i compareu. Un amfitrió que arriba al client a través d’un encaminador no necessita cap entrada de veí, i aquesta diferència és la decisió de disseny en miniatura.

Com el proxy ARP proporciona un següent salt

El proxy ARP fa que la passarel·la respongui la petició de capa d’enllaç en nom d’una destinació a la qual pot arribar per una altra interfície. L’amfitrió de la LAN rep una adreça de maquinari, envia la trama a la passarel·la, i la passarel·la reenvia el paquet a la sessió VPN. Des del punt de vista de l’amfitrió, el client simplement sembla que és darrere de la passarel·la. Res de la configuració del client no canvia.

La documentació d’ARP de RouterOS de MikroTik descriu aquest ús per a clients de connexió telefònica que manlleven l’espai d’adreces de la LAN connectada. El mecanisme és una reparació de la resolució de veïns, i funciona perquè la passarel·la és realment als dos camins.

Això no és el mateix que pontar el client dins de la LAN. La passarel·la encara ha de reenviar el paquet a la sessió activa correcta, i la seva política d’encaminament i de tallafocs encara ha de permetre el servei. El proxy ARP canvia qui respon la petició de veí, no qui pot parlar.

Llegiu amb cura els noms de mode de la plataforma. RouterOS separa proxy-arp de local-proxy-arp, i el segon gestiona el trànsit que entra i surt per la mateixa interfície. No són escriptures intercanviables, i activar tots dos sense criteri no és cap drecera.

Què no us dóna el proxy ARP

No proporciona descobriment per broadcast ni multicast. Un client que necessita trobar un servei per broadcast encara fallarà, perquè la passarel·la reenvia unicast a la sessió i no fa que el client sigui membre del domini de broadcast de la LAN. Els protocols de descobriment que depenen del broadcast són una font habitual d’informes que diuen que funciona per a una cosa i no per a una altra en dissenys d’adreces manllevades.

No reserva l’adreça. Si el número manllevat també és en un pool DHCP o en una assignació estàtica, dos dispositius poden acabar amb la mateixa adreça i el comportament resultant depèn del moment. Un inici de sessió correcte no és una reserva.

I no elimina la necessitat de coordinar-se amb qui posseeix la LAN. Una entrada de proxy ARP que sorprèn el propietari del pla d’adreces és un incident de suport esperant una setmana tranquil·la.

Compareu amb un pool encaminat a part

L’alternativa és donar als clients VPN el seu propi prefix i deixar que els amfitrions de la LAN hi encaminin. Llavors el servidor envia respostes fora d’enllaç a la seva passarel·la, la passarel·la encamina el prefix cap al punt final de la VPN, i no cal cap resolució de veïns al segment de la LAN. Això és menys peces mòbils que una adreça manllevada més una resposta proxy.

Aquest disseny és més fàcil de raonar i d’auditar, perquè el rang de clients és visiblement separat del rang de la LAN. Costa una ruta, un camí de tornada i una regla d’accés, que són les mateixes coses que el disseny de proxy ARP necessita en un lloc menys evident.

Trieu entre els models deliberadament i no per accident. El proxy ARP repara una relació concreta; un pool encaminat evita necessitar aquesta reparació. Anoteu quin heu triat i per què, i la propera persona no haurà de redescobrir-ho a partir d’una entrada de veí fallida.