Dy emra DNS, një port OpenVPN: çfarë zgjedh në të vërtetë

Dy regjistra A, një adresë, një demon: çfarëdo emri që shtyp përdoruesi, paketa që arrin është identike, dhe procesi i lidhur me portën 1194 nuk ka asgjë për të dalluar të dyja. Kjo nuk është një konfigurim i gabuar që pret riparim; është kufiri i asaj që mund të shprehë një kërkim emri. Çdo gjë që zgjedh midis dy instancave të OpenVPN duhet të jetë një vlerë që klienti e vendos në lidhje dhe që pjesa e përparme mund ta rilexojë, dhe një klient standard OpenVPN nuk vendos një vlerë të tillë hapur. Ajo që vijon është ku ju lë kjo, dhe cilat rregullime vërtet e ndajnë trafikun.

Filloni me atë që kthen zgjidhësi

Një klient kërkon vpn-a.example dhe merr një adresë; ajo adresë plus një portë është gjithçka që ai thërret. Emri harxhohet lokalisht, gjatë kërkimit, dhe nuk bëhet kurrë fushë në tel, prandaj dëgjuesi në anën tjetër nuk mund të shohë cila etiketë u përdor. Drejtoni vpn-a.example dhe vpn-b.example drejt të njëjtit pritës dhe të dy kërkimet japin të njëjtin destinacion, prandaj demoni i thith të dyja lidhjet në një instancë pa regjistruar një ndryshim. Profilet e bazuara në adresë sillen saktësisht si ato të bazuara në emër, për të njëjtën arsye.

Kjo mbyll gjithashtu një familje zgjidhjesh tunduese: pseudonime shtesë, zgjedhja e një certifikate për çdo emër në një prizë të vetme, ose një rregull muri zjarri i lidhur me emrin e kërkuar. Asnjëra prej tyre nuk mund të veprojë mbi informacion që ishte hedhur tashmë poshtë përpara se paketa e parë të linte klientin. Nëse dy serverë duhet të mbeten të ndarë, ndarja duhet të udhëtojë me vetë lidhjen, domethënë një adresë, një portë ose një fushë ngarkese që e përcakton protokolli.

Zgjedhësi i vetëm që llogaritet udhëton brenda paketës

HTTP e zgjidh këtë me një krye Host, dhe TLS me një zgjerim emri serveri në ClientHello, dhe kështu një adresë i shërben shumë sajteve pas një dëgjuesi të vetëm. Të dyja funksionojnë sepse protokolli në tel mbart një kërkesë për një shërbim të caktuar. Fakti relevant për OpenVPN është se asnjëra prej këtyre fushave nuk është e pranishme në shtresën që inspekton një kuti e ndërmjetme.

Në një rregullim standard, shtrëngimi i duarve TLS që mbron kanalin e kontrollit ndodh pasi sesioni i jashtëm është vendosur dhe transportohet brenda tij, prandaj një dëgjues që nuk e ka përfunduar atë sesion sheh një rrjedhë të errët. Ai ende mund të thotë se kjo është OpenVPN, sepse opkodi dhe kornizimi në bajtët e parë janë të dallueshëm, por emri i serverit, nëse ekziston, qëndron në pjesën e kriptuar. Një dizajn që pret të lexojë një pritës virtual nga paketa e jashtme po lexon një fushë që protokolli nuk e shkruan kurrë atje. Kjo vjen nga mënyra se si është ndërtuar tuneli, jo nga një boshllëk që një përputhje modeli më e zgjuar mund të mbyllte.

Ku ndalon një ndarës protokollesh

Një multipleksues i asaj lloji që dokumenton projekti sslh dëgjon në një portë të vetme, inspekton bajtët e parë dhe ia dorëzon lidhjen atij backend që flet protokollin e njohur. Kjo është vlerë e vërtetë kur një portë e vetme duhet t'u shërbejë SSH, HTTPS dhe OpenVPN së bashku.

