Profaili iliyofungwa kwa seva inashindwa nyuma ya proksi ya TLS: kizazi kipi?

Mtumiaji mmoja anaweza kuunganisha na mwingine hawezi, kupitia lango lilo hilo, siku hiyo hiyo. Wote wana profaili zilizofungwa kwa seva, wote wako kwenye build moja ya Access Server, na tofauti pekee ni lini profaili yao ilizalishwa. Hiyo ndiyo muundo unaostahili kutambuliwa, kwa sababu "imefungwa kwa seva" inataja sera na si mfululizo wa muunganisho. Access Server imetoa vizazi viwili vya kitu hicho, na proksi ya kinyume ya TLS inasimama mbele ya moja tu ya njia zao. Masharti matatu huamua uko kwenye tawi gani.

Vizazi viwili, mifuatano miwili ya muunganisho

Katika muundo wa zamani, unaotumika hadi 2.8, faili iliyoingizwa ni profaili bandia. OpenVPN Connect hutumia kujithibitisha kwa API ya wavuti ya Access Server kupitia HTTPS, hupokea profaili ya muda iliyofungwa kwa mtumiaji na tokeni ya kikao, na kisha tu huanzisha VPN. Usafirishaji mbili hufanya kazi kwa mfuatano, na ya kwanza ni ombi la kawaida la wavuti.

Muundo ulioanzishwa na 2.9 haufanyi uanzishaji huo kwa kila muunganisho. Ni profaili asilia inayoweza kutumiwa na OpenVPN wateja wanaolingana, si OpenVPN Connect pekee. Kuipakua au kuiingiza kupitia URL bado kunaweza kuhusisha HTTPS — hiyo ni hatua ya uchapishaji, si upataji wa profaili ya muda kwa kila muunganisho.

Uboreshaji hauwezi kuandika upya profaili zilizotolewa tayari, kwa hivyo toleo la sasa la seva linaweza bado kusambaza kitu cha zamani. Build ya seva inakuambia kinachowezekana, si kile mtumiaji huyu aliingiza.

Masharti matatu yanayochagua tawi lako

Sharti la kwanza ni kizazi cha kitu. Omba faili, angalia jinsi ilivyozalishwa, na andika toleo la mteja lililoiingiza. Ikiwa huwezi kubainisha kizazi kutoka kwenye faili, profaili mpya iliyotolewa kwa akaunti ya majaribio itakuambia seva inazalisha nini leo, na hiyo ni taarifa tofauti na ile aliyo nayo mtumiaji anayeshindwa.

Sharti la pili ni kile mbele yako inamaliza kwa kweli. Proksi ya kinyume ya HTTP ya tabaka la saba inayoshusha TLS si kitu kimoja na kipitishaji cha TCP cha tabaka la nne, na kipitishaji cha UDP pia si hivyo. Mpangilio wa kawaida wa Access Server kwenye bandari 443 hufanya daemon ya OpenVPN TCP itambue trafiki ya kivinjari na kuikabidhi kwa huduma za wavuti, kwa hivyo kuweka kimaliza HTTPS kisichohusiana mbele hakutunzi ushughulikiaji wa itifaki wa daemon huyo. Kushiriki namba 443 hakufanyi miundo miwili kuwa sawa.

Sharti la tatu ni mahali kushindwa kunatua. Kushindwa kabla ya VPN na kushindwa kwa kituo cha udhibiti huonekana sawa kwa mteja anayesema "inaunganisha" tu, lakini huacha ushahidi mahali tofauti. Ikiwa muundo wa zamani unatumika, uanzishaji ni mtarajiwa. Ikiwa muundo mpya unatumika, kumbukumbu tupu ya ufikiaji wa wavuti inatarajiwa na haithibitishi chochote kwa upande wowote.

Wakati kitu ni cha zamani: uanzishaji hushindwa kwanza

Soma hitilafu halisi ya mteja badala ya hali yake ya mwisho. Sehemu za kupendeza ni hitilafu ya HTTPS, utambulisho wa seva ambao mteja alitarajia, mahali ombi lilikwenda, na ikiwa uthibitishaji wa cheti ulikamilika. Kisha linganisha hizo na kumbukumbu za huduma ya wavuti na proksi upande wa seva.

