Du A-rikordoj, unu adreso, unu demono: kiun ajn nomon uzanto tajpas, la alvenanta pako estas identa, kaj la procezo ligita al pordo 1194 havas nenion por distingi ilin. Tio ne estas misagordo atendanta riparon; ĝi estas la limo de tio, kion nom-serĉo povas esprimi. Ĉio, kio elektas inter du OpenVPN-okazoj, devas esti valoro, kiun la kliento metas en la konekton kaj kiun la fasado povas relegi, kaj ordinara OpenVPN-kliento metas neniun tian valoron malkaŝe. Tio, kio sekvas, estas kien tio kondukas vin, kaj kiuj aranĝoj vere dividas la trafikon.

Komencu per tio, kion la solvilo redonas

Kliento petas vpn-a.example kaj ricevas adreson; tiu adreso plus pordo estas ĉio, kion ĝi alvokas. La nomo elspeziĝas loke, dum la serĉo, kaj ĝi neniam fariĝas kampo sur la drato, do la aŭskultanto ĉe la alia fino ne povas vidi, kiu etikedo estis uzita. Direktu vpn-a.example kaj vpn-b.example al unu gastiganto, kaj ambaŭ serĉoj donos la saman celon, kaj tial la demono ensorbas ambaŭ konektojn en unu okazon sen registri diferencon. Adres-bazitaj profiloj kondutas ekzakte kiel nom-bazitaj, pro la sama kialo.

Tio ankaŭ fermas familion de tentaj flankaj solvoj: pliaj aliasoj, elektado de atestilo por nomo ĉe unu ingo, aŭ fajroŝirma regulo ligita al la demandita nomo. Neniu el ili povas agi laŭ informo jam forĵetita antaŭ ol la unua pako lasis la klienton. Se du serviloj devas resti apartaj, la divido devas vojaĝi kun la konekto mem, tio estas adreso, pordo aŭ utilŝarĝa kampo, kiun la protokolo difinas.

La sola elektilo, kiu gravas, veturas ene de la pako

HTTP solvas tion per kaplinio Host, kaj TLS per servila-noma etendo en ClientHello, kaj tiel unu adreso servas multajn retejojn malantaŭ unu aŭskultanto. Ambaŭ funkcias ĉar la drata protokolo portas peton pri specifa servo. La grava fakto pri OpenVPN estas, ke neniu el tiuj kampoj ĉeestas en la tavolo, kiun meza skatolo inspektas.

En norma aranĝo la TLS-manpremo, kiu protektas la regan kanalon, okazas post kiam la ekstera sesio estas starigita kaj estas portata ene de ĝi, do aŭskultanto, kiu ne finis tiun sesion, vidas netravideblan fluon. Ĝi ankoraŭ povas rekoni, ke temas pri OpenVPN, ĉar la opkodo kaj kadrigo en la unuaj bajtoj estas rekoneblaj, sed la servila nomo, se ĝi ekzistas, sidas en la ĉifrita parto. Dezajno, kiu atendas legi virtualan gastiganton el la ekstera pako, legas kampon, kiun la protokolo neniam skribas tien. Tio devenas de tio, kiel la tunelo estas konstruita, ne de manko, kiun pli lerta ŝablon-adapto povus fermi.

Kie protokola disigilo haltas

Multpleksilo de la speco, kiun dokumentas la projekto sslh, aŭskultas ĉe unu pordo, inspektas la unuajn bajtojn kaj transdonas la konekton al tiu backend, kiu parolas la rekonitan protokolon. Tio estas reala valoro, kiam unu pordo devas servi SSH, HTTPS kaj OpenVPN kune.

