OpenVPN inaendelea kujaribu tena baada ya hitilafu ya TLS: jinsi ya kuizuia

Mteja anajiunga, anashindwa wakati wa majadiliano ya TLS, anasubiri na kujaribu tena seva hiyo hiyo kwa matokeo hayo hayo. Chini ya msimamizi anayeanzisha upya mchakato ulioshindwa, majaribio hayo yanakuwa mzunguko usio na mwisho katika jarida, na mstari wa kwanza wa uchunguzi unatoweka mbali. OpenVPN hutoa chaguo linalobadilisha kushindwa huko kwa majadiliano kuwa kutoka kunakoonekana badala ya jaribio jingine. Hii ni mipangilio ya uchunguzi na usimamizi, si ukarabati, kwa hivyo iunganishe na sera inayoruhusu mchakato kubaki umesimama.

Mzunguko unaoficha hitilafu ya kwanza

Unachokiona ni kizuizi kinachojirudia na si kushindwa kumoja: jaribio la muunganisho, hitilafu ya TLS, pause na kisha mlolongo huo huo. Kila kurudia kunasukuma mstari wa awali juu zaidi kwenye jarida. Ikiwa kitengo huanzisha upya inaposhindwa, mzunguko unaweza kuendelea kwa masaa bila mtu yeyote kusoma sababu. Dalili ni mzunguko, ingawa kasoro ya msingi ni tatizo moja la majadiliano.

Vikao vya mwingiliano huvumilia hili kwa sababu kushindwa kwa muda kunaweza kutoweka kwenye jaribio lijalo. Miunganisho ya kiotomatiki haiwezi kustahimili matumaini hayo: mchakato lazima usimame ili mtu au kifuatiliaji akione hali.

Kabla ya kubadilisha chochote, nasa mzunguko mmoja kamili. Andika anwani ya mbali, hatua ya TLS iliyotajwa kwenye hitilafu na ikiwa mchakato unatoka kabisa.

Utaratibu wa kujaribu tena nyuma ya mzunguko

Kujaribu tena ni chaguo-msingi kwa sababu muda kadhaa wa kuisha usiohusiana hushiriki utaratibu huo. connect-retry huweka pengo kati ya majaribio ya muunganisho, connect-retry-max inaweza kupunguza mara ngapi kila ingizo la mbali linajaribiwa, na resolv-retry husimamia utafutaji wa majina unaorudiwa. Kushindwa kwa majadiliano ya TLS hufikia utaratibu huo kama tukio la usafirishaji, kwa hivyo mteja hupanga jaribio lingine badala ya kuripoti. Thamani ya chaguo-msingi husaidia kwenye kiungo kisicho imara na kudhuru kwa kasoro isiyoweza kupona.

Chaguo --tls-exit hubadilisha tu kesi ya majadiliano. Mwongozo unalielezea kama kutoka wakati majadiliano ya TLS yanashindwa, jambo ambalo ni jembamba kuliko kutoka kwa kila hitilafu. Muda wa kuisha, kushindwa kwa kitatuzi na kukataliwa kwa uthibitishaji huhifadhi tabia yao.

Kumfanya mteja atoke wakati TLS inashindwa

Weka tls-exit kwenye profaili ambayo mteja hupakia kwa kweli, au toa --tls-exit unapoianzisha, na uiendeshe mara moja mbele. Soma hali ya kutoka na mstari wa mwisho wa kumbukumbu, kwa sababu msimamizi huchukua hatua kwa hali hiyo. Kutoka kusiko sifuri baada ya kushindwa kwa majadiliano ndiyo matokeo yanayokusudiwa. Ikiwa mchakato unaendelea kujaribu badala ya kuisha, chaguo haliko kwenye profaili ambayo mteja hupakia kwa kweli.

Msimamizi huamua ikiwa kutoka huko kunaonekana. Kitengo cha systemd chenye Restart=always au Restart=on-failure huanzisha mteja tena, kwa hivyo mzunguko unaendelea na chaguo linaonekana kama halifanyi kitu. Angalia sera kabla ya kumlaumu mteja:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no huruhusu mchakato kubaki umesimama, na Restart=on-failure bado huanzisha upya baada ya hali isiyo sifuri. Ikiwa unataka kushindwa kuonekana lakini huduma ipone kutokana na ajali zisizohusiana, weka Restart=on-failure na tumia StartLimitBurst na StartLimitIntervalSec kusimamisha dhoruba ya kuanzisha upya. Kisha soma hali ya kitengo kuthibitisha msimbo wa mwisho wa kutoka: systemctl status huiripoti, na jarida huhifadhi hitilafu ya kwanza juu ya kuanzisha upya.

Andika uamuzi kwenye kitengo au kwenye madokezo ya profaili. Profaili inayotoka wakati TLS inashindwa inaonekana kama ajali kwa mtu anayefuata isipokuwa sababu imeandikwa. Eleza ni kushindwa gani kunapaswa kusimamisha mchakato na kupi kunapaswa kujaribiwa tena.

Thibitisha kwa kituo cha mwisho cha matumizi ya mara moja

Ili kuona tabia kabla ya kuiamini, nakili profaili na uelekeze nakala kwenye kituo cha mwisho kinachokubali muunganisho wa TCP lakini hakizungumzi OpenVPN kamwe. Msikilizaji anayejibu na kisha kunyamaza anatosha. Pamoja na tls-exit, mteja anapaswa kuisha wakati makubaliano ya mkono yanashindwa; bila hiyo, profaili hiyo hiyo inapaswa kuendelea kuzunguka. Tumia nakala, kamwe usitumie profaili inayofanya kazi.

Linganisha runs mbili kwa hali ya kutoka na kwa mstari wa kwanza wa hitilafu, si kwa muda ambao kila moja ilidumu. Hali inakuambia ikiwa chaguo liliwashwa, na mstari wa kwanza unakuambia hatua ipi ilishindwa.

Ondoa profaili ya majaribio ukiwa umemaliza. Nakala yenye kituo cha mwisho kilichokosewa kwa makusudi ni mtego kwa yeyote anayeanzisha kila profaili kwenye folda baadaye.

Hatua ambazo chaguo hili haliwezi kufikia kamwe

Kukataliwa kwa uthibitishaji ni hatua ya baadaye. Ikiwa seva inatathmini akaunti na kuikataa, TLS tayari imejadiliwa, kwa hivyo tls-exit haiwashi. Mipangilio ya kujaribu tena uthibitishaji ndiyo mahali panapofuata pa kuangalia, na sababu ya seva ni muhimu zaidi kuliko mstari wa mwisho wa mteja. Nenosiri lisilo sahihi na cheti kinachokosekana vinaweza kutoa ujumbe unaofanana upande wa mteja.

Njia inayokosekana, kitatuzi kisicho sahihi au lango lisilofikiwa pia liko nje ya chaguo, kwa sababu si kushindwa kwa majadiliano. Upotevu wa pakiti kimya ndiyo kisa kisicho wazi zaidi: kulingana na umbali ambao ubadilishanaji ulifika, mteja anaweza kuripoti kushindwa kwa majadiliano au kwa urahisi kupitwa na muda.

Hifadhi tofauti hiyo kwenye madokezo yako. Mpangilio ni wa uchunguzi na usimamizi badala ya ukarabati, kwa hivyo hautengenezi kutokulingana kwa cipher, tatizo la cheti au bandari isiyo sahihi. Kwanza rekebisha sababu ya majadiliano yaliyoshindwa, kisha amua ikiwa kutoka mara moja bado kunafaa usambazaji.