Prefixo público pelo OpenVPN: corrigir o caminho de volta

Observe o túnel subir e o cliente fazer ping no outro lado, e então um endereço público que pertence atrás da VPN responde de outro lugar, ou não responde. Esse sintoma normalmente não tem nada a ver com a cifra ou com os certificados. Um prefixo roteado pelo provedor é entregue como uma rota IP, e carregá-lo pelo OpenVPN significa reproduzir essa rota em dois níveis e preservar o endereço de origem no caminho de volta. Não é preciso fazer bridge da WAN, e adicionar o endereço a uma interface não cria a rota ascendente.

O prefixo primeiro precisa ser roteado para você

Pergunte ao provedor como o bloco é entregue. Um prefixo roteado para o endereço principal do seu servidor é algo diferente de endereços que o provedor espera alcançar diretamente em um segmento WAN. Só o primeiro modelo funciona com o projeto daqui.

Se o provedor roteia 198.51.100.64/28 para o seu servidor de entrada, os pacotes dessa faixa chegam ao servidor e param ali, a menos que você os encaminhe. Se o provedor, em vez disso, faz bridge da faixa no seu uplink, o servidor precisa responder ARP por ela, o que é outro problema.

Teste o modelo de entrega antes de tocar no OpenVPN: de fora, faça ping em um endereço do bloco e veja qual interface o recebe. Se nada chegar, nenhuma configuração de túnel vai ajudar. Se o endereço responder diretamente na WAN, o provedor está fazendo bridge em vez de rotear, e o projeto abaixo não se aplica.

Dois níveis de roteamento: rota do kernel e iroute

O OpenVPN precisa do prefixo em dois lugares. O kernel precisa saber que o prefixo pertence ao dispositivo do túnel, para que os pacotes encaminhados entrem no OpenVPN em vez da rota padrão. O OpenVPN também precisa saber qual cliente autenticado possui o prefixo, que é a entrada iroute no diretório específico do cliente.

A rota do lado do servidor é assim, com o prefixo e a máscara correspondendo à alocação:

ip route add 198.51.100.64/28 dev tun0

A configuração específica do cliente atribui a propriedade. Coloque-a no arquivo CCD nomeado pelo nome comum do certificado do cliente, e confirme que esse diretório é o que o servidor realmente lê:

iroute 198.51.100.64 255.255.255.240

A documentação do OpenVPN sobre redes roteadas descreve os dois níveis e por que eles são separados. Uma rota do kernel sem iroute envia pacotes para o túnel sem proprietário, e o OpenVPN os descarta. Um iroute sem a rota do kernel deixa os pacotes no caminho padrão do servidor. Ambos os erros parecem um túnel quebrado do lado do cliente.

Onde mora o endereço do serviço

O prefixo delegado não é a mesma coisa que os endereços do próprio túnel. Numere o link a partir do espaço privado se quiser, e coloque o endereço público do serviço onde o serviço realmente roda.

Em um cliente Linux que termina o serviço localmente, um único endereço de host basta:

ip address add 198.51.100.70/32 dev lo

Se o prefixo for roteado adiante para um host VM ou outra LAN, configure em vez disso esse caminho a jusante e sua rota de volta. Atribuir cada endereço do bloco ao cliente VPN não é necessário e cria conflitos depois.

Mantenha a origem pública no caminho de volta

Uma resposta do prefixo delegado precisa sair pelo túnel e chegar à rota do provedor. Se o host remoto a enviar pelo próprio ISP, o endereço de origem parece falsificado, e o provedor ou o destino a descarta. A solução é uma regra baseada na origem ou uma tabela de roteamento dedicada, não um NAT mais amplo. Sem ela, o serviço funciona a partir do par do túnel e falha de qualquer outro lugar.

No servidor de entrada, uma regra de masquerade ampla é o culpado habitual. Ela reescreve a origem pública para o endereço principal do servidor, e o cliente nunca vê a real:

iptables -t nat -S POSTROUTING

Limite o NAT aos clientes VPN privados que precisam dele e deixe o prefixo delegado sem tradução. Depois confirme que o servidor encaminha o prefixo, porque uma cadeia de encaminhamento com negação padrão o descarta em silêncio.

Verifique as duas direções antes de confiar nele

A verificação são quatro observações, não uma. Confirme que a rota do provedor chega, que o kernel envia o prefixo para o túnel, que o OpenVPN o atribui ao cliente certo e que a resposta volta com a origem pública intacta. Cada observação tem seu próprio comando, então uma falha aponta para uma camada e não para todo o projeto. Execute-as nessa ordem depois de cada mudança de configuração.

Pergunte ao kernel qual caminho um endereço delegado toma, e observe o túnel enquanto uma requisição roda:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

A filtragem de caminho reverso pode desfazer uma rota correta. Verifique o ajuste efetivo no túnel e no uplink, e lembre-se de que o modo estrito rejeita tráfego cuja origem não corresponde à interface por onde ele chegou:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Por fim, teste o caso de falha. Pare o túnel e confirme que o prefixo público não vaza pelo uplink comum. Restaurar a VPN deve trazer o serviço de volta sem ampliar quais portas o host expõe.