sslh tenas apartan sondilon por ĉiu protokolo, kaj ĝia TLS-sondilo povas eltiri servilan nomon aŭ ALPN-valoron el vera ClientHello. Rekoni norman OpenVPN estas alia klasifiko ol legi TLS-etendon, kaj la du ne kunmetiĝas, ĉar kliento, kiu neniam sendas ClientHello al la aŭskultanta ingo, lasas la sondilon sen io legebla. Regulo kongruanta kun OpenVPN tial respondas “ĉi tio estas OpenVPN-kliento” kaj ne iras plu. Du OpenVPN-backend malantaŭ tiu regulo estas nedistingeblaj, la fasado havas neniun bazon por elekto, kaj ĉiu sesio surteriĝas en la sama loko. Multpleksado dividas unu pordon inter malsamaj servoj; ĝi ne faras virtualan gastigadon ene de unu servo.

Aranĝoj, kiuj vere apartigas du servilojn

La plej malmultekosta honesta divido estas dua publika adreso, unu por okazo, kaj ekzistantaj profiloj jam portas tion, kio necesas, ĉar ili montras al malsamaj adresoj. La sekva estas alia pordo sur la sama adreso, kio kostas nenion krom nombro en ĉiu profilo. TCP kaj UDP tenas apartajn pordajn tabelojn, do 1194/tcp kaj 1194/udp estas nerilataj ingoj kaj po unu el ĉiu povas kunekzisti en unu gastiganto; tio estas transporta apartigo, ne nom-bazita enkursigado, kaj oni ofte konfuzas ĝin kun tio. Ambaŭ opcioj eltenas fajroŝirman revizion, ĉar la regulo kongruas kun io, kion la pako fakte enhavas.

Se la limo, kiun vi bezonas, iras inter grupoj de uzantoj anstataŭ inter du realigoj, unu okazo kun malsamaj klientaj agordoj, propra atestila traktado kaj klara alirpolitiko povas kovri ĝin. Tio aĉetas politikon ene de servilo, ne izolon inter serviloj, kaj tiuj estas malsamaj postuloj. Izolo, kiu devas teniĝi sub kompromito, ankoraŭ bezonas la adreson aŭ la fajroŝirman randon.

TLS-finilo metita antaŭ OpenVPN povas elmeti veran servilan nomon al kapabla fasado, sed nur kiam ankaŭ la klienta flanko estas agordita por tiu plia tavolo. Ekzistantaj profiloj ne akiras la konduton per tio, ke oni direktas ilin al la sama adreso.

Pruvu la elektilon antaŭ ol konstrui

Nomu la kampon, kiu identigos backend, poste konfirmu, ke la kliento fakte sendas ĝin; se la respondo estas adreso, la plano teniĝas, kaj se temas pri servila nomo ene de manpremo, kiu neniam atingas la aŭskultanton, nenia kvanto da DNS-laboro savos ĝin. Tri komandoj rapide solvas la aŭskultantan flankon.

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

La linio openssl donas atestilon nur tie, kie io ĉe tiu adreso finas TLS; kontraŭ norma OpenVPN-aŭskultanto ĝi haltas aŭ malsukcesas, kaj tio mem estas la respondo pri tio, kion elmetas la ekstera tavolo. La linio journal, legita ĉe ĉiu backend, montras, kiu okazo akceptis la sesion. Fasado-protokoloj registras tion, kio estis klasifikita, kaj neniam tion, kio estis intencita, do la backend restas la sola aŭtoritato pri tio, kie uzanto surteriĝis.

Finu per du profiloj celantaj malsamajn servilojn, konektu ilin unu post la alia, kaj notu la backend-protokolon por ĉiu. Se ambaŭ sesioj aperas en la sama ĵurnalo, la elektilo mankas anstataŭ esti misagordita, kaj la ripari estas adreso aŭ pordo, kiun la kliento povas celi. Redakti la enkursigan regulon ne helpos, ĉar al la regulo neniam estis donita io por enkursigi. Foje la divido estas reala, skribu ĝin apud la profiloj, por ke la sekva persono ne aldonu duan aliason kaj atendu, ke ĝi faros la laboron.

Rilataj artikoloj