Majina mawili ya DNS, lango moja la OpenVPN: ni nini huchagua kwa kweli

Rekodi mbili za A, anwani moja, daemon mmoja: jina lolote ambalo mtumiaji ataandika, pakiti inayowasili ni sawa, na mchakato uliofungwa kwenye lango 1194 hauna kitu cha kutofautisha hayo mawili. Hii si usanidi mbaya unaosubiri kutengenezwa; hii ni kikomo cha kile ambacho utafutaji wa jina unaweza kueleza. Kitu chochote kinachochagua kati ya nakala mbili za OpenVPN lazima kiwe thamani ambayo mteja anaiweka kwenye muunganisho na ambayo upande wa mbele unaweza kuisoma tena, na mteja wa kawaida wa OpenVPN haweki thamani kama hiyo wazi. Kinachofuata ni mahali ambapo hilo linakuacha, na mipangilio ipi hasa inayotenganisha trafiki.

Anza na kile kitatuzi kinachorudisha

Mteja anauliza vpn-a.example na anapata anwani; anwani hiyo pamoja na lango ndiyo kila kitu anachopiga. Jina hutumika ndani, wakati wa utafutaji, na haliwi sehemu kwenye waya, kwa hiyo msikilizaji upande wa pili hawezi kuona lebo ipi ilitumika. Elekeza vpn-a.example na vpn-b.example kwenye mwenyeji mmoja na utafutaji wote wawili hutoa lengo lile lile, ndiyo sababu daemon hunyonya muunganisho wote wawili katika nakala moja bila kurekodi tofauti. Profaili zinazotegemea anwani hujiendesha kama zile zinazotegemea jina, kwa sababu hiyo hiyo.

Hii pia hufunga familia ya njia mbadala zenye kuvutia: majina ya ziada, kuchagua cheti kwa kila jina kwenye soketi moja, au kanuni ya ukuta wa moto inayohusishwa na jina lililoulizwa. Hakuna kati yao inayoweza kufanya kazi kwa taarifa ambayo ilikuwa imetupwa tayari kabla ya pakiti ya kwanza kuondoka kwa mteja. Ikiwa seva mbili lazima zibaki tofauti, mgawanyiko lazima usafiri pamoja na muunganisho wenyewe, yaani anwani, lango, au sehemu ya mzigo ambayo itifaki inaifafanua.

Kichaguzi pekee kinachohesabiwa husafiri ndani ya pakiti

HTTP hushughulikia hili kwa kichwa cha Host, na TLS kwa kiendelezi cha jina la seva katika ClientHello, na hivyo anwani moja huhudumia tovuti nyingi nyuma ya msikilizaji mmoja. Zote mbili hufanya kazi kwa sababu itifaki ya waya hubeba ombi la huduma maalum. Ukweli muhimu kuhusu OpenVPN ni kwamba hakuna sehemu yoyote kati ya hizo iliyopo kwenye tabaka ambalo sanduku la kati huchunguza.

Katika mpangilio wa kawaida, salamu ya mkono ya TLS inayolinda kituo cha udhibiti hufanyika baada ya kikao cha nje kuanzishwa na husafirishwa ndani yake, kwa hiyo msikilizaji ambaye hakumaliza kikao hicho huona mtiririko usio wazi. Bado anaweza kusema hii ni OpenVPN, kwa sababu opcode na uwekaji fremu katika baiti za mwanzo zinatambulika, lakini jina la seva, ikiwa lipo, limekaa katika sehemu iliyosimbwa. Ubunifu unaotarajia kusoma mwenyeji pepe kutoka pakiti ya nje unasoma sehemu ambayo itifaki haiandiki hapo kamwe. Hilo linatokana na jinsi handaki ilivyojengwa, si kutokana na pengo ambalo ulinganishaji wa mifumo wenye werevu zaidi ungeweza kufunga.

Mahali mgawanyaji wa itifaki huishia

Kizalishi cha aina ambayo mradi wa sslh huandika hukaa kwenye lango moja, huchunguza baiti za mwanzo, na hukabidhi muunganisho kwa backend yoyote inayozungumza itifaki iliyotambuliwa. Hiyo ni thamani halisi wakati lango moja linapaswa kuhudumia SSH, HTTPS na OpenVPN pamoja.

