Muunganisho kukataliwa si tatizo la cheti: mwongozo wa VPN

Mteja anasema muunganisho umekataliwa mara moja baada ya kuzalisha upya CRL, kwa hiyo CRL inaonekana kuwa na hatia. Haiko hivyo. Kukataliwa ni jibu la tabaka la usafirishaji, na uthibitishaji wa cheti hufanyika baadaye, ndani ya handshake ya handaki. Muda unaolingana ni muktadha, si uthibitisho.

Ukaguzi mbili hutenganisha visa katika muda wa chini ya dakika moja, na hakuna hata mmoja unaogusa mipangilio ya uaminifu.

Soma hitilafu kwenye tabaka iliyoizalisha

ECONNREFUSED kutoka connect ina maana jaribio la usafirishaji lilikataliwa: kitu kiliitikia kwa reset, au stack iliripoti bandari isiyoweza kufikiwa. Tatizo la cheti haliwezi kuzaa hitilafu hiyo, kwa sababu handshake ya TLS haianzi kamwe bila muunganisho wa usafirishaji. Ukiona kukataliwa, mteja hakuwahi kufika mbali vya kutosha kuwasilisha cheti. Ukweli huo mmoja unaondoa ubatilishaji kama sababu.

Kinyume chake pia ni kweli. Cheti kilichobatilishwa huzaa muunganisho kamili wa TCP na handshake iliyoshindikana, ambayo hurekodiwa kwenye seva kama hitilafu ya uthibitishaji.

Kukataliwa kwa TCP: hakuna anayesikiliza

Kwa TCP, angalia kama mfano uliokusudiwa unaendeshwa na umefungwa kwenye anwani na bandari iliyo kwenye wasifu. ss -lntp huonyesha wasikilizaji, na kutokuwepo kwa mmoja ndiyo maelezo ya kawaida. Firewall inayokataa badala ya kutupa huzaa ujumbe huo huo kwa upande wa mteja, ndiyo sababu unakagua yote mawili.

Kagua familia ya anwani pia. Huduma iliyofungwa kwa 127.0.0.1 au kwa IPv6 pekee itakataa mteja anayetatuliwa kwenda nyingine.

Kisha soma logi ya huduma badala ya kubahatisha. Kuanzisha upya baada ya matengenezo ya CA kunaweza kushindikana kwenye faili isiyosomeka au iliyokosekana na kamwe kufikia hali ya kusikiliza, na logi hutaja faili. Hiyo ni kushindikana kwa kuanza, hitilafu tofauti na cheti kilichokataliwa.

UDP haina handshake ya kukataa

OpenVPN juu ya UDP haiundi muunganisho kwa maana ya TCP, kwa hiyo hakuna cha kukataa wakati wa connect. Kwenye Linux, hitilafu inayoonyeshwa na soketi ya UDP inaweza kutoka kwa ICMP port-unreachable iliyozalishwa na datagram ya awali. ukurasa wa mwongozo wa udp(7) unaeleza tabia hiyo isiyo ya samtidiga.

Ndiyo sababu mteja wa UDP anaweza kuchapisha kukataliwa wakati mchakato wa seva unaendeshwa lakini haujafungwa kwenye anwani inayotarajiwa.

CRL hukaguliwa wapi kwa kweli

CRL hushauriwa wakati wa handshake ya TLS, baada ya upande mwingine kuwasilisha cheti chake, na tu ikiwa usanidi wa seva unaruhusu. Chaguo la crl-verify la OpenVPN linaelekeza kwenye faili, na kushindikana huonekana kwenye logi ya seva kama hitilafu ya uthibitishaji inayotaja cheti.

Kwa hiyo mteja aliyebatilishwa huunganisha kwenye tabaka la usafirishaji kisha hushindikana katika uthibitishaji. Seva hiyo hiyo, bandari hiyo hiyo, ujumbe tofauti kabisa.

Kagua mtoaji na tarehe za uhalali wa CRL utakapofikia hatua hiyo. CRL iliyotiwa sahihi na CA isiyo sahihi, au iliyoisha kabla ya mteja kuunganisha, huzaa hitilafu za uthibitishaji ambazo hazina uhusiano wowote na cheti cha mteja mwenyewe.

Mwongozo mfupi kwa mara ijayo

Thibitisha kwanza usafirishaji: msikilizaji yupo, familia sahihi ya anwani, firewall haikatai. Kisha thibitisha huduma ilifika hali ya kusikiliza kwa kusoma logi ya kuanza. Na baada ya hapo pekee ndipo uangalie hitilafu za handshake kwa ujumbe wa uthibitishaji. Weka mpangilio huo thabiti, kwa sababu kila hatua huondoa tabaka zima la sababu.

Andika usafirishaji, lengwa lililotatuliwa, bandari na maandishi kamili ya hitilafu. Kusakinisha upya mteja huharibu ushahidi huo na kwa kawaida hakubadilishi chochote.