Tvær A-færslur, eitt vistfang, einn djöfull: hvaða nafn sem notandi slær inn er pakkinn sem kemur óbreyttur, og ferlið sem er bundið við port 1194 hefur ekkert til að greina þau tvö. Þetta er ekki rangstillt uppsetning sem bíður viðgerðar; þetta er mörkin á því sem nafnuppfletting getur sagt. Allt sem velur milli tveggja OpenVPN-tilvika verður að vera gildi sem biðlarinn setur í tenginguna og framendinn getur lesið til baka, og venjulegur OpenVPN-biðlari setur ekkert slíkt gildi í opnu. Það sem fer á eftir er hvar þetta skilur þig eftir, og hvaða fyrirkomulag aðskilur umferðina í raun.

Byrjaðu á því sem uppflettirinn skilar

Biðlari biður um vpn-a.example og fær vistfang; það vistfang auk ports er allt sem hann hringir í. Nafnið er eytt á staðnum, meðan á uppflettingunni stendur, og verður aldrei svið á vírnum, þannig að hlustandinn hinum megin getur ekki séð hvaða merki var notað. Beindu vpn-a.example og vpn-b.example að sama hýsil og báðar uppflettingarnar gefa sama áfangastað, og þess vegna gleypir djöfullinn báðar tengingarnar í eitt tilvik án þess að skrá mun. Vistfangsbundin snið hegða sér nákvæmlega eins og nafnbundin, af sömu ástæðu.

Þetta lokar líka ætt af freistandi krókaleiðum: aukamerki, að velja skírteini fyrir hvert nafn á einni sökkul, eða eldveggjarregla sem er bundin við nafnið sem spurt var um. Ekkert þeirra getur unnið á upplýsingum sem þegar var hent áður en fyrsti pakkinn fór frá biðlaranum. Ef tveir þjónar verða að vera aðskildir, verður aðskilnaðurinn að ferðast með tengingunni sjálfri, sem þýðir vistfang, port eða burðarsvið sem samskiptareglan skilgreinir.

Eini valarinn sem telur fer inni í pakkanum

HTTP leysir þetta með Host-haus, og TLS með þjónanafnsviðbót í ClientHello, og þannig þjónar eitt vistfang mörgum vefjum bak við einn hlustanda. Bæði virka vegna þess að samskiptareglan á vírnum ber beiðni um tiltekna þjónustu. Mikilvæga staðreyndin um OpenVPN er að ekkert þessara sviða er til staðar á því lagi sem millibox skoðar.

Í venjulegu fyrirkomulagi á TLS-handaband sem verndar stjórnrásina sér stað eftir að ytra lotan er komin á og er flutt inni í henni, þannig að hlustandi sem hefur ekki lokið þeirri lotu sér ógegnsætt flæði. Hann getur samt sagt að þetta sé OpenVPN, því opkóði og rammagjörð í upphafsbtum eru þekkjanleg, en þjónanafnið, ef það er til, liggur í dulkóðaða hlutanum. Hönnun sem vonast til að lesa sýndarhýsil úr ytri pakkanum er að lesa svið sem samskiptareglan skrifar aldrei þangað. Það kemur frá því hvernig göngin eru byggð, ekki frá eyðu sem gáfaðri mynstursamsvörun gæti lokað.

Hvar samskiptaregluskiptir stöðvast

Fjölrás sem er af þeirri gerð sem sslh-verkefnið skjalfestir hlustar á einu porti, skoðar upphafsbtin og afhendir tenginguna þeim bakenda sem talar þá samskiptareglu sem hann þekkti. Það er raunverulegt gildi þegar eitt port þarf að þjóna SSH, HTTPS og OpenVPN saman.

