Debería o seu cliente OpenVPN usar nobind ou un porto fixo?

Dous perfís que difiren nunha soa liña compórtanse de xeito distinto no momento en que un segundo cliente arrinca no mesmo host. Un leva nobind e toma calquera porto local que lle dea o núcleo; o outro reserva 1194, e a segunda instancia morre cun enderezo xa en uso. Esa liña decide quen escolle o porto de orixe, o que á súa vez decide se o perfil pode convivir con calquera outra cousa na máquina. Tres preguntas resólveno, e a primeira responde á maioría dos perfís antes de chegar ás outras dúas.

Que omite realmente nobind

Por defecto o cliente liga un socket local antes de marcar, e o porto local é 1194 salvo que o perfil diga o contrario. nobind elimina esa reserva, así que a pila asigna un porto non usado no momento da conexión. É unha excepción, non un valor por defecto, e un cliente sen a liña retén 1194, que é exactamente por que choca unha segunda instancia non fixada. A maioría dos perfís de cliente distribuídos levan a directiva por ese motivo, e que un ficheiro de exemplo faga algo non é o mesmo que o mecanismo o faga por defecto.

O que non cambia é o lado afastado. O servidor segue escoitando onde o perfil di que escoita, e o porto de destino na configuración segue sendo o porto de destino. Un porto de orixe dinámico cambia o enderezo de retorno do seu propio socket e nada do do servidor.

Tampouco oculta nada. O seu enderezo público é aquilo ao que o camiño o traduce, o paquete segue cruzando a rede local, e quen xestione esa rede segue vendo un fluxo. nobind non é nin unha función de privacidade nin unha elusión de cortalumes.

Tres condicións que o deciden

Unha pregunta decide as outras dúas, así que respóndaa antes de editar nada. Se o par marca, as preguntas restantes só afinan unha decisión xa tomada. Se acepta conexións entrantes, ningún axuste do porto local o fai alcanzable.

Inicia este par a conexión? Se marca, un porto de orixe dinámico é inofensivo e normalmente preferible, porque a resposta volve polo mesmo fluxo. Se espera conexións entrantes, un porto dinámico faino inalcanzable a menos que algo diante publique o porto. Esa única resposta separa cada perfil de cliente de cada perfil de servidor.

Filtra o camiño polo porto de orixe? Unha regra estrita escrita para un porto coñecido obriga a un porto local explícito, e o perfil debería rexistrar que regra cumpre. A maioría das redes só filtran por destino, así que esta condición é máis rara que a primeira. Onde se aplica, anula a preferencia por un porto dinámico.

Comparten varias instancias o host? Un só porto fixo non pode servir dúas delas, e unha instancia reiniciada pode atopar 1194 aínda en estado de peche. Os portos dinámicos eliminan ese conflito sen cambiar nada máis. Se non pode responder isto con confianza, asuma que si e deixe que o núcleo escolla.

Onde un porto fixado é a resposta correcta

Algunhas redes filtran polo porto de orixe ademais de polo destino, así que un operador pode ter escrito unha regra que só deixa pasar tráfico dun porto coñecido. Fixar o porto local é entón correcto, e o perfil debería levar un comentario que nomee a regra que cumpre. Fixalo por simetría co porto do servidor non é un motivo, porque os dous números non teñen nada que ver entre si. Se a fixación só existe porque a tiña un modelo, bórrea.

Do contrario, un porto fixado compra problemas: dous clientes nunha máquina non poden manter ambos 1194, e o segundo falla cun erro que apunta ao porto e non ao perfil. Un contedor que se reinicia rápido choca co mesmo muro. A reparación é a directiva que os perfís distribuídos xa contiñan.

Servidor e cliente non son simétricos

manual de OpenVPN 2.6 coloca nobind xunto a lport, que é o argumento nunha liña: unha opción di que escolle o núcleo, a outra di que escolle vostede. Un porto local dinámico só funciona para o par que marca, porque o lado que responde non pode coñecer o porto de antemán. Por iso copiar un perfil de cliente a un servidor produce un oínte ao que ninguén pode chegar.

Nun host con varias interfaces de rede o enderezo é unha decisión separada do porto. Ligar un enderezo local concreto e ligar un porto concreto son dous axustes distintos, e un servidor con dúas ligazóns ascendentes normalmente fixa ambos. Un cliente que fixa ambos asumiu a mesma rixidez sen ningún beneficio.

O resumo trata de roles e non de seguridade: quen marca pode ser flexible coa súa propia orixe, e quen responde non pode. Ningunha das dúas opcións cambia o que o outro extremo aprende sobre a súa identidade. Por iso a directiva aparece nos exemplos de cliente e case nunca nos de servidor.

Verifique o porto que escolleu o núcleo

Tras conectar, lea o socket e non a configuración, porque a configuración declara a intención e o socket declara o que ocorreu. Os feitos que paga a pena rexistrar son o porto local, o extremo remoto e se algo segue escoitando. Nun host Linux os tres están a un comando de distancia.

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

Un cliente con nobind mostra un porto local alto e o porto remoto configurado, que é a forma esperada. Un servidor mostra un socket escoitando no seu porto configurado, e se ese socket falta, o perfil ou non é un oínte ou non puido ligar. Cando existe un fluxo pero non volven paquetes, compare o porto de orixe escollido con calquera filtro de portos do camiño antes de editar o perfil. Cambie unha cousa, reconecte e lea o socket de novo.