Dois endereços de serviço num cliente OpenVPN: iroute e lo

A aplicação responde no seu endereço de túnel, e o endereço que documentou para ela não vai a lado nenhum. Nada no registo do OpenVPN se queixa, o par aparece ligado e o concentrador lista exatamente um cliente. A lacuna é que um segundo endereço num cliente são dois factos separados: o anfitrião tem de o possuir, e o concentrador tem de saber qual par o possui. Trate um sem o outro e o tráfego ou morre no concentrador ou chega sem rota para casa.

O alias é local, a propriedade é remota

Um endereço de túnel é negociado, por isso ambos os extremos o aprendem durante o handshake. Um endereço de serviço adicional não é negociado de todo, e é por isso que acrescentá-lo não muda nada no concentrador por si só. O cliente pode possuir o endereço de imediato e o servidor continuará a enviar esse tráfego pela sua rota predefinida ou a descartá-lo. É preciso criar dois registos, em dois locais diferentes.

No cliente, o endereço pertence ao anfitrião, e o loopback é a casa natural para uma identidade de serviço que nunca deveria aparecer numa ligação física. No concentrador, o mapeamento de par para prefixo é uma declaração separada que só o servidor lê. Nenhum dos registos implica o outro.

Mantenha os dois intervalos distintos também nas suas notas. Os endereços de um exemplo são valores de documentação, e sobrepô-los a uma LAN real é a forma mais rápida de fazer uma configuração funcional parecer avariada.

Acrescente o endereço no cliente de forma persistente

Coloque o endereço de serviço no loopback com um prefixo de anfitrião, para que o anfitrião o trate como entrada local e não como uma sub-rede a alcançar. ip address add 10.66.0.10/32 dev lo faz isso para um endereço, e repetir o comando para um segundo endereço modela dois serviços.

Execute isso como um teste pontual e depois mova-o para o que possui a configuração de rede do anfitrião, porque uma adição em tempo de execução desaparece no reinício e os duplicados acumulam-se entre reconexões. Uma unidade systemd ordenada depois da rede é uma opção, e um gestor de rede da distribuição é outra. Escolha o que escolher, o endereço tem de existir antes de a aplicação se ligar, ou o serviço aparece no socket errado. Verifique com ip address show dev lo depois de um reinício e não depois do comando manual.

A ligação é uma decisão separada do endereçamento. Uma aplicação que escuta em todos os endereços aceita tráfego em interfaces que nunca pretendeu, por isso aponte-a para o endereço de serviço específico. Então a política de entrada local tem algo preciso com que coincidir.

Reclame-o no ficheiro CCD que o concentrador lê de facto

No servidor, a declaração de propriedade vai para o ficheiro por cliente selecionado pelo nome comum autenticado, dentro do diretório indicado por client-config-dir. A linha é iroute 10.66.0.10 255.255.255.255, uma por endereço, e diz ao servidor qual par deve receber o tráfego desse destino.

Dois detalhes quebram isto em silêncio. O nome do ficheiro tem de corresponder ao nome que o servidor usa realmente, que muda quando username-as-common-name está em jogo. E iroute só produz efeito em modo TUN com um diretório de configuração de clientes configurado, por isso a mesma linha não faz nada numa implementação em ponte. Acrescente linhas ao ficheiro existente em vez de o substituir, pois ele pode já transportar um endereço fixo ou opções push. A referência do OpenVPN 2.6 documenta tanto o diretório como a diretiva de propriedade.

O próprio núcleo do concentrador também precisa de um caminho para esses destinos para que o tráfego gerado localmente entre no processo do túnel. route 10.66.0.10 255.255.255.255 na configuração do servidor cobre o tráfego que o servidor origina, enquanto os outros clientes precisam de push "route 10.66.0.10 255.255.255.255" para aprender o destino sozinhos.

O encaminhamento e a autorização continuam separados. Uma rota empurrada diz a um cliente para onde enviar pacotes e não concede nada; o serviço ainda tem de aceitar o chamador nos seus próprios termos.

Verifique a política de entrada e o caminho de resposta

Um pacote dirigido ao alias chega ao anfitrião proprietário como entrada local, por isso a questão é se a firewall local permite essa origem e essa porta. Permita a porta de serviço concreta a partir do intervalo de origem da VPN em vez de abrir o endereço inteiro.

As respostas precisam de um caminho de volta para o chamador. Para um chamador dentro do conjunto de túnel normal esse caminho já existe, porque o dispositivo de túnel o transporta. Um chamador atrás de outra rede encaminhada precisa também da rota de retorno dessa rede, e é aqui que as configurações assimétricas perdem pacotes.

Vigie um segundo ouvinte na mesma porta ligado a um endereço diferente, porque o núcleo entrega ao socket que coincidir e os resultados parecem aleatórios. Verifique com ss -lntp e confirme que o endereço ligado é o alias do serviço. O NAT de origem não é necessário aqui, e acrescentá-lo esconde a identidade do chamador da qual os seus registos dependem.

Teste endereços e propriedade separadamente

Teste em dois passos. Primeiro confirme que o anfitrião proprietário consegue alcançar o serviço no seu alias a partir de si mesmo, o que separa os problemas de ligação e firewall do encaminhamento. Depois teste a partir de um chamador VPN real usando a autenticação da própria aplicação. Quando o primeiro passa e o segundo falha, a peça em falta está do lado do concentrador.

Verifique também os modos de falha que sobrevivem a uma ligação: o alias continua atribuído quando o túnel está em baixo, e o concentrador mantém a sua rota quando o par está ausente. Nenhum objeto por si só prova que o serviço é alcançável, e é por isso que o teste em dois passos supera um único ping a partir de um portátil.