sslh heldur sér rannsókn fyrir hverja samskiptareglu, og TLS-rannsókn þess getur dregið þjónanafn eða ALPN-gildi út úr ósviknum ClientHello. Að þekkja venjulegt OpenVPN er önnur flokkun en að lesa TLS-viðbót, og þau tvö samlagast ekki, því biðlari sem sendir aldrei ClientHello á hlustandi sökkulinn skilur rannsóknina eftir án nokkurs til að lesa. Þess vegna svarar regla sem passar við OpenVPN „þetta er OpenVPN-biðlari“ og fer ekki lengra. Tveir OpenVPN-bakendar bak við þá reglu eru ógreinanlegir, framendinn hefur engan grunn til vals, og hver lota lendir á sama stað. Fjölrásun deilir einu porti milli ólíkra þjónustna; hún stundar ekki sýndarhýsingu innan einnar þjónustu.

Fyrirkomulag sem aðskilur tvo þjóna í raun

Ódýrasti heiðarlega aðskilnaðurinn er annað opinbert vistfang, eitt fyrir hvert tilvik, og fyrirliggjandi snið bera þegar það sem þarf því þau vísa á ólík vistföng. Næsta er annað port á sama vistfangi, sem kostar ekkert nema eina tölu í hverju sniði. TCP og UDP halda aðskildum porttöflum, svo 1194/tcp og 1194/udp eru óskyldir sökkular og eitt af hvoru getur verið á sama hýsli; það er flutningsaðskilnaður en ekki nafnaleiðsla, og það er oft ruglað saman við hana. Báðir valmöguleikar standast eldveggjarskoðun, því reglan passar við eitthvað sem pakkinn inniheldur í raun.

Ef mörkin sem þú þarft liggja milli notendahópa í staðinn fyrir milli tveggja útfærslna, getur eitt tilvik með ólíkum biðlarastillingum, eigin skírteinismeðferð og skýrri aðgangsstefnu ná yfir það. Það sem það kaupir er stefna innan þjóns, ekki einangrun milli þjóna, og það eru ólíkar kröfur. Einangrun sem verður að halda undir árás þarf enn vistfangið eða eldveggjarbrúnina.

TLS-endir sem er settur fyrir framan OpenVPN getur afhjúpað raunverulegt þjónanafn fyrir hæfum framenda, en aðeins þegar biðlarahliðin er líka stillt fyrir það aukalag. Fyrirliggjandi snið öðlast ekki þessa hegðun með því að vísa á sama vistfang.

Sannaðu valarann áður en þú byggir

Nefndu sviðið sem mun auðkenna bakenda, staðfestu síðan að biðlarinn sendi það í raun; ef svarið er vistfang stendur áætlunin, og ef það er þjónanafn inni í handabandi sem nær aldrei til hlustandans mun ekkert DNS-starfsbjarga því. Þrjár skipanir leysa hlustandahliðina fljótt.

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-línan gefur aðeins skírteini þar sem eitthvað á því vistfangi endar TLS; gegn venjulegum OpenVPN-hlustanda stöðvast hún eða mistekst, og það er sjálft svarið um hvað ytra lagið afhjúpar. journal-línan, lesin á hverjum bakenda, sýnir hvaða tilvik tók lotuna. Framendaskrár skrá það sem var flokkað og aldrei það sem stóð til, svo bakendinn er áfram eina heimildin um hvar notandi lenti.

Endaðu með tveimur sniðum sem eiga að ná til ólíkra þjóna, tengdu þau eitt í einu og skráðu bakendaskrána fyrir hvort. Ef báðar loturnar birtast í sama journal vantar valarann frekar en að hann sé rangstilltur, og lagfæringin er vistfang eða port sem biðlarinn getur miðað á. Að breyta leiðarreglunni mun ekki hjálpa, því reglan fékk aldrei neitt til að leiða á. Þegar aðskilnaðurinn er raunverulegur skaltu skrifa hann við hlið sniðanna svo næsta manneskja bæti ekki við öðru aukamerki og búist við að það vinni verkið.

Tengdir greinar