Todo peer OpenVPN precisa de uma linha remote? Não exatamente

Duas configurações de peer são comparadas lado a lado, uma tem uma linha remote e a outra não, e a conclusão é que uma delas está quebrada. Essa inferência está errada com frequência suficiente para merecer análise. A diretiva descreve para onde o primeiro pacote deve ser enviado. Ela não seleciona se o processo atua como cliente que inicia ou como gateway que espera, e não decide qual lado prova a sua identidade ao outro.

O que remote realmente especifica

Uma entrada remote nomeia um host, opcionalmente uma porta e um transporte, e opcionalmente várias dessas entradas a tentar por ordem.

A sua ausência tem um significado definido e não indefinido: o processo espera e não age sobre pacotes de um endereço a menos que esse peer se autentique. Por isso um gateway que serve utilizadores itinerantes não tem motivo para nomear nenhum deles antecipadamente.

Leia a entrada como uma relação de endereços. Se se confia na outra ponta respondem os certificados e as opções de verificação, não o facto de se ter escrito um endereço.

Três disposições decidem a resposta

Um cliente itinerante precisa de um destino, porque tem de iniciar e sem ele não sabe onde está o gateway. Um gateway para vários clientes não precisa de destino por utilizador, porque os clientes chegam e autenticam-se. Uma ligação deliberada entre dois peers com extremos conhecidos pode ter destino num lado, nos dois ou em nenhum, conforme o lado que inicia.

Colar um endereço de cliente fixo num gateway geral é o erro que decorre de ignorar essas categorias. Funciona para o único peer cujo endereço foi registado e engana todos os outros.

Nada na diretiva converte uma configuração num servidor para vários clientes, e nada na sua presença impede um papel de servidor. A referência do OpenVPN 2.6 documenta os argumentos opcionais e o comportamento sem remote em separado, o que é uma pista de quão independentes são.

Os papéis de transporte são outro eixo

Em TCP, um lado espera e o outro estabelece a ligação. São diretivas separadas do destino, e misturá-las produz um par em que ambos esperam ou ambos estabelecem a ligação.

Existe também um papel de filtro de origem TCP, e é por isso que a afirmação categórica de que um servidor nunca pode conter remote está errada.

Em UDP não há ligação a estabelecer, por isso ambas as pontas usam o transporte UDP correspondente e a diretiva diz apenas para onde apontar. As mudanças de endereço de um peer autenticado são tratadas por um comportamento dedicado e não acrescentando mais entradas. Acertar no transporte é uma condição prévia para que o destino signifique algo, e confundir os dois produz configurações que parecem plausíveis e nunca completam um handshake.

Por que um remote ausente não é uma porta aberta

Um processo sem destino continua a recusar tráfego de peers que não se autenticam, e essa é a parte que as pessoas perdem quando leem a linha ausente como um ouvinte aberto a todos.

A autenticação e o destino são independentes, e a primeira é a que importa para a confiança.

O erro inverso é mais perigoso. Um endereço de origem fixo pode parecer um controlo de acesso porque é específico e fácil de verificar, mas não prova nada sobre quem está do outro lado. Mantenha a verificação de certificados e as verificações de identidade que ligam um certificado ao seu papel. Substituí-las por uma correspondência de endereço troca um controlo real pela sua aparência.

Anote o que a configuração assume

Para cada lado, registe três coisas: como o primeiro pacote chega ao peer, que lado pode aceitar o transporte e o que cada lado verifica sobre o outro.

Esses pressupostos são o desenho. As diretivas são apenas a sua grafia.

Se os dois ficheiros diferirem, verifique se expressam pressupostos diferentes em vez de assumir que um está errado. Um par simétrico de ficheiros não é necessário nem suficiente para um túnel funcional, e a assimetria é muitas vezes a parte que faz funcionar uma topologia.