OpenVPN iroute versus rota do kernel: qual está faltando?

Um pacote para 10.77.20.0/24 toma duas decisões separadas num servidor OpenVPN: o sistema operacional precisa entregá-lo à interface VPN, e o OpenVPN precisa saber qual cliente conectado possui esse prefixo. Uma rota do kernel ausente o descarta antes do túnel, e uma rota do peer ausente o descarta depois. As duas falhas parecem idênticas a partir da LAN remota, e diagnosticar qual você tem exige um comando em cada lado.

No caminho de dados clássico em espaço de usuário, a rota do kernel leva o pacote ao processo do túnel e o iroute diz a esse processo qual peer deve recebê-lo. Nenhuma substitui a outra, e uma configuração que traga só uma delas parecerá razoável até o primeiro ping.

Duas decisões, não uma rota

Imagine um link entre sites em que 10.77.20.0/24 fica atrás de um único cliente. A rota do kernel do servidor, por exemplo ip route add 10.77.20.0/24 dev tun0, envia os pacotes correspondentes ao dispositivo do túnel. Depois o OpenVPN consulta sua própria tabela interna, construída a partir das entradas iroute no diretório de configuração do cliente, para decidir qual conexão de peer os recebe. Sem a rota do kernel o pacote nunca chega ao processo, e sem a rota do peer chega ao processo e não vai a lugar nenhum.

Essa divisão é fácil de esquecer, porque uma única linha de rota num perfil de cliente pode parecer que faz as duas tarefas. Não faz: empurrar uma rota diz aos clientes o que enviar pelo túnel, enquanto o iroute diz ao servidor quem possui uma faixa de endereços atrás de um cliente. Elas vivem em arquivos diferentes, são lidas por lados diferentes e falham em direções opostas.

Onde fica o iroute e o que ele diz

A entrada vai num arquivo por cliente nomeado segundo o common_name do cliente, dentro de client-config-dir, como iroute 10.77.20.0/24. A correspondência do nome do arquivo não é cosmética: o OpenVPN procura a identidade autenticada e lê o arquivo com exatamente esse nome, então um arquivo chamado site-a só vale para um cliente cujo nome comum seja site-a. Adicione ccd-exclusive se clientes sem esse arquivo devem ser recusados de imediato, que é o ajuste correto quando cada cliente é um gateway de site. Mantenha um arquivo por gateway e nomeie-o segundo o assunto do certificado que você realmente emite.

Teste a entrada a partir do servidor antes de culpar a LAN remota. O arquivo de status lista os clientes conectados com seus nomes comuns, e um servidor executado com --verb 4 registra a instalação do iroute no momento em que o peer se conecta. Se nada aparecer na conexão, o arquivo está no diretório errado ou nomeia a identidade errada.

A armadilha: arquivo presente, identidade errada

Um iroute de aparência correta preso ao peer errado desperdiça mais tempo do que um arquivo ausente, porque tudo no disco parece certo. A renomeação de certificados, nomes comuns duplicados e o username-as-common-name mudando a identidade efetiva produzem tudo isso. Verifique qual identidade o servidor autenticou em vez da que você esperava: a saída de status é autoritativa, enquanto o nome do arquivo é apenas uma chave de busca.

Uma rota também pode sobreviver ao seu dono. Rotas estáticas e entradas iroute descrevem um prefixo, não uma garantia de disponibilidade, então o tráfego pode continuar sendo encaminhado para um peer que está desconectado neste momento.

Conclua o caminho além do peer

A posse do peer é o meio do caminho, não o fim. O cliente precisa encaminhar pacotes do túnel para sua própria LAN, o que significa encaminhamento de IP ativado naquele host e uma regra de firewall permitindo a passagem. Os hosts da LAN remota precisam de um caminho de volta para o endereço do túnel: ou uma rota apontando de volta para o gateway, ou um desenho de NAT deliberado no lado do cliente. Confirme o ajuste de encaminhamento no cliente com sysctl net.ipv4.ip_forward em vez de supor um padrão da distribuição.

Se outros clientes VPN precisam alcançar essa sub-rede, o arranjo cresce de novo: o servidor precisa de client-to-client, e esses clientes precisam encaminhar o prefixo pelo túnel. Nada disso é implícito na própria tabela de rotas do servidor.

Verifique um destino a partir de uma origem real em vez do próprio servidor. Um ping de um host LAN não relacionado para um host atrás do cliente exercita o caminho de volta, a regra de encaminhamento e a posse do peer num único movimento, enquanto um handshake bem-sucedido prova apenas a identidade. Depois desconecte o peer proprietário e anote o que a rota faz, porque essa resposta é o seu modo de falha.