Por que um host da LAN envia ARP para o endereço de um cliente OpenVPN

Problemas de alcance entre um host da LAN e um cliente VPN costumam remontar ao próprio plano de endereçamento. Dê a esse host uma interface em 10.0.100.0/22 e ele tratará cada endereço de 10.0.100.0 a 10.0.103.255 como diretamente conectado, incluindo um pool de clientes colocado discretamente em 10.0.101.0/24. A resposta nunca vai para um roteador, porque do ponto de vista do host nenhum roteador está envolvido. O pacote é endereçado a um vizinho e solicitado no cabo.

Esse mecanismo está por trás de toda uma família de relatos: o túnel está ativo, o servidor tem uma rota e o host da LAN continua sem alcançar o cliente.

O /22 que engole o /24

Leia o prefixo como um intervalo, não como uma string. Um /22 contém 1024 endereços, e 10.0.100.0/22 abrange de 10.0.100.0 a 10.0.103.255, então um pool em 10.0.101.0/24 fica inteiramente dentro dele. O erro sobrevive à revisão porque os primeiros octetos do pool parecem diferentes dos primeiros octetos da LAN, e somente o terceiro octeto revela a contenção. Escreva os dois intervalos em números antes de declará-los separados.

A mesma contenção pode aparecer ao contrário. Um pool que parece livre porque nada o usa no momento pode ainda cair dentro de um prefixo anunciado por algum roteador de site, e o plano de endereçamento é o único documento que mostra isso.

Ligação direta significa ARP, não roteamento

Quando um host com uma interface /22 envia para 10.0.101.25, o kernel compara o destino com o prefixo da interface e encontra uma correspondência. O pacote torna-se uma resolução de vizinho em vez de um pacote roteado, e no Ethernet a resolução de vizinho é uma solicitação ARP para esse endereço. Se o endereço pertence a um cliente VPN atrás de um gateway roteado, nenhum host da LAN o possui, então a solicitação fica sem resposta e os pacotes são descartados. O túnel não tem culpa, e o cliente nunca vê o tráfego.

Por isso a falha parece assimétrica e às vezes intermitente. O host VPN costuma alcançar a LAN porque suas próprias rotas apontam no sentido certo, enquanto o host da LAN não consegue responder, e qualquer cache de entrada ARP obsoleta faz o sintoma piscar.

TUN, TAP e o que cada um transporta

Um dispositivo TUN transporta pacotes IP, e um dispositivo TAP transporta quadros Ethernet. Um link TUN roteado não precisa transportar ARP para entregar alcance IP, e é exatamente por isso que a solicitação sem resposta acima é esperada e não um defeito. TAP com uma ponte deliberada pode estender o domínio de broadcast e fazer o ARP funcionar, mas muda o que o cliente pode ver, exige extremidades que suportem o mesmo enquadramento e é um redesenho do modelo de rede em vez de um reparo para um prefixo sobreposto. Mudar uma implantação roteada para TAP a fim de curar um erro de plano de endereçamento troca um problema pequeno por um maior.

Anote onde a solicitação ARP apareceu e qual sistema a emitiu antes de tirar conclusões. O emissor diz o que acredita sobre o destino, não o que o túnel faz.

Projete um pool que não possa se sobrepor

Escolha um pool fora de cada prefixo conectado e de cada prefixo de site anunciado, e depois acrescente as rotas que o tornam alcançável nos dois sentidos. Um intervalo como 10.8.0.0/24 numa parte não usada do plano é fácil de raciocinar, e uma LAN que precisa alcançá-lo recebe uma rota estática apontando para o servidor VPN. Altere em conjunto a alocação, as rotas anunciadas, os endereços de origem permitidos e as regras de firewall, porque descrevem um único projeto e não quatro ajustes.

O NAT de origem no servidor pode esconder o pool atrás de um endereço roteável pela LAN, e é uma ferramenta de migração legítima. Ele também reescreve a origem, então a LAN perde a capacidade de atribuir conexões a clientes individuais e de aplicar regras por cliente.

Para a aceitação, use o endereço realmente atribuído ao cliente real e uma solicitação de aplicação real a partir de um host da LAN, e então confirme que a resposta segue o gateway planejado e não o cabo.