Dalawang pagkabigo ng VPN ay magkatulad sa upuan ng user ngunit nangangailangan ng magkasalungat na pagwawasto. Ang hindi pagtutugma ng pangalan ay nangangahulugang wasto ang sertipiko ngunit inilabas para sa ibang bagay. Ang pagkabigo dahil sa pag-expire ay nangangahulugang hindi wasto ang sertipiko sa sandaling ito. Wala sa dalawa ang problema sa password, at ang pag-reset ng mga kredensyal ang pinakakaraniwang nasasayang na oras sa parehong kaso. Basahin ang yugtong nabibigo bago hawakan ang anuman.

Ang teksto ng error ang diagnosis

Sinasabi ng kliyente kung aling pag-check ang nabigo, kahit maikli ang mensahe. Ang hindi pagtutugma ay pinangalanan ang inaasahang hostname at ang nahanap na pangalan. Ang error sa pag-expire ay binabanggit ang mga petsa ng bisa o oras. Ang dalawang pangungusap na iyon ay tumuturo sa magkaibang bahagi ng sertipiko.

Basahin ang mga ito sa yugtong lumilitaw sila. Ang pagkabigo habang nag-aagawan ng kamay ay problema sa sertipiko; ang pagkabigo pagkatapos umangat ang tunel ay problema sa routing o kredensyal. Ang pagpapanatili ng yugto ang pumipigil sa pagsisiyasat na dumausdos sa walang kaugnayang mga setting.

Kung nag-iiba ang pagkabigo sa pagitan ng mga pagtatangka, mayroon kang ikatlong posibilidad: higit sa isang node sa likod ng parehong pangalan.

Mga pag-check ng pangalan: ano ang inihahambing ng kliyente

Inihahambing ng kliyente ang pagkakakilanlang inaasahan nito sa mga pangalan sa sertipiko, na nasa subjectAltName extension. Ang hilaw na IP sa profile, isang alias na hindi nakalista ng sertipiko, o isang pangalang dumadagundong lamang sa parehong server — lahat ay nabibigo sa pag-check na ito. Ang maabot ang tamang makina ay hindi katulad ng paghaharap ng tamang pagkakakilanlan.

Suriin ang sertipikong aktuwal na inihaharap ng server sa halip na file mula sa naunang pagtatangka. Hinihingi ng utos sa ibaba ang pangalang in-configure mo, kaya kasama sa sagot ang sertipikong makikita ng tunay na kliyente.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -ext subjectAltName

Ang sertipiko mula sa pinagkakatiwalaang issuer ay maaari pa ring para sa ibang serbisyo. Panatilihing naka-on ang mga pag-check ng pangalan ng kliyente, dahil ang pagtitiwala sa isang CA ay hindi nagbibigay ng awtoridad sa bawat pangalang pinirmahan nito. Ang pagpapasawalang-bisa ng pag-check ay ginagawang paglantad ang error sa configuration.

Pag-expire: kaninong orasan ang binabasa

Ang bisa ay isang pares ng timestamp, at inihahambing ito ng verifier sa sarili nitong orasan. Ang device na mali ang orasan ay nag-uulat ng wastong sertipiko bilang nag-expire na o hindi pa wasto, at ang orasan ang kailangang itama, hindi ang sertipiko. Ang pagkakaiba sa pagpapakita ng time zone ay hindi katulad ng maling pinagbabatayang oras.

Ihambing ang mga petsa ng sertipiko sa UTC sa kliyente bago maghinuha ng anuman:

openssl x509 -in cert.pem -noout -dates
date -u

Kung talagang lumipas na ang mga petsa, mag-renew sa pamamagitan ng issuer. Kung may kapalit ngunit hindi pa wasto, sundin ang sinusuportahang paglipat sa halip na ilipat ang orasan upang umakma rito. Ang pag-urong ng petsa ng device upang masiyahan ang isang sertipiko ay desisyong may mga kahihinatnan na lampas pa sa tunel.

Bakit ang pagwawasto ng isa ay naglalantad ng iba

Nagpapatupad ng sunod-sunod na pag-check ang validation, at ang unang pagkabigo ang humihinto sa ulat. Ayusin ang pangalan at maaaring sabihin ng kliyente sa iyo na hindi kumpleto ang chain o nag-expire na ang sertipiko. Hindi ibig sabihin nito na hindi kailangan ang unang pag-check. Ibig sabihin, may higit sa isang problema ang chain, kaya asahan ang pangalawang error sa halip na basahin ito bilang patunay na mali ang unang pagwawasto.

Pinapalala ito ng maraming node. Ang serbisyong may load balancing ay maaaring magharap ng magkaibang sertipiko mula sa magkaibang miyembro, kaya ang pagsusulit na pumapasa nang dalawang beses at nabibigo nang isang beses ay nagsasabi tungkol sa fleet, hindi sa iyong kliyente. Itago ang peer address at oras ng pagtatangka sa diagnosis.

Ang detalyeng iyon ang nagpapalit ng pabagu-bagong tiket sa isang maaaring kopyahin.

Patunayan ito sa bagong koneksyon

Pagkatapos ng pagkumpuni, magbukas ng bagong koneksyon sa halip na ipagpatuloy ang luma, at tiyakin na ang yugtong dating nabibigo ay pumapasa na. Pagkatapos ay tiyakin na talagang nagdadala ng trapiko ang tunel, dahil ang matagumpay na pag-aagawan ng kamay ay hindi gumaganang ruta.

Itago ang eksaktong yugto ng error at ang mga detalye ng sertipiko kasama ng tiket.

Ang rekord na iyon ang pumipigil sa susunod na tao na i-reset ang mga password ng account dahil sa problema sa sertipiko. Magkaibang tanong ang pagkakakilanlan at bisa, at ang RFC 5280 ang sanggunian sa kung paano sinusuri ang pangalawa.

Kaugnay na mga artikulo