Hindi Problema ng Sertipiko ang Tinanggihang Koneksyon: Gabay sa VPN

Sabi ng kliyente, tinanggihan ang koneksyon kaagad matapos mong muling likhain ang CRL, kaya mukhang may kasalanan ang CRL. Hindi. Ang pagtanggi ay sagot ng antas ng transport, at ang pagpapatunay ng sertipiko ay nangyayari mamaya, sa loob ng handshake ng tunnel. Ang pagkakataon ng oras ay konteksto, hindi patunay.

Dalawang pagsusuri ang naghihiwalay sa mga kaso nang wala pang isang minuto, at wala sa kanila ang humahawak sa mga setting ng pagtitiwala.

Basahin ang error sa antas na lumikha nito

Ang ECONNREFUSED mula sa connect ay nangangahulugang tinanggihan ang pagtatangkang transport: may sumagot ng reset, o iniulat ng stack ang isang port na hindi maabot. Hindi kayang likhain ng problema sa sertipiko ang error na iyon, dahil hindi kailanman nagsisimula ang handshake ng TLS nang walang koneksyon sa transport. Kung may nakita kang pagtanggi, hindi umabot ang kliyente sa yugto ng paghaharap ng sertipiko. Ang nag-iisang katotohanang iyon ay nag-aalis sa pagpapawalang-bisa bilang dahilan.

Totoo rin ang kabaligtaran. Ang pinawalang-bisang sertipiko ay gumagawa ng kumpletong koneksyon ng TCP at bigong handshake, na naitala sa server bilang error sa pagpapatunay.

Pagtanggi ng TCP: walang nakikinig

Para sa TCP, tingnan kung tumatakbo ang nilalayong instance at nakatali sa address at port sa profile. Ipinapakita ng ss -lntp ang mga nakikinig, at ang kawalan ng isa ay ang karaniwang paliwanag. Ang firewall na tumatanggi sa halip na magtapon ay gumagawa ng parehong mensahe sa panig ng kliyente, kaya sinusuri mo ang dalawa.

Suriin din ang pamilya ng address. Ang serbisyong nakatali sa 127.0.0.1 o sa IPv6 lamang ay tatanggihan ang kliyenteng nagre-resolve sa isa.

Pagkatapos, basahin ang log ng serbisyo sa halip na manghula. Ang pag-restart pagkaraang ng maintenance ng CA ay maaaring mabigo sa isang file na hindi mabasa o nawawala at hindi kailanman umabot sa kalagayang nakikinig, at pinapangalanan ng log ang file. Iyon ay kabiguan sa pagsisimula, ibang bug kaysa sa tinanggihang sertipiko.

Walang handshake ang UDP na tatanggihan

OpenVPN sa UDP ay hindi nagtatatag ng koneksyon sa diwang TCP, kaya walang tatanggihan sa oras ng connect. Sa Linux, ang error na ipinapakita ng socket ng UDP ay maaaring magmula sa ICMP port-unreachable na nilikha ng naunang datagram. Inilalarawan ng pahina ng manwal ng udp(7) ang async na pag-uugaling iyon.

Kaya ang kliyenteng UDP ay maaaring maglimbag ng pagtanggi habang tumatakbo ang proseso ng server ngunit hindi nakatali sa inaasahang address.

Saan talaga sinusuri ang CRL

Ang CRL ay kinukonsulta sa panahon ng handshake ng TLS, matapos iharap ng kabilang panig ang sertipiko nito, at kung pinapayagan lamang ng konfigurasyon ng server. Ang opsyon na crl-verify ng OpenVPN ay tumuturo sa file, at ang kabiguan ay lumilitaw sa log ng server bilang error sa pagpapatunay na pinapangalanan ang sertipiko.

Kaya ang pinawalang-bisang kliyente ay kumokonekta sa antas ng transport at pagkatapos ay nabibigo sa pagpapatunay. Parehong server, parehong port, ganap na ibang mensahe.

Suriin ang naglabas at ang mga petsa ng bisa ng CRL kapag umabot ka sa yugtong iyon. Ang CRL na pinirmahan ng maling CA, o ang isang nag-expire bago kumonekta ang kliyente, ay gumagawa ng mga error sa pagpapatunay na walang kinalaman sa sariling sertipiko ng kliyente.

Isang maikling gabay para sa susunod

Unahing tiyakin ang transport: may nakikinig, tama ang pamilya ng address, hindi tumatanggi ang firewall. Pagkatapos ay tiyakin na umabot ang serbisyo sa kalagayang nakikinig sa pamamagitan ng pagbasa ng log ng pagsisimula. At pagkatapos lamang nito tingnan ang mga error sa handshake para sa mga mensahe ng pagpapatunay. Panatilihing takda ang pagkakasunod-sunod na iyon, dahil inaalis ng bawat hakbang ang isang buong uri ng dahilan.

Isulat ang transport, ang na-resolve na destinasyon, ang port at ang eksaktong teksto ng error. Ang muling pag-install ng kliyente ay sumisira sa ebidensiyang iyon at karaniwang walang binabago.