Odmietnuté pripojenie nie je problém certifikátu: runbook pre VPN

Klient hlási odmietnuté pripojenie hneď po tom, čo ste znova vygenerovali CRL, takže CRL vyzerá ako vinník. Nie je. Odmietnutie je odpoveď transportnej vrstvy a overenie certifikátu prebieha neskôr, vnútri handshake tunela. Načasovanie je kontext, nie dôkaz.

Dve kontroly oddelia prípady za menej ako minútu a ani jedna z nich sa nedotýka nastavení dôvery.

Čítajte chybu na vrstve, ktorá ju vytvorila

ECONNREFUSED z connect znamená, že pokus o transport bol odmietnutý: niečo odpovedalo resetom, alebo zásobník ohlásil nedostupný port. Problém s certifikátom takú chybu vyvolať nemôže, pretože TLS handshake nikdy nezačne bez transportného spojenia. Ak vidíte odmietnutie, klient sa nikdy nedostal tak ďaleko, aby predložil certifikát. Tento jediný fakt vylučuje odvolanie ako príčinu.

Platí to aj naopak. Odvolaný certifikát vytvorí dokončené TCP spojenie a neúspešný handshake, ktorý sa na serveri zaznamená ako chyba overenia.

Odmietnutie TCP: nikto nepočúva

Pri TCP skontrolujte, či zamýšľaná inštancia beží a je naviazaná na adresu a port z profilu. ss -lntp zobrazuje počúvajúce procesy a ich neprítomnosť je obvyklým vysvetlením. Firewall, ktorý odmieta namiesto zahadzovania, vytvára na strane klienta rovnakú správu, preto kontrolujete oboje.

Skontrolujte aj rodinu adries. Služba naviazaná na 127.0.0.1 alebo len na IPv6 odmietne klienta, ktorý sa prekladá na druhú.

Potom čítajte log služby, namiesto aby ste hádali. Reštart po údržbe CA môže zlyhať na nečitateľnom alebo chýbajúcom súbore a nikdy nedosiahnuť stav počúvania, a log súbor pomenuje. To je zlyhanie pri štarte, iná chyba než odmietnutý certifikát.

UDP nemá handshake, ktorý by sa dal odmietnuť

OpenVPN cez UDP nenadväzuje spojenie v zmysle TCP, takže v okamihu connect nie je čo odmietnuť. V Linuxe môže chyba hlásená UDP socketom pochádzať z ICMP port-unreachable vygenerovaného skorším datagramom. manuálová stránka udp(7) opisuje toto asynchrónne správanie.

Preto môže UDP klient vypísať odmietnutie, kým proces servera beží, ale nie je naviazaný na očakávanú adresu.

Kde sa CRL skutočne kontroluje

CRL sa konzultuje počas TLS handshake, po tom čo protistrana predloží svoj certifikát, a len ak to konfigurácia servera umožní. Voľba OpenVPN crl-verify ukazuje na súbor a zlyhanie sa v logu servera objaví ako chyba overenia s názvom certifikátu.

Odvolaný klient sa teda pripojí na transportnej vrstve a potom zlyhá pri autentizácii. Ten istý server, ten istý port, úplne iná správa.

Keď sa dostanete do tej fázy, skontrolujte vydavateľa CRL a dátumy platnosti. CRL podpísaná nesprávnou CA alebo tá, ktorá vypršala pred pripojením klienta, vytvára chyby overenia, ktoré nemajú nič spoločné s certifikátom samotného klienta.

Krátky runbook pre budúci raz

Najprv potvrďte transport: počúvajúci proces existuje, správna rodina adries, firewall neodmieta. Potom potvrďte, že služba dosiahla stav počúvania prečítaním štartovacieho logu. A až potom hľadajte v chybách handshake správy o overení. Držte toto poradie pevné, pretože každý krok vylučuje celú triedu príčin.

Zapíšte transport, preložený cieľ, port a presný text chyby. Preinštalovanie klienta ten dôkaz zničí a zvyčajne nič nezmení.