Du DNS vardai, vienas OpenVPN prievadas: kas iš tikrųjų parenka

Du A įrašai, vienas adresas, vienas demonas: kokį vardą įvestų naudotojas, atvykstanti paketas yra identiškas, o prie 1194 prievado pririštas procesas neturi kuo atskirti abiejų. Tai ne laukianti taisymo klaidinga konfigūracija; tai riba, ką gali išreikšti vardo paieška. Viskas, kas pasirenka tarp dviejų OpenVPN egzempliorių, turi būti reikšmė, kurią klientas įdeda į ryšį ir kurią priekinė dalis gali perskaityti atgal, o įprastas OpenVPN klientas tokios reikšmės atvirai neįdeda. Toliau – kur tai veda ir kokios sąrangos tikrai atskiria srautą.

Pradėkite nuo to, ką grąžina sprendiklis

Klientas paklausia vpn-a.example ir gauna adresą; šis adresas plius prievadas yra viskas, ką jis sujungia. Vardas išnaudojamas vietiškai, paieškos metu, ir niekada netampa lauku laidu, todėl klausytojas kitame gale negali matyti, kokia žymė panaudota. Nukreipkite vpn-a.example ir vpn-b.example į tą patį kompiuterį, ir abi paieškos duos tą pačią paskirtį, todėl demonas abu ryšius sugeria į vieną egzempliorių neužregistruodamas skirtumo. Adresu pagrįsti profiliai elgiasi lygiai taip pat kaip vardu pagrįsti, dėl tos pačios priežasties.

Tai taip pat uždaro viliojančių apėjimo būdų šeimą: papildomi slapyvardžiai, sertifikato parinkimas kiekvienam vardui viename lizde arba ugniasienės taisyklė, susieta su užklaustu vardu. Nė vienas iš jų negali veikti informacija, kuri jau buvo išmesta prieš pirmajam paketui paliekant klientą. Jei du serveriai turi likti atskiri, atskyrimas turi keliauti kartu su pačiu ryšiu, tai reiškia adresą, prievadą arba naudingosios apkrovos lauką, kurį apibrėžia protokolas.

Vienintelis skaičiuojamas parinkiklis keliauja paketo viduje

HTTP tai sprendžia Host antrašte, o TLS – serverio vardo plėtiniu ClientHello, ir taip vienas adresas aptarnauja daug svetainių už vieno klausytojo. Abu veikia todėl, kad laido protokolas neša konkrečios paslaugos užklausą. Svarbus faktas apie OpenVPN yra tas, kad nė vieno iš šių laukų nėra sluoksnyje, kurį tikrina tarpinė dėžė.

Įprastoje sąrangoje valdymo kanalą saugantis TLS rankos paspaudimas įvyksta po to, kai nustatoma išorinė sesija, ir yra pernešamas jos viduje, todėl klausytojas, kuris tos sesijos neužbaigė, mato nepermatomą srautą. Jis vis tiek gali pasakyti, kad tai OpenVPN, nes pradinių baitų opkodas ir kadravimas yra atpažįstami, bet serverio vardas, jei toks yra, yra užšifruotoje dalyje. Dizainas, kuris tikisi perskaityti virtualų prieglobą iš išorinio paketo, skaito lauką, kurio protokolas ten niekada nerašo. Tai kyla iš to, kaip pastatytas tunelis, o ne iš spragos, kurią galėtų uždaryti gudresnis šablono atitikimas.

Kur protokolo skirstytuvas sustoja

Tipo multiplekseris, kurį dokumentuoja sslh projektas, klausosi viename prievade, apžiūri pradinius baitus ir perduoda ryšį tam backend, kuris kalba atpažintu protokolu. Tai tikra vertė, kai vienas prievadas turi aptarnauti SSH, HTTPS ir OpenVPN kartu.

