Servidor ou cliente: qual unidade OpenVPN num Pi com duplo papel

Dois processos de OpenVPN correm num Pi que simultaneamente aceita utilizadores itinerantes e alcança um fornecedor a montante, e não partilham quase nada além do hardware. Um escuta os túneis de entrada enquanto o outro liga para fora. Cada um lê o seu próprio diretório, e cada um tem o seu próprio modo de falha. Reiniciar o errado é a forma mais comum de uma correção do cliente acabar por abanar o ouvinte.

Faça corresponder o nome da unidade ao diretório que ela carrega

O Upstream 2.6 fornece duas unidades de modelo, [email protected] e [email protected]. O modelo de servidor arranca em /etc/openvpn/server e carrega %i.conf a partir daí. O modelo de cliente arranca em /etc/openvpn/client. Uma instância chamada roaming pode existir em ambos os locais ao mesmo tempo, como servidor e como cliente, com duas configurações sem relação e nenhum vínculo entre elas além da cadeia.

Pergunte ao systemd em vez do sistema de ficheiros, porque os empacotadores acrescentam ficheiros adicionais que podem mudar o diretório de trabalho ou os argumentos que o binário recebe.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

O primeiro comando lista cada unidade instanciada, incluindo as que falharam e ficaram carregadas. O segundo imprime o ficheiro da unidade juntamente com qualquer substituição. O terceiro é a forma mais rápida de ver os dois factos que decidem a questão: o diretório em que o processo arranca, e o caminho de configuração que lhe foi entregue.

Decida pela direção dos pacotes, não pelo nome da interface

Uma instância de servidor possui um socket de escuta e aceita ligações. O seu transporte cifrado é entrada local e saída local no Pi, enquanto o tráfego que reencaminha para utilizadores segue o caminho de reencaminhamento e responde a outro conjunto de regras. Uma instância de cliente não tem ouvinte nesse sentido: liga-se a um par, por isso o seu transporte cifrado é saída local em direção à camada inferior.

Essa diferença diz-lhe a que pertence uma regra. Uma regra que corresponde a uma interface dentro de uma cadeia de reencaminhamento só permite o tráfego que o encaminhamento já selecionou; nunca seleciona a rota. Quando os pacotes de um utilizador itinerante saem pelo caminho errado, a cadeia a inspecionar é forward, não output.

Olhe para os sockets antes de teorizar. Um servidor ligado a udp/1194 mostra um socket de escuta. O cliente mostra uma associação ao endereço do fornecedor e nada a escutar.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

A rota predefinida de uma instância pode capturar as respostas da outra

Um redirect-gateway empurrado pelo cliente a montante instala uma rota predefinida que compete com tudo o resto na máquina, incluindo as respostas que o servidor envia aos utilizadores itinerantes. O OpenVPN abre uma exceção para o seu próprio endereço de par para que o túnel continue alcançável, mas essa exceção não diz nada sobre um telemóvel numa rede de hotel.

O sintoma é normalmente assimétrico. O handshake completa-se, o cliente reporta ligado, e o tráfego morre após o primeiro pacote de resposta. O encaminhamento de políticas baseado na origem, ou uma marca de pacote colocada na instância do servidor com --mark, mantém os dois fluxos separados; nenhuma das duas é um conjunto completo de regras por si só, e ambas precisam de rotas válidas na tabela que escolherem.

Teste a decisão local em vez do estado do túnel, porque o núcleo escolhe a origem e a interface antes de o OpenVPN ver o pacote.

ip route get 203.0.113.44
ip rule show

Reinicie um papel e prove que o outro sobreviveu

A ordem importa quando ambos os papéis dependem da mesma camada inferior. Reinicie o cliente primeiro se a rota a montante tiver de existir antes de o tráfego dos utilizadores poder ser reencaminhado, e reinicie o servidor primeiro quando apenas muda o seu ouvinte ou o seu conjunto. Em qualquer caso, confirme as duas unidades depois, porque um reinício falhado pode deixar o outro papel a correr com estado desatualizado.

Escreva a condição de paragem antes da alteração: perder o túnel a montante bloqueia os utilizadores itinerantes, ou recai no uplink próprio do Pi? O DNS e o IPv6 também precisam de uma resposta explícita, porque um resolver empurrado sobrevive muitas vezes à rota que o tornou útil.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Aceite a alteração apenas quando três coisas se verificam ao mesmo tempo: uma nova ligação de entrada se completa, uma aplicação reencaminhada chega ao seu destino pela saída prevista, e ambos os processos ainda reportam o par esperado. Se uma das três falhar, mudou a instância errada ou a rota errada, e o passo seguinte é reler a unidade em vez de reiniciar outra coisa.