Dois túneis OpenVPN num só host Linux: de quem é a rota?

Dois perfis ligados, e um deles transporta em silêncio tráfego destinado ao outro. Um host Linux consegue executar ambos os clientes OpenVPN ao mesmo tempo sem dificuldade. O que não consegue é decidir por si que processo pode reivindicar que prefixo. Essa decisão tem de ser tomada antes de o segundo túnel subir, não depois de um recurso deixar de responder.

Comece pelo trabalho que a segunda ligação tem de fazer

Um escritório acessível por um perfil e um laboratório acessível por outro precisam dos dois túneis ativos e de nenhum deles a reivindicar tudo. Uma única aplicação teimosa que tem de sair pelo segundo perfil precisa de uma regra de política e não de uma segunda rota predefinida. Uma ligação de reserva só precisa de um túnel a funcionar de cada vez, por isso a reserva não deve arrancar com a máquina.

São três configurações diferentes, e confundem-se porque todas começam da mesma forma: um segundo perfil e uma ligação bem-sucedida. Escreva primeiro a disposição pretendida e depois configure nesse sentido. Uma frase de intenção poupa uma hora de capturas de pacotes.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

O primeiro comando lista as instâncias em execução, incluindo as iniciadas à mão fora do gestor. O segundo imprime a reivindicação de rota predefinida atual, que é o estado que terá de explicar mais tarde.

Os pools sobrepostos quebram antes do encaminhamento

Dois servidores atribuem alegremente endereços do mesmo 10.8.0.0/24. O cliente fica então com duas interfaces dentro de um prefixo, sem nada que diga que destino pertence a qual, e o comportamento resultante parece uma falha de encaminhamento mas é na realidade uma falha de numeração. Renumerar um pool custa uma edição de configuração; cada solução de encaminhamento posterior custa um fim de semana. Verifique o pool antes de lhe acrescentar uma rota.

Veja também a LAN local. Uma LAN doméstica numerada 192.168.1.0/24 que um túnel também expõe produz a mesma ambiguidade, e o sintoma é um nome de anfitrião que resolve enquanto a ligação nunca se conclui. Isso parece uma falha de resolução de nomes até imprimir as rotas.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Compare as duas saídas com as duas configurações de servidor antes de tocar no cliente. Se os prefixos se sobrepuserem, pare e renumere, porque nenhuma quantidade de reinícios os separará.

Dê a cada perfil a sua própria unidade e a cada prefixo um dono

Cada perfil tem o seu próprio nome de instância e o seu próprio ficheiro de configuração, por isso a instância chamada office carrega office.conf enquanto a chamada lab carrega lab.conf. Confirme esse mapeamento através do gestor de serviços em vez de confiar numa listagem de diretório, porque um drop-in pode mudar que ficheiro é carregado. Errar o mapeamento significa que está a afinar o perfil que não está a correr.

Depois decida quem instala as rotas. Quando os servidores empurram conjuntos incompatíveis, ou recusa o empurrão e lista os prefixos você mesmo, ou deixa um perfil ficar com a predefinida e encaminha o outro com regras de política. Dois processos que ambos instalam uma predefinida acabam com um vencedor silencioso e sem registo escrito da decisão.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

O primeiro mostra a unidade com qualquer substituição que altere os seus argumentos. O segundo mostra se o perfil aceita de todo as rotas empurradas, e é o interruptor que decide tudo o resto.

As marcas mantêm as respostas na interface de onde chegaram

Quando cada túnel serve fontes diferentes, uma resposta pode sair pela ligação errada e a ligação morre após o primeiro pacote. O padrão que se aguenta é marcar os pacotes que chegam por interface de entrada, restaurar essa marca na resposta e dar a cada marca uma tabela com a sua própria porta de ligação predefinida.

A filtragem frouxa de caminho inverso normalmente tem de ser relaxada para as interfaces afetadas, porque uma resposta chega legitimamente por uma ligação que a tabela principal nunca escolheria. Mantenha as marcas estreitas para que nunca apanhem o tráfego cifrado dos próprios túneis, o que enviaria o túnel através de si mesmo.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Leia as regras existentes antes de acrescentar outra. Prioridades duplicadas e tabelas esquecidas são a razão habitual para uma política de marcas parecer não ter efeito nenhum.

Prove o isolamento parando uma ligação

Com os dois túneis ativos, registe o endereço de cada interface, a rota para um anfitrião atrás de cada túnel e o caminho que um destino não relacionado toma. Peça ao kernel a consulta em vez de ler uma só tabela, porque uma tabela nunca mostra a decisão final.

Depois pare uma instância e veja a sua interface e rotas desaparecerem enquanto a outra continua. Uma quebra na sobrevivente significa que as duas ainda partilham um nome de dispositivo, uma rota ou uma regra de firewall que ninguém separou.

Traga de volta o perfil parado e repita as mesmas verificações. Quando um túnel só sobrevive ao primeiro arranque após um reinício, está a ver um defeito de ciclo de vida e não um desenho de encaminhamento.