sslh laiko atskirą zondą kiekvienam protokolui, o jo TLS zondas gali iš tikro ClientHello ištraukti serverio vardą arba ALPN reikšmę. Atpažinti standartinį OpenVPN yra kita klasifikacija nei skaityti TLS plėtinį, ir abu nesijungia, nes klientas, kuris niekada nesiunčia ClientHello į klausantį lizdą, palieka zondą be nieko skaityti. Todėl taisyklė, atitinkanti OpenVPN, atsako „tai OpenVPN klientas“ ir neina toliau. Du OpenVPN backend už tos taisyklės yra neatskiriami, priekinė dalis neturi pagrindo pasirinkti, ir kiekviena sesija nusileidžia toje pačioje vietoje. Multipleksavimas dalijasi vienu prievadu tarp skirtingų paslaugų; jis neatlieka virtualaus prieglobos vienoje paslaugoje.

Sąrangos, kurios tikrai atskiria du serverius

Pigiausias sąžiningas atskyrimas yra antras viešas adresas, po vieną egzemplioriui, o esami profiliai jau neša tai, ko reikia, nes rodo į skirtingus adresus. Kitas – kitas prievadas tame pačiame adrese, o tai nekainuoja nieko, išskyrus skaičių kiekviename profilyje. TCP ir UDP laiko atskiras prievadų lenteles, todėl 1194/tcp ir 1194/udp yra nesusiję lizdai ir po vieną iš kiekvieno gali egzistuoti tame pačiame kompiuteryje; tai transporto atskyrimas, o ne maršrutizavimas pagal vardą, ir dažnai su juo painiojamas. Abu variantai atlaiko ugniasienės peržiūrą, nes taisyklė atitinka tai, ką paketas tikrai turi.

Jei reikalinga riba eina tarp naudotojų grupių, o ne tarp dviejų implementacijų, ją gali uždengti vienas egzempliorius su skirtingomis kliento konfigūracijomis, savo sertifikatų tvarkymu ir aiškia prieigos politika. Tai perka politiką serverio viduje, o ne izoliaciją tarp serverių, ir tai yra skirtingi reikalavimai. Izoliacija, kuri turi atlaikyti kompromitavimą, vis dar reikalauja adreso arba ugniasienės krašto.

Prieš OpenVPN pastatytas TLS užbaigėjas gali atskleisti tikrą serverio vardą pajėgiai priekinei daliai, bet tik tada, kai kliento pusė taip pat sukonfigūruota tam papildomam sluoksniui. Esami profiliai neįgyja šio elgesio vien nukreipus juos į tą patį adresą.

Įrodykite parinkiklį prieš statydami

Įvardykite lauką, kuris identifikuos backend, tada patvirtinkite, kad klientas jį tikrai siunčia; jei atsakymas yra adresas, planas laikosi, o jei tai serverio vardas rankos paspaudimo viduje, kuris niekada nepasiekia klausytojo, joks DNS darbas neišgelbės. Trys komandos greitai išsprendžia klausymo pusę.

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 eilutė duoda sertifikatą tik ten, kur kažkas tame adrese užbaigia TLS; prieš standartinį OpenVPN klausytoją ji užstringa arba nepavyksta, ir tai pats savaime yra atsakymas, ką atskleidžia išorinis sluoksnis. journal eilutė, perskaityta kiekviename backend, parodo, kuris egzempliorius priėmė sesiją. Priekinės dalies žurnalai fiksuoja, kas buvo klasifikuota, ir niekada to, kas buvo numatyta, todėl backend lieka vienintelė institucija, žinanti, kur naudotojas nusileido.

Užbaikite dviem profiliais, skirtai pasiekti skirtingus serverius, prijunkite juos po vieną ir užsirašykite kiekvieno backend žurnalą. Jei abi sesijos atsiranda tame pačiame žurnale, parinkiklio trūksta, o ne jis neteisingai sukonfigūruotas, ir pataisa yra adresas arba prievadas, į kurį klientas gali taikytis. Maršrutizavimo taisyklės redagavimas nepadės, nes taisyklei niekada nebuvo duota nieko, pagal ką maršrutizuoti. Kai atskyrimas taps tikras, užrašykite jį šalia profilių, kad kitas žmogus nepridėtų antro slapyvardžio ir nesitikėtų, kad jis atliks darbą.