Twee DNS-name, een OpenVPN-poort: wat werklik kies

Twee A-rekords, een adres, een daemon: watter naam 'n gebruiker ook al intik, die pakket wat aankom is identies, en die proses wat aan poort 1194 gebind is, het niks waarmee hy die twee van mekaar kan onderskei nie. Dit is nie 'n verkeerde konfigurasie wat wag om reggemaak te word nie; dit is die grens van wat 'n naam-opsoeking kan uitdruk. Enigiets wat tussen twee OpenVPN-instansies kies, moet 'n waarde wees wat die kliënt in die verbinding plaas en wat die frontent kan teruglees, en 'n standaard OpenVPN-kliënt plaas geen so waarde in die oopte nie. Wat volg, is waar dit jou laat, en watter reëlings die verkeer werklik verdeel.

Begin by wat die resolver teruggee

'n Kliënt vra vir vpn-a.example en kry 'n adres; daardie adres plus 'n poort is die hele ding wat hy skakel. Die naam word plaaslik uitgegee, tydens die opsoeking, en dit word nooit 'n veld op die draad nie, so die luisteraar aan die ander kant kan nie sien watter etiket gebruik is nie. Wys vpn-a.example en vpn-b.example na een gasheer, en albei opsoekings lewer dieselfde bestemming, en daarom absorbeer die daemon albei verbindings in een instansie sonder om 'n verskil te registreer. Adresgebaseerde profiele gedra hom presies soos naamgebaseerde profiele, om dieselfde rede.

Dit sluit ook 'n familie verloklike omwegies af: ekstra aliasse, 'n sertifikaat per naam op een socket kies, of 'n firewallreël wat op die opgevraagde naam reageer. Nie een van hulle kan handel op inligting wat reeds weggegooi is voordat die eerste pakket die kliënt verlaat het nie. As twee servers apart moet bly, moet die splitsing saam met die verbinding self reis, wat beteken 'n adres, 'n poort of 'n payload-veld wat die protokol definieer.

Die enigste kieser wat tel, ry binne die pakket

HTTP bestuur dit met 'n Host-kop, en TLS bestuur dit met 'n bedienernaam-uitbreiding in die ClientHello, en dit is hoe een adres baie werwe agter een luisteraar bedien. Albei werk omdat die draadprotokol 'n versoek vir 'n spesifieke diens dra. Die relevante feit oor OpenVPN is dat nie een van daardie velde op die laag teenwoordig is wat 'n tussenliggende boks ondersoek nie.

In 'n standaard reëling gebeur die TLS-handdruk wat die beheerkanaal beskerm nadat die buitenste sessie gevestig is, en dit word binne-in daardie sessie gedra, so 'n luisteraar wat daardie sessie nie beëindig het nie, sien 'n ondeursigtige stroom. Hy kan steeds sien dit is OpenVPN, want die opkode en raamwerk in die openingsgrepe is herkenbaar, maar die bedienernaam, as daar een is, sit in die geënkripteerde deel. 'n Ontwerp wat verwag om 'n virtuele gasheer uit die buitenste pakket te lees, lees 'n veld wat die protokol nooit daar skryf nie. Dit kom uit hoe die tonnel gebou is, nie uit 'n gaping wat 'n slimmer patroonpassing kan toemaak nie.

Waar 'n protokolsplitter te kort skiet

'n Multiplekser van die soort wat die sslh-projek dokumenteer, luister op een poort, ondersoek die openingsgrepe en gee die verbinding aan watter backend ook al die protokol praat wat hy herken het. Dit is werklike waarde wanneer 'n enkele poort SSH, HTTPS en OpenVPN saam moet bedien.

sslh hou 'n aparte probe per protokol, en sy TLS-probe kan 'n bedienernaam of 'n ALPN-waarde uit 'n egte ClientHello haal. Om native OpenVPN te herken is 'n ander klassifikasie as om 'n TLS-uitbreiding te lees, en die twee komponeer nie, want 'n kliënt wat nooit 'n ClientHello na die luistersocket stuur nie, laat die probe met niks om te lees. 'n Reël wat OpenVPN pas, antwoord dus “dit is 'n OpenVPN-kliënt” en gaan nie verder nie. Twee OpenVPN-backends agter daardie reël is ononderskeibaar, die frontent het geen basis vir 'n keuse nie, en elke sessie beland op dieselfde plek. Multipleksing deel een poort oor verskillende dienste; dit doen nie virtuele gasheer binne een diens nie.

Reëlings wat twee servers werklik skei

Die goedkoopste eerlike splitsing is 'n tweede openbare adres, een per instansie, en bestaande profiele dra reeds wat nodig is, want hulle wys na verskillende adresse. Die volgende is 'n ander poort op dieselfde adres, wat niks kos buiten 'n nommer in elke profiel nie. TCP en UDP hou aparte poorttabelle, so 1194/tcp en 1194/udp is onverwante sockets en een van elkeen kan saam op een gasheer bestaan, wat vervoerskeiding is eerder as naamroetering, en dit word dikwels daarmee verwar. Albei opsies oorleef 'n firewall-hersiening, want die reël pas iets wat die pakket werklik bevat.

As die grens wat jy nodig het tussen groepe gebruikers loop in plaas van tussen twee implementasies, kan een instansie met verskillende kliëntkonfigurasies, sy eie sertifikaatbehandeling en 'n eksplisiete toegangsbeleid dit dek. Wat dit koop, is beleid binne 'n server, nie isolasie tussen servers nie, en die twee is verskillende vereistes. Isolasie wat onder kompromittering moet hou, het steeds die adres of die firewallrand nodig.

'n TLS-beëindiger voor OpenVPN kan 'n egte bedienernaam aan 'n bekwame frontent blootstel, maar net wanneer die kliëntkant ook vir daardie ekstra laag opgestel is. Bestaande profiele kry nie die gedrag deur na dieselfde adres gewys te word nie.

Bewys die kieser voordat jy bou

Noem die veld wat 'n backend sal identifiseer, en bevestig dan dat die kliënt dit werklik stuur; as die antwoord 'n adres is, hou die plan, en as dit 'n bedienernaam binne 'n handdruk is wat nooit die luisteraar bereik nie, sal geen hoeveelheid DNS-werk dit red nie. Drie opdragte beslis die luisterkant vinnig.

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

Die openssl-reël lewer net 'n sertifikaat waar iets op daardie adres TLS beëindig; teen 'n native OpenVPN-luisteraar staak of misluk dit, en dit is self die antwoord oor wat die buitenste laag blootstel. Die journal-reël, op elke backend gelees, wys watter instansie die sessie aanvaar het. Frontent-logs teken op wat geklassifiseer is en nooit wat bedoel is nie, so die backend bly die enigste gesag oor waar 'n gebruiker beland het.

Sluit af met twee profiele wat bedoel is om verskillende servers te bereik, verbind hulle een op 'n slag en noteer die backend-log vir elkeen. As albei sessies in dieselfde journal verskyn, ontbreek die kieser eerder as dat dit verkeerd opgestel is, en die regstelling is 'n adres of 'n poort wat die kliënt kan teiken. Die roeteringsreël wysig sal nie help nie, want die reël het nooit iets gekry om op te roeteer nie. Sodra die splitsing werklik is, skryf dit langs die profiele sodat die volgende persoon nie 'n tweede alias byvoeg en verwag dat dit die werk doen nie.