To DNS-navn, én OpenVPN-port: hva som faktisk velger

To A-poster, én adresse, én daemon: uansett hvilket navn en bruker skriver, er pakken som ankommer identisk, og prosessen som er bundet til port 1194 har ingenting å skille de to med. Dette er ikke en feilkonfigurasjon som venter på reparasjon; det er grensen for hva et navneoppslag kan uttrykke. Alt som velger mellom to OpenVPN-instanser, må være en verdi klienten legger i forbindelsen og som frontenden kan lese tilbake, og en vanlig OpenVPN-klient legger ingen slik verdi i klartekst. Det som følger, er hvor det etterlater deg, og hvilke oppsett som faktisk deler trafikken.

Start med det resolveren gir tilbake

En klient spør etter vpn-a.example og får en adresse; den adressen pluss en port er alt den ringer. Navnet brukes opp lokalt, under oppslaget, og det blir aldri et felt på ledningen, så lytteren i den andre enden kan ikke se hvilken etikett som ble brukt. Pek vpn-a.example og vpn-b.example mot samme vert, og begge oppslagene gir samme destinasjon, og derfor suger daemonen begge forbindelsene inn i én instans uten å registrere en forskjell. Adressebaserte profiler oppfører seg nøyaktig som navnebaserte, av samme grunn.

Dette stenger også en familie av fristende omveier: ekstra aliaser, å velge et sertifikat per navn på én socket, eller en brannmurregel knyttet til navnet som ble spurt om. Ingen av dem kan handle på informasjon som allerede var kastet før den første pakken forlot klienten. Hvis to servere må forbli adskilt, må delingen reise med selve forbindelsen, altså en adresse, en port eller et nyttelastfelt som protokollen definerer.

Den eneste velgeren som teller, kjører inne i pakken

HTTP løser dette med en Host-header, og TLS med en servernavn-utvidelse i ClientHello, og slik betjener én adresse mange nettsteder bak én lytter. Begge virker fordi protokollen på ledningen bærer en forespørsel om en bestemt tjeneste. Det relevante faktumet om OpenVPN er at ingen av disse feltene finnes på laget en mellomliggende boks undersøker.

I et vanlig oppsett skjer TLS-håndtrykket som beskytter kontrollkanalen etter at den ytre sesjonen er etablert, og det bæres inne i den, så en lytter som ikke har avsluttet den sesjonen ser en ugjennomsiktig strøm. Den kan fortsatt si at dette er OpenVPN, fordi opkoden og innrammingen i de første bytene er gjenkjennelige, men servernavnet, hvis det finnes, sitter i den krypterte delen. En design som forventer å lese en virtuell vert fra den ytre pakken, leser et felt som protokollen aldri skriver der. Det kommer av hvordan tunnelen er bygget, ikke av et hull som en smartere mønstertilpasning kunne lukke.

Hvor en protokolldeler stopper

En multiplekser av den typen sslh-prosjektet dokumenterer, lytter på én port, undersøker de første bytene og overlater forbindelsen til den backenden som snakker protokollen den kjente igjen. Det er reell verdi når én port må betjene SSH, HTTPS og OpenVPN samtidig.

sslh holder en egen sonde per protokoll, og TLS-sonden kan trekke ut et servernavn eller en ALPN-verdi fra en ekte ClientHello. Å kjenne igjen vanlig OpenVPN er en annen klassifisering enn å lese en TLS-utvidelse, og de to komponerer ikke, fordi en klient som aldri sender ClientHello til lyttesocketen, lar sonden stå uten noe å lese. En regel som passer på OpenVPN svarer derfor «dette er en OpenVPN-klient» og går ikke videre. To OpenVPN-backender bak den regelen kan ikke skilles, frontenden har ingen basis for et valg, og hver sesjon lander på samme sted. Multipleksing deler én port mellom ulike tjenester; det driver ikke virtuell hosting inne i én tjeneste.

Oppsett som virkelig skiller to servere

Den billigste ærlige delingen er en annen offentlig adresse, én per instans, og eksisterende profiler har allerede det som trengs fordi de peker på ulike adresser. Den neste er en annen port på samme adresse, som ikke koster noe utover et tall i hver profil. TCP og UDP holder egne porttabeller, så 1194/tcp og 1194/udp er ubeslektede sockets og én av hver kan eksistere på samme vert; det er transportdeling og ikke navneruting, og det forveksles ofte med det. Begge alternativene overlever en brannmurgjennomgang, fordi regelen passer på noe pakken faktisk inneholder.

Hvis grensen du trenger går mellom grupper av brukere i stedet for mellom to implementasjoner, kan én instans med ulike klientkonfigurasjoner, egen sertifikathåndtering og en uttrykkelig tilgangspolicy dekke det. Det kjøper policy inne i en server, ikke isolasjon mellom servere, og de to er ulike krav. Isolasjon som må holde under kompromittering, trenger fortsatt adressen eller brannmurkanten.

En TLS-terminator foran OpenVPN kan eksponere et ekte servernavn for en dyktig frontend, men bare når klientsiden også er konfigurert for det ekstra laget. Eksisterende profiler får ikke atferden ved å bli pekt på samme adresse.

Bevis velgeren før du bygger

Navngi feltet som skal identifisere en backend, og bekreft deretter at klienten faktisk sender det; hvis svaret er en adresse, holder planen, og hvis det er et servernavn inne i et håndtrykk som aldri når lytteren, redder ingen mengde DNS-arbeid det. Tre kommandoer avgjør lytterdelen raskt.

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

openssl-linjen gir bare et sertifikat der noe på den adressen avslutter TLS; mot en vanlig OpenVPN-lytter stopper den eller feiler, og det er i seg selv svaret på hva det ytre laget eksponerer. journal-linjen, lest på hver backend, viser hvilken instans som godtok sesjonen. Frontend-loggene registrerer hva som ble klassifisert og aldri hva som var ment, så backenden er fortsatt den eneste autoriteten på hvor en bruker landet.

Avslutt med to profiler laget for å nå ulike servere, koble dem til én om gangen og noter backend-loggen for hver. Hvis begge sesjonene dukker opp i samme journal, mangler velgeren i stedet for å være feilkonfigurert, og rettelsen er en adresse eller en port klienten kan sikte på. Å redigere rutingregelen hjelper ikke, fordi regelen aldri fikk noe å rute på. Når delingen er reell, skriv den ved siden av profilene, så neste person ikke legger til et ekstra alias og forventer at det gjør jobben.