May isang lumang device na lumitaw, hindi makakonekta, at ang pinakamabilis na ayos na mukha ay ang pagpapahina ng buong host hanggang sa magtagumpay ang koneksyon. Ang palitang iyon ay hindi nakikita sa sandaling iyon at permanente sa praktika, dahil walang nag-aalis ng floor na sa wakas ay gumagana. Dalawang lubos na magkaibang fault ang gumagawa ng pressure, at isa lang sa kanila ang tungkol sa mga cipher. Classify muna ang fault, pagkatapos ay ilagay ang eksepsiyon sa lugar kung saan hindi ito makakalat.

Hatiin ang failure sa dalawa bago baguhin ang isang directive

Ang linya ng server log tungkol sa walang shared cipher, o tungkol sa unsupported na bersyon ng protocol, ay galing sa control channel: hindi nagkasundo ang dalawang dulo kung paano poprotektahan ang negotiation mismo. Ang linya ng client na nagsasabing walang paraan ng pag-verify ng server certificate ang naka-enable ay galing sa ibang lugar, dahil hindi man lang sinusuri ng client na iyon kung sino ang sumagot. Ang pagpapalit ng data cipher ay walang nagagawa sa ikalawang kaso, at ang pagdaragdag ng role check ay walang nagagawa sa una.

Kunin ang pinakaunang failing line mula sa bawat panig, hindi ang huling linya bago ang disconnect, dahil ang huli ay karaniwang resulta lang. Pagkatapos, alamin kung aling file ang talagang binuksan ng client: ang na-import na profile ay madalas na umiiral nang dalawang beses sa magkaibang display name, at ang pag-edit sa kopyang walang nagbabasa ay gumagawa ng nakakumbinsing walang pagbabago. Ang tumatakbong proseso ay nagtatago ng mga setting na sinimulan nito, kaya ang na-save na file ay hindi ang na-load na file. Ipinapakita ng mga command sa ibaba ang negotiation ng client sa tabi ng pananaw ng server sa parehong pagtatangka.

openvpn --config <profile>.ovpn --verb 4 2>&1 | head -n 40
journalctl -u [email protected] --since '-10 min' | grep -iE 'cipher|tls|verify'

Ang pangalawang listener ang tapat na lugar para sa mas mahinang floor

Kapag tumigil ang device sa TLS 1.0 na may data channel bago ang 2.5, kailangang mag-alok ang server ng mas mababang floor para sa control channel at data cipher na kinikilala ng lumang client. Ang fallback directive ay para sa peer na iyon mismo, habang ang listahan ng cipher ay nagpapanatili sa mga modernong client sa modernong suite. Pag-aari ng listener ang dalawang directive at hindi ng user o koneksyon, at walang opsiyon sa bawat client ang nagpapakipot sa kanila mamaya. Kaya ang isang legacy na device sa pangunahing port ay desisyon tungkol sa bawat peer na nagbabahagi ng port na iyon.

Kung saan pinapayagan ng platform, patakbuhin ang legacy listener bilang sarili nitong instance sa hiwalay na port, payagan ang port na iyon mula sa address ng device lamang, at iwanan ang pangunahing serbisyo. Isulat kung bakit umiiral ang pangalawang listener, sa file na nagdadala ng configuration nito, dahil kung hindi ay babasahin ito ng susunod na paglilinis bilang natirang basura. Ang paghahati ay may halaga lamang kung ang mas mahinang floor ay nagtatapos kung saan nagtatapos ang device.

tls-version-min 1.0
data-ciphers AES-128-GCM:AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC

Ano ba talaga ang sinisira ng lumang provider certificate

Ang verification error ay isang nawawalang role binding: kung wala ito, tatanggapin ng client ang anumang certificate na nag-chain sa pinagkakatiwalaang CA, nakaisyu man ito para sa server o hindi. I-bind muna ang certificate sa server role, at ituring ang binding bilang requirement hindi bilang tuning knob. Isang profile lang na nabibigo pa rin pagkatapos ng hakbang na iyon ang may tunay na problema sa certificate.

Ang lumang provider certificate na ang laki ng key o signature algorithm ay hindi na tumutugma sa default na patakaran ng OpenSSL ay ang kaso para sa limitadong pagbabago ng security level sa control channel. Ang pagbaba ng level doon ay hindi nagsasara ng verification, at hindi kailanman dapat isama sa walang laman na CA, naka-disable na verification, o hindi nasuri na hostname. Itago ang linya sa loob ng iisang profile na nangangailangan nito; ang pag-export ng pinaluwag na OpenSSL configuration sa buong mundo ay magbibigay ng parehong pagluwag sa bawat programa sa makina.

remote-cert-tls server
tls-cipher "DEFAULT:@SECLEVEL=0"

Basahin ang na-negotiate na halaga, hindi ang banner

Sa verbosity 4, ipinapakita ng dalawang dulo ang TLS version at cipher ng control channel na napagkasunduan, at ang data cipher ng session. Basahin ang mga linyang iyon sa halip na ang initialization banner, na nag-uulat ng tagumpay at hindi ng mga tuntunin nito. Pagkatapos ay ikonekta muli ang modernong client sa pangunahing listener at tiyakin na dumarating pa rin ito sa modernong suite, dahil ang eksepsiyong tumagas sa shared configuration ay unang lumilitaw dito. Ang mga halagang kokopyahin mo ay magiging basehan ng susunod na review.

Subukan ang lumang device nang mag-isa: dapat itong kumonekta, at dapat ito ang tanging session sa mga log na nagpapakita ng mas mahinang parameter. Kung ang pangalawang peer ay nag-negotiate din sa lumang suite, mas malawak ang eksepsiyon kaysa sa nilayon at hindi talaga nangyari ang paghahati ng listener. Itala ang dalawang obserbasyon at hindi lamang ang konklusyon.

Bawat eksepsiyon ay nangangailangan ng may-ari at petsa

Ang eksepsiyong walang kundisyon sa pagtanggal ay tahimik na nagiging default, kaya ilagay ang device, ang may-ari, ang dahilan at ang petsang aalis ito sa tabi ng configuration na pinagbibigyan nito. Kung wala ang linyang iyon, mas matagal pang mabubuhay ang mas mahinang floor kaysa sa hardware na nangailangan nito.

Ang palitan ang client, o humingi ng kasalukuyang profile sa provider, ang resulta na dapat targetin; ang eksepsiyon ay pagkaantala at hindi disenyo. Kapag nagretiro ang device, alisin ang listener at ang profile sa iisang pagbabago para walang kalahati ang magpatuloy sa pagtakbo. Wala sa mga ito ang gumagawa sa lumang parameter na ligtas, pinipigilan lang nito ang limitasyon ng isang device na maging basehan ng lahat.

Kaugnay na mga artikulo