sslh mban një sondë të veçantë për çdo protokoll, dhe sonda e tij TLS mund të nxjerrë një emër serveri ose një vlerë ALPN nga një ClientHello i vërtetë. Njohja e OpenVPN-it origjinal është një klasifikim tjetër nga leximi i një zgjerimi TLS, dhe të dyja nuk kombinohen, sepse një klient që nuk dërgon kurrë ClientHello te priza dëgjuese e lë sondën pa asgjë për të lexuar. Prandaj një rregull që përputhet me OpenVPN përgjigjet «ky është një klient OpenVPN» dhe nuk shkon më tej. Dy backend-e OpenVPN pas atij rregulli janë të padallueshëm, pjesa e përparme nuk ka asnjë bazë për zgjedhje, dhe çdo sesion zbret në të njëjtin vend. Multipleksimi ndan një portë midis shërbimeve të ndryshme; ai nuk bën hosting virtual brenda një shërbimi.

Rregullime që vërtet ndajnë dy serverë

Ndarja e ndershme më e lirë është një adresë e dytë publike, një për instancë, dhe profilet ekzistuese tashmë mbartin atë që duhet sepse tregojnë adresa të ndryshme. Tjetra është një portë tjetër në të njëjtën adresë, që nuk kushton asgjë përveç një numri në çdo profil. TCP dhe UDP mbajnë tabela të veçanta portash, kështu që 1194/tcp dhe 1194/udp janë priza të palidhura dhe nga një prej secilës mund të bashkëjetojë në të njëjtin pritës; ky është ndarje transporti dhe jo rrugëtim sipas emrit, dhe shpesh ngatërrohet me të. Të dyja opsionet i mbijetojnë një rishikimi të murit të zjarrit, sepse rregulli përputhet me diçka që paketa vërtet përmban.

Nëse kufiri që ju nevojitet kalon midis grupeve të përdoruesve dhe jo midis dy zbatimeve, një instancë me konfigurime të ndryshme klienti, menaxhimin e vet të certifikatave dhe një politikë të qartë aksesi mund ta mbulojë atë. Ajo që blen është politikë brenda një serveri, jo izolim midis serverëve, dhe këto janë kërkesa të ndryshme. Izolimi që duhet të qëndrojë nën kompromis ende ka nevojë për adresën ose skajin e murit të zjarrit.

Një përfundues TLS i vendosur përpara OpenVPN mund t'i ekspozojë një emër serveri të vërtetë një pjese të përparme të aftë, por vetëm kur edhe ana e klientit është konfiguruar për atë shtresë shtesë. Profilet ekzistuese nuk e fitojnë këtë sjellje thjesht duke u drejtuar drejt të njëjtës adresë.

Vërtetoni zgjedhësin përpara se të ndërtoni

Emërtoni fushën që do të identifikojë një backend, pastaj konfirmoni se klienti vërtet e dërgon atë; nëse përgjigjja është një adresë, plani qëndron, dhe nëse është një emër serveri brenda një shtrëngimi duarsh që nuk arrin kurrë te dëgjuesi, asnjë punë DNS nuk do ta shpëtojë. Tre komanda e zgjidhin shpejt anën dëgjuese.

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

Rreshti openssl jep një certifikatë vetëm atje ku diçka në atë adresë përfundon TLS; kundër një dëgjuesi origjinal OpenVPN ai ngec ose dështon, dhe kjo është në vetvete përgjigjja për atë që ekspozon shtresa e jashtme. Rreshti journal, i lexuar në çdo backend, tregon cila instancë e pranoi sesionin. Regjistrat e pjesës së përparme shënojnë atë që u klasifikua dhe asnjëherë atë që synohej, prandaj backend-i mbetet autoriteti i vetëm për vendin ku zbriti përdoruesi.

Përfundoni me dy profile të menduara për të arritur serverë të ndryshëm, lidhini një nga një dhe shënoni regjistrin e backend-it për secilin. Nëse të dy sesionet shfaqen në të njëjtin journal, zgjedhësi mungon dhe nuk është konfiguruar gabimisht, dhe rregullimi është një adresë ose portë që klienti mund të synojë. Redaktimi i rregullit të rrugëtimit nuk do të ndihmojë, sepse rregullit nuk iu dha kurrë diçka mbi të cilën të rrugëtojë. Pasi ndarja të bëhet e vërtetë, shkruajeni pranë profileve, që personi tjetër të mos shtojë një pseudonim të dytë dhe të presë që ai ta bëjë punën.