Um Pi, duas instâncias OpenVPN: o que cada unidade lê

Conte os processos OpenVPN antes de tocar num perfil. Um Pi que aceita utilizadores em roaming e também marca uma ligação a um serviço a montante corre dois daemons, e cada um lê um ficheiro de configuração escolhido pelo nome de instância que escreveu. Os modelos do pacote dão depois a cada daemon o seu próprio diretório de trabalho, o seu próprio ficheiro de estado de execução e o seu próprio dispositivo de túnel. Se errar esta divisão, passa uma noite a alterar uma definição correta dentro de um ficheiro que o processo em execução nunca abre.

Cada nome de instância escolhe o seu ficheiro

Nos ficheiros de unidade fornecidos com o OpenVPN 2.6, os argumentos de arranque transportam um marcador de instância preenchido com o texto a seguir ao sinal @. O modelo de servidor corre a partir do diretório de configuração do servidor e resolve o seu argumento contra o %i.conf que lá está, enquanto o modelo de cliente faz o mesmo a partir do diretório do cliente. Assim, [email protected] lê admits.conf no diretório do servidor e [email protected] lê uplink.conf no diretório do cliente, e nenhum desses nomes tem qualquer significado no outro diretório.

Confirme o mapeamento na máquina em vez de assumir que o pacote manteve os valores predefinidos. Um drop-in da distribuição pode substituir por completo o diretório de trabalho ou o argumento de configuração.

systemctl cat [email protected]
systemctl cat [email protected]

Leia a linha WorkingDirectory e o argumento de configuração nessa saída, porque só a unidade ativada decide que ficheiro é carregado. Um drop-in que acrescenta --config a ExecStart vence o modelo mesmo quando o caminho do modelo parece correto. Peça os caminhos dos fragmentos e dos drop-ins quando quiser saber se há uma sobreposição local em jogo. Se ambas as funções resolverem para um só ficheiro, tem um único processo a tentar ser servidor e cliente ao mesmo tempo, e a opção mais à frente nesse ficheiro ganha em silêncio.

Transporte local e payload encaminhado atingem hooks diferentes

A ligação cifrada do servidor a cada utilizador em roaming é gerada no próprio Pi, pelo que as suas respostas externas saem pelo hook de saída local. A ligação do cliente ao seu par a montante também é saída gerada localmente, ainda que chegue a uma rede remota. O payload encaminhado é a terceira categoria, e o kernel só o faz corresponder depois de já ter escolhido um dispositivo de saída para o pacote.

Uma regra que corresponde a uma interface de saída dentro de uma cadeia forward pode permitir ou descartar um pacote que o encaminhamento já atribuiu a essa interface, mas nunca escolhe a interface. Quando um anfitrião termina um túnel e origina outro, a política que envia o payload dos utilizadores para o túnel a montante e a política que protege as respostas cifradas do próprio Pi são duas decisões separadas. Calham na mesma NIC física, e é por isso que se confundem.

Essa distinção explica uma falha parcial comum. Os utilizadores ligam-se, o handshake completa-se e o tráfego deles continua a sair pelo caminho errado, porque o handshake era local e o payload era forward e só um dos dois foi alguma vez testado.

Uma rota importada pode engolir as respostas aos seus utilizadores

A definição de segurança do perfil de cliente decide o que a montante pode empurrar para a tabela de encaminhamento do Pi, e um redirecionamento amplo é a opção que transforma um anfitrião de dupla função a funcionar num avariado. Se a rota empurrada cobrir os endereços públicos dos utilizadores em roaming, as respostas que o servidor gera para eles podem seguir a nova rota para dentro do túnel a montante em vez de saírem pela camada de base. As pessoas confirmam muitas vezes que o túnel para o fornecedor ainda funciona e param aí, porque esse tráfego é o transporte do próprio túnel e continua a fluir enquanto tudo o resto se comporta mal.

A política baseada na origem ou numa marca é a forma de manter os dois fluxos separados. A opção mark de Linux do OpenVPN marca os pacotes cifrados do próprio daemon com uma marca de firewall, que uma regra de encaminhamento pode depois enviar para uma tabela dedicada. Os endereços de origem funcionam igualmente bem quando as respostas externas do servidor saem sempre de um único endereço de base. Qualquer das abordagens precisa de rotas válidas na tabela que seleciona e de uma exceção para o endpoint do fornecedor, ou o próprio túnel deixa de subir.

Pergunte ao kernel qual o caminho que uma resposta tomaria realmente antes de escrever qualquer regra. Os endereços abaixo são marcadores para um endereço de base do Pi e para o endereço público de um utilizador em roaming.

ip rule show
ip route get 198.51.100.7 from 192.0.2.10

Verifique a divisão e depois pare uma função de cada vez

Teste três fluxos em separado, porque um handshake a funcionar não prova nada sobre os outros dois. Aceite uma nova ligação de entrada, envie uma aplicação permitida pela saída a montante e confirme que ambos os processos ainda alcançam os seus pares.

Depois pare a função de cliente e observe o que a função de servidor mantém. É a forma mais barata de encontrar uma regra de rota ou de marca que se destinava a uma instância e foi aplicada às duas.

systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pager

O que quer ver é o listener ainda ligado, o dispositivo de túnel ainda presente e o registo livre de novos erros enquanto a função de cliente está parada. Se parar o cliente também cortar as respostas do servidor aos utilizadores existentes, as duas funções partilham algo que devia estar limitado a uma delas. Registe que instância, que ficheiro de configuração e que dono de fluxo cada alteração tocou, porque a próxima pessoa a depurar este anfitrião vai repetir a mesma descoberta a partir do zero.