To DNS-namn, éin OpenVPN-port: kva som faktisk vel

To A-poster, éi adresse, éin daemon: uansett kva namn ein brukar skriv, er pakken som kjem identisk, og prosessen som er bunden til port 1194 har ingenting å skilje dei to med. Dette er ikkje ein feilkonfigurasjon som ventar på reparasjon; det er grensa for kva eit namneoppslag kan uttrykkje. Alt som vel mellom to OpenVPN-instansar, må vere ein verdi klienten legg i sambandet og som frontenden kan lese tilbake, og ein vanleg OpenVPN-klient legg ingen slik verdi i klartekst. Det som følgjer, er kvar det lèt deg, og kva oppsett som faktisk deler trafikken.

Start med det resolvaren gjev tilbake

Ein klient spør etter vpn-a.example og får ei adresse; den adressa pluss ein port er alt han ringjer. Namnet blir brukt opp lokalt, under oppslaget, og det blir aldri eit felt på linja, så lyttaren i andre enden kan ikkje sjå kva etikett som vart brukt. Peik vpn-a.example og vpn-b.example mot same vert, og begge oppslaga gjev same mål, og difor søg daemonen begge sambanda inn i éin instans utan å registrere ein skilnad. Adressebaserte profilar oppfører seg nøyaktig som namnebaserte, av same grunn.

Dette stengjer òg ein familie av freistande omvegar: ekstra alias, å velje eit sertifikat per namn på éin socket, eller ein brannmurregel knytt til namnet det vart spurt om. Ingen av dei kan handle på informasjon som alt var kasta før den første pakken forlét klienten. Viss to servarar må halde fram med å vere skilde, må delinga reise saman med sjølve sambandet, altså ei adresse, ein port eller eit nyttelastfelt som protokollen definerer.

Den einaste veljaren som tel, køyrer inne i pakken

HTTP løyser dette med ein Host-header, og TLS med ei servernamn-utviding i ClientHello, og slik tener éi adresse mange nettstader bak éin lyttar. Begge verkar fordi protokollen på linja ber ein førespurnad om ein bestemt teneste. Det relevante faktumet om OpenVPN er at ingen av desse felta finst på laget ein mellomliggande boks undersøkjer.

I eit vanleg oppsett skjer TLS-handtrykket som verner kontrollkanalen etter at den ytre sesjonen er etablert, og det blir bore inne i han, så ein lyttar som ikkje har avslutta den sesjonen ser ein ugjennomsiktig straum. Han kan framleis seie at dette er OpenVPN, fordi opkoden og innramminga i dei første byta er attkjennelege, men servernamnet, om det finst, sit i den krypterte delen. Eit design som ventar å lese ein virtuell vert frå den ytre pakken, les eit felt som protokollen aldri skriv der. Det kjem av korleis tunnelen er bygd, ikkje av eit hol som ein smartare mønstertilpassing kunne lukke.

Kvar ein protokolldelar stoppar

Ein multipleksar av den typen sslh-prosjektet dokumenterer, lyttar på éin port, undersøkjer dei første byta og overlèt sambandet til den backenden som snakkar protokollen han kjende att. Det er reell verdi når éin port må tene SSH, HTTPS og OpenVPN samtidig.

sslh held ein eigen sonde per protokoll, og TLS-sonden kan trekkje ut eit servernamn eller ein ALPN-verdi frå ein ekte ClientHello. Å kjenne att vanleg OpenVPN er ein annan klassifikasjon enn å lese ei TLS-utviding, og dei to komponerer ikkje, fordi ein klient som aldri sender ClientHello til lyttesocketen, lèt sonden stå utan noko å lese. Ein regel som passar på OpenVPN svarar difor «dette er ein OpenVPN-klient» og går ikkje vidare. To OpenVPN-backendar bak den regelen kan ikkje skiljast, frontenden har ingen basis for eit val, og kvar sesjon landar på same stad. Multipleksing deler éin port mellom ulike tenester; det driv ikkje virtuell hosting inne i éi teneste.

Oppsett som verkeleg skil to servarar

Den billegaste ærlege delinga er ei anna offentleg adresse, éi per instans, og eksisterande profilar har alt det som trengst fordi dei peikar på ulike adresser. Den neste er ein annan port på same adresse, som ikkje kostar noko utover eit tal i kvar profil. TCP og UDP held eigne porttabellar, så 1194/tcp og 1194/udp er uslekta sockets og éin av kvar kan eksistere på same vert; det er transportdeling og ikkje namneruting, og det blir ofte forveksla med det. Begge alternativa overlever ein brannmurgjennomgang, fordi regelen passar på noko pakken faktisk inneheld.

Viss grensa du treng går mellom grupper av brukarar i staden for mellom to implementasjonar, kan éin instans med ulike klientkonfigurasjonar, eiga sertifikathandtering og ein uttrykkeleg tilgangspolicy dekkje det. Det kjøper policy inne i ein servar, ikkje isolasjon mellom servarar, og dei to er ulike krav. Isolasjon som må halde under kompromittering, treng framleis adressa eller brannmurkanten.

Ein TLS-terminator framfor OpenVPN kan eksponere eit ekte servernamn for ein dugande frontend, men berre når klientsida òg er konfigurert for det ekstra laget. Eksisterande profilar får ikkje åtferda ved å bli peika på same adresse.

Prov veljaren før du byggjer

Namngje feltet som skal identifisere ein backend, og stadfest deretter at klienten faktisk sender det; viss svaret er ei adresse, held planen, og viss det er eit servernamn inne i eit handtrykk som aldri når lyttaren, reddar inga mengd DNS-arbeid det. Tre kommandoar avgjer lyttarsida 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-linja gjev berre eit sertifikat der noko på den adressa avsluttar TLS; mot ein vanleg OpenVPN-lyttar stoppar ho eller feilar, og det er i seg sjølv svaret på kva det ytre laget eksponerer. journal-linja, lesen på kvar backend, viser kva instans som tok imot sesjonen. Frontend-loggene registrerer kva som vart klassifisert og aldri kva som var meint, så backenden er framleis den einaste autoriteten på kvar ein brukar landa.

Avslutt med to profilar laga for å nå ulike servarar, kople dei til éin om gongen og noter backend-loggen for kvar. Viss begge sesjonane dukkar opp i same journal, manglar veljaren i staden for å vere feilkonfigurert, og rettinga er ei adresse eller ein port klienten kan sikte på. Å redigere rutingsregelen hjelper ikkje, fordi regelen aldri fekk noko å rute på. Når delinga er reell, skriv ho ved sida av profilane, så neste person ikkje legg til eit ekstra alias og ventar at det gjer jobben.