Kivinjari kufikia ukurasa wa kuingia si ushahidi kwamba uthibitishaji wa API wa mteja huyu ulifanikiwa. Ni maombi tofauti, yenye matarajio tofauti ya cheti na mara nyingi majina tofauti ya mwenyeji. Ikiwa lango linahudumiwa kwa usahihi na mteja bado anashindwa, tofauti iko kwenye njia ya uanzishaji, si kwenye nenosiri la mtumiaji.

Usifanye ulinganisho upite kwa kuzima uthibitishaji wa TLS au kulegeza sera ya uthibitishaji. Hiyo hubadilisha kutolingana kwa usanidi kunakoweza kutambuliwa kuwa njia inayofanya kazi lakini haijathibitishwa, na mabadiliko hayo ndiyo hubadilisha jaribio la muda kuwa shimo la kudumu. Nyaraka za Access Server kuhusu profaili za muunganisho zinaeleza vizazi vyote viwili na mtiririko wa profaili ya muda, na ndiyo rejea ya kukagua kabla ya kudhani kuwa proksi ndiyo yenye kosa.

Wakati kitu ni kipya: soma kituo cha udhibiti badala yake

Kwa profaili ya mtindo wa 2.9, mteja huenda moja kwa moja kwenye kituo cha mwisho asilia cha VPN. Chunguza vituo vya mwisho kwenye profaili, usafirishaji unaotumika, na hitilafu ya kituo cha udhibiti. Ikiwa mteja hatoi ombi la HTTP kamwe, hiyo inaendana na muundo na si dalili.

Hapa pia swali la proksi hubadilisha umbo. Ushushaji wa HTTPS hauwezi kuvunja mtiririko wa TCP pekee ambao hauoni kamwe, lakini bado unaweza kuvunja upakuaji unaochapisha profaili, na kipitishaji cha TCP pekee hakitabeba UDP hata kidogo. Angalia usafirishaji ambao profaili inaomba kabla ya kuhitimisha kuwa mbele haina umuhimu.

Upitishaji wa TLS kwa mtiririko mmoja ni mpangilio mwembamba. Hautoi upitishaji wa UDP, na hauzalishi tabia ya daemon yenyewe ya kupitisha huduma kwenye 443. Ikiwa mbele yako inafanya moja ya hayo, sema ipi, kwa sababu tiba inatofautiana.

Tiba zinazobaki nyembamba

Ukaguzi usioingilia sana ni kuzalisha profaili mpya inayotumika kwa akaunti ya majaribio na kuunganisha kupitia kituo cha mwisho asilia kilichokusudiwa na mahitaji yale yale ya uthibitishaji. Ikiwa hiyo inafanya kazi na profaili ya zamani iliyohifadhiwa haifanyi, umetenganisha kitu na seva na na proksi kwa hatua moja.

Usambazaji wa profaili iliyofungwa kwa mtumiaji huondoa kabisa utegemezi wa uanzishaji wa zamani, kwa sababu hakuna ubadilishanaji wa profaili ya muda unaoweza kushindwa. Lazima itolewe kwa mtumiaji aliyekusudiwa, kamwe isinakiliwe kutoka kwa msimamizi, na hubadilisha kile mteja anaruhusiwa kufanya, kwa hivyo ichukulie kama uamuzi wa sera na si kama njia ya kukwepa.

Kisha rekebisha mpangilio wa uchapishaji ili kila njia inayohitajika iwepo: njia ya wavuti kwa upakuaji na matumizi ya lango, na njia asilia ya VPN kwenye usafirishaji ambao profaili unatarajia. Weka kazi ya proksi kwenye tabaka moja. Handaki iliyofungwa kwa mtumiaji inayofanya kazi inathibitisha kuwa njia hiyo inafanya kazi; haithibitishi kuwa kila mpangilio wa proksi unasaidia kila kizazi, na kushindwa kwa uanzishaji wa zamani hakuhukumu muundo mpya zaidi.

• Bainisha kizazi cha kitu kabla ya kugusa proksi.
• Bainisha ikiwa kushindwa kunatokea kabla ya handaki au ndani yake.
• Thibitisha kile mbele inamaliza: HTTP, mtiririko wa TCP, au UDP.
• Jaribu profaili iliyotolewa hivi karibuni dhidi ya kituo cha mwisho asilia bila kubadilisha sera.