Dous nomes DNS, un porto OpenVPN: que selecciona realmente

Dous rexistros A, un enderezo, un daemon: escriba o usuario o nome que escriba, o paquete que chega é idéntico, e o proceso ligado ao porto 1194 non ten con que distinguilos. Non é unha configuración errónea agardando reparación; é o límite do que pode expresar unha consulta de nome. Calquera cousa que escolla entre dúas instancias de OpenVPN ten que ser un valor que o cliente poña na conexión e que o frontend poida reler, e un cliente OpenVPN estándar non pon ningún valor así en claro. O que segue é onde te deixa iso e que disposicións separan de verdade o tráfico.

Comeza polo que devolve o resolver

Un cliente pide vpn-a.example e recibe un enderezo; ese enderezo máis un porto é todo o que marca. O nome consómese localmente, durante a consulta, e nunca se converte nun campo no cable, así que o listener do outro extremo non pode ver que etiqueta se usou. Apunta vpn-a.example e vpn-b.example a un mesmo host e ambas consultas darán o mesmo destino, e por iso o daemon absorbe as dúas conexións nunha soa instancia sen rexistrar diferenza. Os perfís baseados en enderezo compórtanse exactamente igual que os baseados en nome, pola mesma razón.

Isto tamén pecha unha familia de solucións tentadoras: alias adicionais, escoller un certificado por nome nun só socket ou unha regra de cortafuegos ligada ao nome consultado. Ningunha delas pode actuar sobre información que xa se descartou antes de que o primeiro paquete saíse do cliente. Se dous servidores teñen que seguir separados, a separación ten que viaxar coa propia conexión, é dicir, un enderezo, un porto ou un campo de carga útil que defina o protocolo.

O único selector que conta viaxa dentro do paquete

HTTP resólveo cunha cabeceira Host, e TLS cunha extensión de nome de servidor no ClientHello, e así un enderezo serve moitos sitios detrás dun só listener. Ambos funcionan porque o protocolo no cable leva unha petición para un servizo concreto. O feito relevante sobre OpenVPN é que ningún deses campos está presente na capa que inspecciona unha caixa intermedia.

Nunha disposición estándar o handshake TLS que protexe a canle de control ocorre unha vez establecida a sesión exterior e transpórtase dentro dela, así que un listener que non rematou esa sesión ve un fluxo opaco. Aínda pode dicir que isto é OpenVPN, porque o opcode e o encadramento dos primeiros bytes son recoñecibles, pero o nome de servidor, se existe, está na parte cifrada. Un deseño que espera ler un host virtual do paquete exterior está lendo un campo que o protocolo nunca escribe aí. Iso vén de como está construído o túnel, non dun oco que unha coincidencia de patróns máis lista puidese pechar.

Onde un divisor de protocolos queda curto

Un multiplexor do tipo que documenta o proxecto sslh escoita nun porto, inspecciona os primeiros bytes e entrega a conexión ao backend que fale o protocolo que recoñeceu. Iso é valor real cando un só porto ten que servir SSH, HTTPS e OpenVPN á vez.

sslh mantén unha sonda aparte por protocolo, e a súa sonda TLS pode extraer un nome de servidor ou un valor ALPN dun ClientHello auténtico. Recoñecer OpenVPN nativo é unha clasificación distinta de ler unha extensión TLS, e as dúas non se compoñen, porque un cliente que nunca envía un ClientHello ao socket de escoita deixa a sonda sen nada que ler. Por iso unha regra que coincide con OpenVPN responde «este é un cliente OpenVPN» e non vai máis alá. Dous backends OpenVPN detrás desa regra son indistinguibles, o frontend non ten base para escoller, e cada sesión aterra no mesmo sitio. O multiplexado comparte un porto entre servizos distintos; non fai aloxamento virtual dentro dun servizo.

Disposicións que separan de verdade dous servidores

A separación honesta máis barata é un segundo enderezo público, un por instancia, e os perfís existentes xa levan o necesario porque apuntan a enderezos distintos. A seguinte é un porto distinto no mesmo enderezo, que non custa nada máis alá dun número en cada perfil. TCP e UDP manteñen táboas de portos separadas, así que 1194/tcp e 1194/udp son sockets non relacionados e un de cada un pode coexistir nun mesmo host; iso é separación de transporte, non encamiñamento por nome, e a miúdo confúndese con el. Ambas opcións sobreviven a unha revisión de cortafuegos, porque a regra coincide con algo que o paquete contén de verdade.

Se a fronteira que necesitas discorre entre grupos de usuarios en lugar de entre dúas implementacións, unha instancia con configuracións de cliente distintas, o seu propio manexo de certificados e unha política de acceso explícita pode cubrilo. O que iso compra é política dentro dun servidor, non illamento entre servidores, e son requisitos distintos. O illamento que debe soster baixo compromiso segue necesitando o enderezo ou a beira do cortafuegos.

Un terminador TLS colocado diante de OpenVPN pode expor un nome de servidor real a un frontend capaz, pero só cando o lado cliente tamén está configurado para esa capa extra. Os perfís existentes non adquiren o comportamento por apuntalos ao mesmo enderezo.

Demostra o selector antes de construír

Nomea o campo que identificará un backend e despois confirma que o cliente o envía de verdade; se a resposta é un enderezo, o plan sostiña, e se é un nome de servidor dentro dun handshake que nunca chega ao listener, ningunha cantidade de traballo de DNS o salvará. Tres comandos resolven rápido o lado que escoita.

ss -lntup | grep -E ':443|:1194'
openssl s_client -connect vpn-a.example:443 -servername vpn-a.example </dev/null | head -n 20
journalctl -u openvpn-server@server-a -n 20 --no-pager

A liña de openssl só dá un certificado onde algo nese enderezo remata TLS; contra un listener OpenVPN nativo atáscase ou falla, e iso é en si a resposta sobre que expón a capa exterior. A liña de journal, lida en cada backend, mostra que instancia aceptou a sesión. Os rexistros do frontend anotan que se clasificou e nunca que se pretendía, así que o backend segue sendo a única autoridade sobre onde aterrou un usuario.

Remata con dous perfís pensados para alcanzar servidores distintos, conéctalos de un en un e anota o rexistro do backend para cada un. Se ambas sesións aparecen no mesmo journal, falta o selector en lugar de estar mal configurado, e o arranxo é un enderezo ou un porto que o cliente poida atacar. Editar a regra de encamiñamento non axudará, porque á regra nunca se lle deu nada polo que encamiñar. Unha vez que a separación é real, escríbea xunto aos perfís para que a seguinte persoa non engada un segundo alias e espere que faga o traballo.