O seu cliente OpenVPN deve usar nobind ou uma porta fixa?

Dois perfis que diferem numa única linha comportam-se de forma diferente no momento em que um segundo cliente arranca no mesmo anfitrião. Um leva nobind e aceita qualquer porta local que o kernel atribua; o outro reserva 1194, e a segunda instância morre com um endereço já em uso. Essa linha decide quem escolhe a porta de origem, o que por sua vez decide se o perfil pode coexistir com qualquer outra coisa na máquina. Três perguntas resolvem-no, e a primeira responde à maioria dos perfis antes de chegar às outras duas.

O que nobind realmente dispensa

Por predefinição o cliente liga um socket local antes de marcar, e a porta local é 1194 a menos que o perfil diga o contrário. nobind remove essa reserva, pelo que a pilha atribui uma porta não usada no momento da ligação. É uma exceção, não uma predefinição, e um cliente sem a linha mantém 1194, que é exatamente por isso que uma segunda instância não fixada colide. A maioria dos perfis de cliente distribuídos leva a diretiva por esse motivo, e o facto de um ficheiro de exemplo fazer algo não é o mesmo que o mecanismo o fazer por predefinição.

O que não muda é o lado remoto. O servidor continua a escutar onde o perfil diz que escuta, e a porta de destino na configuração continua a ser a porta de destino. Uma porta de origem dinâmica muda o endereço de retorno do seu próprio socket e nada do do servidor.

Também não esconde nada. O seu endereço público é aquilo em que o caminho o traduz, o pacote continua a atravessar a rede local, e quem gere essa rede continua a ver um fluxo. nobind não é uma funcionalidade de privacidade nem uma forma de contornar a firewall.

Três condições que o decidem

Uma pergunta decide as outras duas, por isso responda-lhe antes de editar seja o que for. Se o par marcar para fora, as restantes perguntas apenas afinam uma decisão já tomada. Se aceitar ligações de entrada, nenhum ajuste da porta local o torna alcançável.

Este par inicia a ligação? Se marcar para fora, uma porta de origem dinâmica é inofensiva e normalmente preferível, porque a resposta segue o mesmo fluxo de volta. Se esperar por ligações de entrada, uma porta dinâmica torna-o inalcançável a menos que algo à frente publique a porta. Essa única resposta separa cada perfil de cliente de cada perfil de servidor.

O caminho filtra pela porta de origem? Uma regra estrita escrita para uma porta conhecida obriga a uma porta local explícita, e o perfil deve registar que regra cumpre. A maioria das redes filtra apenas pelo destino, pelo que esta condição é mais rara do que a primeira. Onde se aplica, sobrepõe-se à preferência por uma porta dinâmica.

Várias instâncias partilham o anfitrião? Uma única porta fixa não consegue servir duas delas, e uma instância reiniciada pode encontrar 1194 ainda em estado de fecho. As portas dinâmicas eliminam esse conflito sem alterar mais nada. Se não consegue responder com confiança, assuma que sim e deixe o kernel escolher.

Onde uma porta fixada é a resposta certa

Algumas redes filtram tanto pela porta de origem como pelo destino, pelo que um operador pode ter escrito uma regra que só deixa passar tráfego de uma porta conhecida. Fixar a porta local é então correto, e o perfil deve levar um comentário que nomeie a regra que cumpre. Fixar por simetria com a porta do servidor não é um motivo, porque os dois números não têm nada a ver um com o outro. Se a fixação só existe porque um modelo a tinha, apague-a.

Caso contrário, uma porta fixada compra problemas: dois clientes numa máquina não podem ambos manter 1194, e o segundo falha com um erro que aponta para a porta e não para o perfil. Um contentor que reinicia depressa embate na mesma parede. A reparação é a diretiva que os perfis distribuídos já continham.

Servidor e cliente não são simétricos

manual do OpenVPN 2.6 coloca nobind ao lado de lport, que é o argumento numa linha: uma opção diz que o kernel escolhe, a outra diz que é você. Uma porta local dinâmica só funciona para o par que marca, porque o lado que responde não pode conhecer a porta de antemão. É por isso que copiar um perfil de cliente para um servidor produz um ouvinte a que ninguém consegue chegar.

Num anfitrião com várias interfaces de rede, o endereço é uma decisão separada da porta. Ligar um endereço local específico e ligar uma porta específica são duas definições diferentes, e um servidor com duas ligações ascendentes normalmente fixa ambas. Um cliente que fixa ambas assumiu a mesma rigidez sem qualquer benefício.

O resumo é sobre papéis e não sobre segurança: quem marca pode ser flexível quanto à sua própria origem, e quem responde não pode. Nenhuma das opções altera o que o outro extremo aprende sobre a sua identidade. É também por isso que a diretiva aparece nos exemplos de cliente e quase nunca nos de servidor.

Verifique a porta escolhida pelo kernel

Depois de ligar, leia o socket e não a configuração, porque a configuração declara a intenção e o socket declara o que aconteceu. Os factos que vale a pena registar são a porta local, o ponto final remoto e se algo continua a escutar. Num anfitrião Linux os três estão a um comando de distância.

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

Um cliente com nobind mostra uma porta local alta e a porta remota configurada, que é a forma esperada. Um servidor mostra um socket à escuta na sua porta configurada, e se esse socket faltar o perfil ou não é um ouvinte ou não conseguiu ligar-se. Quando existe um fluxo mas não voltam pacotes, compare a porta de origem escolhida com qualquer filtro de portas no caminho antes de editar o perfil. Altere uma coisa, volte a ligar e leia o socket outra vez.