Dos noms DNS, un port OpenVPN: què selecciona realment

Dos registres A, una adreça, un dimoni: sigui quin sigui el nom que escrigui l'usuari, el paquet que arriba és idèntic, i el procés lligat al port 1194 no té res per distingir-los. Això no és una configuració errònia esperant reparació; és el límit del que pot expressar una consulta de nom. Qualsevol cosa que triï entre dues instàncies d'OpenVPN ha de ser un valor que el client posi a la connexió i que el frontend pugui tornar a llegir, i un client OpenVPN estàndard no hi posa cap valor d'aquest tipus en clar. El que segueix és on us deixa això i quines disposicions separen realment el trànsit.

Comenceu pel que retorna el resolutor

Un client demana vpn-a.example i rep una adreça; aquesta adreça més un port és tot a què es connecta. El nom es consumeix localment, durant la consulta, i mai no es converteix en un camp a la xarxa, així que el receptor de l'altre extrem no pot veure quina etiqueta s'ha fet servir. Apunteu vpn-a.example i vpn-b.example a un mateix amfitrió i ambdues consultes donaran la mateixa destinació, i per això el dimoni absorbeix les dues connexions en una sola instància sense registrar cap diferència. Els perfils basats en adreça es comporten exactament com els basats en nom, per la mateixa raó.

Això també tanca una família de solucions temptadores: àlies addicionals, triar un certificat per nom en un sol sòcol o una regla de tallafocs lligada al nom consultat. Cap d'elles no pot actuar sobre informació que ja s'havia descartat abans que el primer paquet sortís del client. Si dos servidors han de romandre separats, la separació ha de viatjar amb la connexió mateixa, cosa que vol dir una adreça, un port o un camp de càrrega útil que defineixi el protocol.

L'únic selector que compta viatja dins del paquet

HTTP ho gestiona amb una capçalera Host, i TLS ho gestiona amb una extensió de nom de servidor al ClientHello, i així una adreça serveix molts llocs darrere d'un sol receptor. Tots dos funcionen perquè el protocol de xarxa porta una petició per a un servei concret. El fet rellevant sobre OpenVPN és que cap d'aquests dos camps no és present a la capa que inspecciona una caixa intermèdia.

En una disposició estàndard, l'apretada de mans TLS que protegeix el canal de control passa un cop establerta la sessió exterior i es transporta dins seu, així que un receptor que no ha acabat aquella sessió veu un flux opac. Encara pot dir que això és OpenVPN, perquè l'opcode i l'emmarcament dels primers bytes són recognoscibles, però el nom de servidor, si existeix, se seu a la part xifrada. Un disseny que espera llegir un amfitrió virtual del paquet exterior està llegint un camp que el protocol no hi escriu mai. Això ve de com es construeix el túnel, no d'una escletxa que una coincidència de patrons més enginyosa pogués tancar.

On un divisor de protocols es queda curt

Un multiplexor del tipus que documenta el projecte sslh escolta en un port, inspecciona els primers bytes i lliura la connexió al backend que parli el protocol que ha reconegut. Això és un valor real quan un sol port ha de servir SSH, HTTPS i OpenVPN alhora.

sslh manté una sonda separada per protocol, i la seva sonda TLS pot extreure un nom de servidor o un valor ALPN d'un ClientHello autèntic. Reconèixer OpenVPN natiu és una classificació diferent de llegir una extensió TLS, i les dues no es componen, perquè un client que no envia mai cap ClientHello al sòcol d'escolta deixa la sonda sense res a llegir. Per tant, una regla que coincideix amb OpenVPN respon “aquest és un client OpenVPN” i no va més enllà. Dos backends OpenVPN darrere d'aquesta regla són indistingibles, el frontend no té cap base per triar, i cada sessió acaba al mateix lloc. La multiplexació comparteix un port entre serveis diferents; no fa allotjament virtual dins d'un sol servei.

Disposicions que separen realment dos servidors

La separació honesta més barata és una segona adreça pública, una per instància, i els perfils existents ja porten el que cal perquè apunten a adreces diferents. La següent és un port diferent a la mateixa adreça, que no costa res més enllà d'un número a cada perfil. TCP i UDP mantenen taules de ports separades, així que 1194/tcp i 1194/udp són sòcols no relacionats i un de cada pot coexistir en un mateix amfitrió; això és separació de transport, no encaminament per nom, i sovint es confon amb ell. Totes dues opcions superen una revisió de tallafocs, perquè la regla coincideix amb una cosa que el paquet conté realment.

Si la frontera que necessiteu discorre entre grups d'usuaris en lloc de entre dues implementacions, una instància amb configuracions de client diferents, la seva pròpia gestió de certificats i una política d'accés explícita pot cobrir-ho. El que això compra és política dins d'un servidor, no aïllament entre servidors, i són dos requisits diferents. L'aïllament que ha de mantenir-se sota compromís encara necessita l'adreça o la vora del tallafocs.

Un terminador TLS posat davant d'OpenVPN pot exposar un nom de servidor real a un frontend capaç, però només quan el costat client també està configurat per a aquesta capa extra. Els perfils existents no adquireixen el comportament pel fet d'apuntar-los a la mateixa adreça.

Proveu el selector abans de construir

Anomeneu el camp que identificarà un backend i després confirmeu que el client l'envia de veritat; si la resposta és una adreça, el pla aguanta, i si és un nom de servidor dins d'una apretada de mans que no arriba mai al receptor, cap quantitat de feina de DNS no ho salvarà. Tres ordres resolen de pressa el costat receptor.

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

La línia d'openssl només dóna un certificat allà on alguna cosa d'aquella adreça acaba TLS; contra un receptor OpenVPN natiu s'encalla o falla, i això mateix és la resposta sobre què exposa la capa exterior. La línia de journal, llegida a cada backend, mostra quina instància ha acceptat la sessió. Els registres del frontend anoten què s'ha classificat i mai què es pretenia, així que el backend continua sent l'única autoritat sobre on ha aterrat un usuari.

Acabeu amb dos perfils pensats per arribar a servidors diferents, connecteu-los d'un en un i anoteu el registre del backend per a cadascun. Si les dues sessions apareixen al mateix journal, el selector falta en lloc d'estar mal configurat, i la solució és una adreça o un port que el client pugui adreçar. Editar la regla d'encaminament no ajudarà, perquè a la regla mai no se li ha donat res per encaminar. Un cop la separació sigui real, escriviu-la al costat dels perfils perquè la propera persona no afegeixi un segon àlies i esperi que faci la feina.