sslh huweka uchunguzi tofauti kwa kila itifaki, na uchunguzi wake wa TLS unaweza kutoa jina la seva au thamani ya ALPN kutoka ClientHello halisi. Kutambua OpenVPN asili ni uainishaji tofauti na kusoma kiendelezi cha TLS, na hizo mbili haziungani, kwa sababu mteja asiyetuma ClientHello kwenye soketi ya kusikiliza huacha uchunguzi bila kitu cha kusoma. Hivyo kanuni inayolingana na OpenVPN hujibu “huyu ni mteja wa OpenVPN” na haiendi mbele. Backend mbili za OpenVPN nyuma ya kanuni hiyo haziwezi kutofautishwa, upande wa mbele hauna msingi wa kuchagua, na kila kikao hutua mahali pamoja. Uzalishaji-nyingi hugawanya lango moja kati ya huduma tofauti; haufanyi upangishaji pepe ndani ya huduma moja.

Mipangilio inayotenganisha seva mbili kwa kweli

Mgawanyiko wa uaminifu wa bei nafuu ni anwani ya pili ya umma, moja kwa kila nakala, na profaili zilizopo tayari hubeba kinachohitajika kwa sababu zinaelekea anwani tofauti. Inayofuata ni lango tofauti kwenye anwani ile ile, ambayo haigharimu chochote isipokuwa namba katika kila profaili. TCP na UDP huweka majedwali ya lango tofauti, kwa hiyo 1194/tcp na 1194/udp ni soketi zisizohusiana na moja kutoka kila moja inaweza kuwepo kwenye mwenyeji mmoja; huo ni mgawanyiko wa usafirishaji na si uelekezaji wa jina, na mara nyingi huchanganywa nao. Chaguo zote mbili zinastahimili ukaguzi wa ukuta wa moto, kwa sababu kanuni inalingana na kitu ambacho pakiti ina kweli.

Ikiwa mpaka unaouhitaji unapita kati ya makundi ya watumiaji badala ya kati ya utekelezaji mbili, nakala moja yenye usanidi tofauti wa mteja, usimamizi wake wa vyeti na sera ya ufikiaji iliyo wazi inaweza kuifunika. Kinachonunuliwa ni sera ndani ya seva, si kutengwa kati ya seva, na hayo ni mahitaji tofauti. Kutengwa ambako lazima kudumu chini ya uvunjaji bado kunahitaji anwani au ukingo wa ukuta wa moto.

Kimaliza TLS kilichowekwa mbele ya OpenVPN kinaweza kufichua jina halisi la seva kwa upande wa mbele wenye uwezo, lakini tu wakati upande wa mteja pia umesanidiwa kwa tabaka hilo la ziada. Profaili zilizopo hazipati tabia hiyo kwa kuelekezwa kwenye anwani ile ile.

Thibitisha kichaguzi kabla ya kujenga

Taja sehemu itakayotambua backend, kisha thibitisha kwamba mteja anaituma kweli; ikiwa jibu ni anwani mpango unashikilia, na ikiwa ni jina la seva ndani ya salamu ya mkono ambayo haifikii msikilizaji kamwe, hakuna kazi ya DNS itakayoiokoa. Amri tatu huamua upande wa kusikiliza haraka.

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

Mstari wa openssl hutoa cheti tu pale ambapo kitu kwenye anwani hiyo kinamaliza TLS; dhidi ya msikilizaji wa OpenVPN asili hukwama au hushindwa, na hiyo yenyewe ni jibu la kile tabaka la nje linafichua. Mstari wa journal, ukisomwa kwenye kila backend, unaonyesha ni nakala ipi ilikubali kikao. Kumbukumbu za upande wa mbele zinaandika kile kilichoainishwa na kamwe kile kilichokusudiwa, kwa hiyo backend inabaki kuwa mamlaka pekee kuhusu mahali mtumiaji alipotua.

Maliza na profaili mbili zilizokusudiwa kufikia seva tofauti, ziunganishe moja baada ya nyingine na uandike kumbukumbu ya backend kwa kila moja. Ikiwa vikao vyote viwili vinaonekana kwenye journal moja, kichaguzi hakipo na si kimesanidiwa vibaya, na suluhisho ni anwani au lango ambalo mteja anaweza kulenga. Kuhariri kanuni ya uelekezaji hakutasaidia, kwa sababu kanuni haikupewa kitu cha kuelekeza. Mara mgawanyiko ukiwa halisi, iandike kando ya profaili ili mtu anayefuata asiongeze jina la pili na kutarajia lifanye kazi hiyo.