Odmítnuté připojení není problém certifikátu: runbook pro VPN

Klient hlásí odmítnuté připojení hned poté, co jste znovu vygenerovali CRL, takže CRL vypadá jako viník. Není. Odmítnutí je odpověď transportní vrstvy a ověření certifikátu probíhá později, uvnitř handshake tunelu. Načasování je kontext, ne důkaz.

Dvě kontroly oddělí případy za méně než minutu a ani jedna z nich se nedotýká nastavení důvěry.

Čtěte chybu na vrstvě, která ji vytvořila

ECONNREFUSED z connect znamená, že pokus o transport byl odmítnut: něco odpovědělo resetem, nebo zásobník ohlásil nedostupný port. Problém s certifikátem takovou chybu vyvolat nemůže, protože TLS handshake nikdy nezačne bez transportního spojení. Pokud vidíte odmítnutí, klient se nikdy nedostal tak daleko, aby předložil certifikát. Tento jediný fakt vylučuje odvolání jako příčinu.

Platí to i obráceně. Odvolaný certifikát vytvoří dokončené TCP spojení a neúspěšný handshake, který se na serveru zaznamená jako chyba ověření.

Odmítnutí TCP: nikdo neposlouchá

U TCP zkontrolujte, zda zamýšlená instance běží a je navázaná na adresu a port z profilu. ss -lntp zobrazuje naslouchající procesy a jejich nepřítomnost je obvyklým vysvětlením. Firewall, který odmítá místo zahazování, vytváří na straně klienta stejnou zprávu, a proto kontrolujete obojí.

Zkontrolujte i rodinu adres. Služba navázaná na 127.0.0.1 nebo jen na IPv6 odmítne klienta, který se překládá na druhou.

Potom čtěte log služby, místo abyste hádali. Restart po údržbě CA může selhat na nečitelném nebo chybějícím souboru a nikdy nedosáhnout stavu naslouchání, a log soubor pojmenuje. To je selhání při startu, jiná chyba než odmítnutý certifikát.

UDP nemá handshake, který by se dal odmítnout

OpenVPN přes UDP nenavazuje spojení ve smyslu TCP, takže v okamžiku connect není co odmítnout. V Linuxu může chyba hlášená UDP socketem pocházet z ICMP port-unreachable vygenerovaného dřívějším datagramem. manuálová stránka udp(7) popisuje toto asynchronní chování.

Proto může UDP klient vypsat odmítnutí, zatímco proces serveru běží, ale není navázán na očekávanou adresu.

Kde se CRL skutečně kontroluje

CRL se konzultuje během TLS handshake, poté co protistrana předloží svůj certifikát, a jen pokud to konfigurace serveru umožní. Volba OpenVPN crl-verify ukazuje na soubor a selhání se v logu serveru objeví jako chyba ověření s názvem certifikátu.

Odvolaný klient se tedy připojí na transportní vrstvě a poté selže při autentizaci. Stejný server, stejný port, úplně jiná zpráva.

Když se dostanete do této fáze, zkontrolujte vydavatele CRL a data platnosti. CRL podepsaná špatnou CA nebo ta, která vypršela před připojením klienta, vytváří chyby ověření, které nemají nic společného s certifikátem samotného klienta.

Krátký runbook pro příště

Nejprve potvrďte transport: naslouchající proces existuje, správná rodina adres, firewall neodmítá. Potom potvrďte, že služba dosáhla stavu naslouchání, čtením startovního logu. A teprve potom hledejte v chybách handshake zprávy o ověření. Držte toto pořadí pevné, protože každý krok vylučuje celou třídu příčin.

Zapište transport, přeložený cíl, port a přesný text chyby. Přeinstalace klienta ten důkaz zničí a obvykle nic nezmění.