Kaks DNS-nime, üks OpenVPN-port: mis tegelikult valib
Kaks hostinime, mis osutavad samale aadressile, jõuavad ikkagi ühe kuulajani. Backendit saab valida ainult väli, mille klient saadab, ja tavaline OpenVPN ei saada ühtegi.
Kaks A-kirjet, üks aadress, üks deemon: ükskõik millise nime kasutaja sisestab, saabuv pakett on identne ja pordiga 1194 seotud protsessil pole millegagi neid eristada. See pole valesti seadistatud konfiguratsioon, mis ootab parandamist; see on nimepäringu väljendusvõime piir. Kõik, mis valib kahe OpenVPN eksemplari vahel, peab olema väärtus, mille klient ühendusse paneb ja mille frontend saab tagasi lugeda, ning tavaline OpenVPN-i klient ei pane sellist väärtust avalikult. Järgnev näitab, kuhu see viib ja millised lahendused liikluse tõesti eraldavad.
Alusta sellest, mida resolver tagastab
Klient küsib vpn-a.example ja saab aadressi; see aadress pluss port on kõik, millele ta helistab. Nimi kulub ära kohapeal, päringu ajal, ega muutu kunagi väljaks juhtmel, seega teises otsas olev kuulaja ei näe, millist silti kasutati. Suuna vpn-a.example ja vpn-b.example ühele hostile ja mõlemad päringud annavad sama sihtkoha, mistõttu deemon neelab mõlemad ühendused ühte eksemplari, ilma et erinevust registreeriks. Aadressipõhised profiilid käituvad täpselt nagu nimipõhised, samal põhjusel.
See sulgeb ka pere ahvatlevaid möödasõite: lisasildid, sertifikaadi valimine iga nime kohta ühes soketis või tulemüürireegel, mis on seotud küsitud nimega. Ükski neist ei saa tegutseda info põhjal, mis oli juba kõrvale heidetud enne, kui esimene pakett kliendist lahkus. Kui kaks serverit peavad jääma eraldi, peab eraldus liikuma ühenduse endaga kaasa, mis tähendab aadressi, porti või protokolli määratud kandevälja.
Ainus loetav valija sõidab paketi sees
HTTP lahendab selle Host-päisega ja TLS serverinime laiendiga ClientHello's, ja nii teenindab üks aadress paljusid saite ühe kuulaja taga. Mõlemad töötavad, sest juhtmeprotokoll kannab konkreetse teenuse päringut. OpenVPN-i puhul on oluline see, et kumbki neist väljadest ei esine kihis, mida vahekast uurib.
Tavalises lahenduses toimub juhtkanalit kaitsv TLS-käepigistus pärast välissessiooni loomist ja seda kantakse selle sees, nii et kuulaja, kes pole seda sessiooni lõpetanud, näeb läbipaistmatut voogu. Ta suudab siiski öelda, et tegu on OpenVPN-iga, sest avabaitide opkood ja raamimine on äratuntavad, kuid serverinimi, kui see on olemas, asub krüpteeritud osas. Kujundus, mis loodab välispaketist virtuaalhosti lugeda, loeb välja, mida protokoll sinna kunagi ei kirjuta. See tuleneb tunneliehituse loogikast, mitte august, mille nutikam mustriotsing võiks sulgeda.
Kus protokollijaotur lühikeseks jääb
Multiplekser seda tüüpi, mida dokumenteerib sslh projekt, kuulab ühel pordil, uurib avabaite ja annetab ühenduse sellele backendile, mis räägib äratuntud protokolli. See on tõeline väärtus, kui üks port peab teenindama SSH-d, HTTPS-i ja OpenVPN-i korraga.
sslh hoiab iga protokolli jaoks eraldi sondi ja selle TLS-sond suudab tõelise ClientHello seest välja tõmmata serverinime või ALPN-väärtuse. Tavalise OpenVPN-i äratundmine on teine klassifikatsioon kui TLS-laiendi lugemine ja need kaks ei liitu, sest klient, kes ei saada kunagi ClientHello'd kuulavasse soketisse, jätab sondi ilma millegi lugemiseta. Seetõttu vastab OpenVPN-iga sobiv reegel „see on OpenVPN-i klient“ ega lähe kaugemale. Kaks OpenVPN-i backendit selle reegli taga on eristamatud, frontendil pole valikuks alust ja iga sessioon maandub samas kohas. Multipleksimine jagab ühe pordi eri teenuste vahel; see ei tee virtuaalhostingut ühe teenuse sees.
Lahendused, mis tõesti kaks serverit eraldavad
Odavaim aus eraldus on teine avalik aadress, üks eksemplari kohta, ja olemasolevad profiilid kannavad juba vajalikku, sest need osutavad erinevatele aadressidele. Järgmine on teine port samal aadressil, mis ei maksa midagi peale numbri igas profiilis. TCP ja UDP peavad eraldi porditabeleid, seega 1194/tcp ja 1194/udp on seostamata soketid ja üks kummastki võib ühel hostil kõrvuti eksisteerida; see on transpordieraldus, mitte nimipõhine marsruutimine, ja seda aetakse sellega sageli segamini. Mõlemad valikud peavad tulemüüriülevaatusele vastu, sest reegel sobib millegagi, mis paketis tegelikult on.
Kui vajalik piir jookseb kasutajagruppide vahel, mitte kahe teostuse vahel, suudab seda katta üks eksemplar erinevate kliendikonfiguratsioonide, oma sertifikaadikäitluse ja selgesõnalise juurdepääsupoliitikaga. See ostab poliitika serveri sees, mitte isolatsiooni serverite vahel, ja need on erinevad nõuded. Isolatsioon, mis peab vastu pidama kompromissi korral, vajab endiselt aadressi või tulemüüri serva.
OpenVPN-i ette pandud TLS-terminaator võib paljastada tõelise serverinime võimekale frontendile, aga ainult siis, kui ka kliendipool on selle lisakihi jaoks seadistatud. Olemasolevad profiilid ei omanda seda käitumist lihtsalt sama aadressi poole suunamisega.
Tõesta valija enne ehitamist
Nimeta väli, mis backendi identifitseerib, ja kinnita seejärel, et klient seda tõesti saadab; kui vastuseks on aadress, peab plaan, ja kui selleks on serverinimi käepigistuse sees, mis kunagi kuulajani ei jõua, ei päästa seda ükski DNS-töö. Kolm käsku lahendavad kuulavapoolse küsimuse kiiresti.
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-rida annab sertifikaadi ainult seal, kus miski sellel aadressil TLS-i lõpetab; tavapärase OpenVPN-i kuulaja vastu takerdub see või ebaõnnestub, ja see on iseenesest vastus sellele, mida väliskiht paljastab. journal-rida näitab igas backendis loetuna, milline eksemplar sessiooni vastu võttis. Frontendi logid kirjutavad üles, mida klassifitseeriti, ja mitte kunagi, mida kavatseti, seega jääb backend ainsaks autoriteediks selle kohta, kus kasutaja maandus.
Lõpeta kahe profiiliga, mis on mõeldud erinevatele serveritele jõudmiseks, ühenda need ükshaaval ja märgi igaühe kohta backend-logi. Kui mõlemad sessioonid ilmuvad samasse journalisse, siis valija puudub, mitte pole valesti seadistatud, ja parandus on aadress või port, millele klient saab sihtida. Marsruutimisreegli muutmine ei aita, sest reeglile ei antud kunagi midagi, mille peale marsruutida. Kui eraldus on tõeline, kirjuta see profiilide kõrvale, et järgmine inimene ei lisaks teist silti ja eeldaks, et see teeb töö ära.