Por que un host da LAN envía ARP para o enderezo dun cliente OpenVPN

Os problemas de alcance entre un host da LAN e un cliente VPN adoitan remontarse ao propio plan de enderezamento. Dállalle a ese host unha interface en 10.0.100.0/22 e tratará cada enderezo desde 10.0.100.0 ata 10.0.103.255 como directamente conectado, incluído un conxunto de clientes colocado discretamente en 10.0.101.0/24. A resposta nunca vai a un encamiñador, porque desde o punto de vista do host non intervé ningún encamiñador. O paquete diríxese a un veciño e reclámase no cable.

Ese mecanismo está detrás de toda unha familia de informes: o túnel está activo, o servidor ten unha ruta e o host da LAN segue sen acadar o cliente.

O /22 que traga o /24

Le o prefixo como un intervalo, non como unha cadea. Un /22 contén 1024 enderezos, e 10.0.100.0/22 abrangue de 10.0.100.0 a 10.0.103.255, así que un conxunto en 10.0.101.0/24 queda enteiramente dentro. O erro sobrevive á revisión porque os primeiros octetos do conxunto parecen distintos dos primeiros octetos da LAN, e só o terceiro octeto revela a contención. Escribe ambos os intervalos en cifras antes de declarares que son separados.

A mesma contención pode aparecer ao revés. Un conxunto que parece libre porque nada o usa agora pode caer igualmente dentro dun prefixo que anuncia algún encamiñador de sede, e o plan de enderezamento é o único documento que o mostra.

Ligazón directa significa ARP, non encamiñamento

Cando un host cunha interface /22 envía a 10.0.101.25, o núcleo compara o destino co prefixo da interface e atopa unha coincidencia. O paquete convértese nunha resolución de veciño en lugar dun paquete encamiñado, e en Ethernet a resolución de veciño é unha solicitude ARP para ese enderezo. Se o enderezo pertence a un cliente VPN detrás dunha pasarela encamiñada, ningún host da LAN o posúe, así que a solicitude queda sen resposta e os paquetes descártanse. O túnel non ten culpa, e o cliente nunca ve o tráfico.

Por iso a falla parece asimétrica e ás veces intermitente. O host VPN adoita acadar a LAN porque as súas propias rutas apuntan na dirección correcta, mentres que o host da LAN non pode responder, e calquera caché dunha entrada ARP obsoleta fai parpadear o síntoma.

TUN, TAP e o que transporta cada un

Un dispositivo TUN transporta paquetes IP, e un dispositivo TAP transporta tramas Ethernet. Unha ligazón TUN encamiñada non necesita transportar ARP para ofrecer alcance IP, e é exactamente por iso que a solicitude sen resposta de arriba é esperada e non un defecto. TAP cunha ponte deliberada pode ampliar o dominio de difusión e facer funcionar ARP, pero cambia o que o cliente pode ver, esixe extremos que admitan o mesmo encapsulado e é un redeseño do modelo de rede en lugar dunha reparación para un prefixo solapado. Pasar un despregamento encamiñado a TAP para curar un erro de plan de enderezamento cambia un problema pequeno por un máis grande.

Anota onde apareceu a solicitude ARP e que sistema a emitiu antes de sacar conclusións. O emisor diche o que cre sobre o destino, non o que fai o túnel.

Deseña un conxunto que non se poida solapar

Escolle un conxunto fóra de cada prefixo conectado e de cada prefixo de sede anunciado, e despois engade as rutas que o fan alcanzable nos dous sentidos. Un intervalo como 10.8.0.0/24 nunha parte non usada do plan é fácil de razoar, e unha LAN que precisa acadalo recibe unha ruta estática que apunta ao servidor VPN. Cambia á vez a asignación, as rutas anunciadas, os enderezos de orixe permitidos e as regras da devasa, porque describen un único deseño e non catro axustes.

O NAT de orixe no servidor pode agachar o conxunto detrás dun enderezo encamiñable desde a LAN, e é unha ferramenta de migración lexítima. Tamén reescribe a orixe, así que a LAN perde a capacidade de atribuír conexións a clientes individuais e de aplicar regras por cliente.

Para a aceptación, usa o enderezo realmente asignado ao cliente real e unha solicitude de aplicación real desde un host da LAN, e despois confirma que a resposta segue a pasarela prevista e non o cable.