Porque é que a sub-rede atrás de um cliente OpenVPN está inacessível?

Os pings ao endereço do túnel do servidor são bem-sucedidos, a tabela de rotas do próprio cliente parece correta, e a LAN atrás desse cliente continua inacessível. A tabela de encaminhamento do cliente parece correta, o servidor tem uma rota que aponta para o túnel, e os pacotes continuam a desaparecer. É o sintoma clássico de um túnel layer-3 que não sabe que um dos seus clientes também é uma gateway.

Uma interface tun não tem próximo salto por cliente. O kernel vê uma única interface com muitos pares, por isso a decisão sobre qual cliente deve receber um pacote para uma LAN remota tem de ser tomada dentro do processo OpenVPN. Essa decisão é configurada com iroute, e sem ela o pacote não tem para onde ir.

O servidor encaminha por cliente, não por interface

Quando o servidor precisa de enviar um pacote para o endereço do túnel de um cliente, a resposta é inequívoca: o endereço pertence à sessão desse cliente. Quando o destino é toda uma sub-rede atrás desse cliente, o endereço não pertence a ninguém que o servidor conheça, e a rota do kernel para o túnel apenas diz "por esta interface", sem indicar qual par.

OpenVPN resolve isto com uma tabela de rotas interna que associa um prefixo de destino a um cliente específico. Essa tabela é construída a partir de entradas iroute, e é por isso que uma rota normal no anfitrião do servidor não chega. A rota do kernel leva o pacote à interface do túnel; a associação interna decide qual sessão o recebe. É também por isso que a reparação nunca aparece na saída de rotas do kernel.

Se a associação faltar, o pacote chega ao servidor, corresponde à rota do túnel e é descartado porque nenhum cliente reclama o destino. Nada registra um erro limpo, e por isso a falha parece um buraco negro silencioso em vez de um ciclo de encaminhamento.

Escrever a entrada iroute que nomeia o cliente

O iroute vive num ficheiro de configuração específico do cliente, não na configuração principal do servidor. Aponte o servidor para um diretório com a opção client-config-dir, depois crie um ficheiro cujo nome seja o nome comum do certificado do cliente e coloque lá o prefixo.

Para uma filial cuja LAN é 10.20.0.0/24 e cujo nome comum do certificado é branch-router, o ficheiro nesse caminho contém uma linha como iroute 10.20.0.0 255.255.255.0. A configuração principal só precisa da opção do diretório; o prefixo vive com o cliente.

O nome comum é a parte frágil. Um certificado emitido com outro subject, ou uma instalação que autentica utilizadores por nome de utilizador enquanto o ficheiro tem o nome do certificado, produz um ficheiro que nunca é lido. Verifique o nome que o servidor relata realmente para a sessão, e considere a opção que faz falhar um cliente não correspondente em vez de o ligar em silêncio sem as suas rotas. Renomear o ficheiro para corresponder ao certificado é uma correção de cinco minutos que evita uma noite muito longa.

Um cliente pode ter vários prefixos. Adicione uma linha iroute por rede e mantenha a lista ao lado das restantes definições desse cliente para que a associação continue auditável.

Construir o caminho de retorno nos dois sentidos

Levar os pacotes à LAN remota é metade do trabalho. O cliente também tem de enviar o tráfego dessa LAN para o túnel, o que normalmente se faz empurrando uma rota para o cliente: uma linha como push "route 10.8.0.0 255.255.255.0" diz a cada cliente como alcançar a rede do lado do servidor. Para a filial, a rota equivalente aponta para o túnel para tudo o que tenha de alcançar do lado do servidor.

O sentido de retorno precisa de um dono do lado remoto. Desse lado, alguém tem de conhecer o caminho de volta: uma rota estática no router da LAN que aponte o pool de VPN para o servidor, ou tradução de endereços no servidor antes de o tráfego entrar na LAN. A rota estática mantém os endereços originais visíveis nos registos e nas regras de acesso, mas exige a cooperação do dono da LAN; a tradução é autónoma, mas esconde quem se ligou realmente.

O encaminhamento tem de estar ativo no anfitrião do servidor. Sem isso o kernel aceita o pacote do túnel e recusa passá-lo à interface da LAN, o que do ponto de vista do cliente parece exatamente igual a uma iroute em falta.

Verificar o acesso com as sondas certas

Teste por camadas em vez de fazer ping ao extremo remoto e adivinhar. Do servidor, verifique que a associação interna do prefixo existe e que a rota do kernel aponta para o túnel. Do cliente, confirme que a rota empurrada está instalada e que o seu caminho predefinido para o endereço da LAN é o túnel.

Depois observe os pacotes. Uma captura na interface do túnel mostra se o servidor transmite para o cliente, e uma captura na interface da LAN mostra se encaminha. Se a primeira mostra pacotes e a segunda não, o problema é o encaminhamento ou um filtro; se nenhuma mostra nada, a procura falhou mais cedo.

Dois servidores ligados por um túnel repetem a mesma regra dos dois lados: cada um precisa de uma iroute para o pool do outro, e cada um precisa da rota e do encaminhamento que tornam o caminho simétrico. Encaminhamento e política são assuntos separados aqui. O encaminhamento decide para onde um pacote pode ir, enquanto uma regra FORWARD decide se pode, por isso um cliente com duas linhas iroute alcança os dois prefixos, a menos que um filtro diga o contrário.