Anslutning nekad är inte ett certifikatproblem: en VPN-körbok

Klienten säger anslutning nekad direkt efter att du återskapade CRL:en, så CRL:en ser skyldig ut. Det är den inte. Nekande är ett svar från transportlagret, och certifikatvalidering sker senare, inne i tunnelns handskakning. Tidpunkten är kontext, inte bevis.

Två kontroller skiljer fallen åt på under en minut, och ingen av dem rör förtroendeinställningarna.

Läs felet på det lager som producerade det

ECONNREFUSED från connect betyder att transportförsöket nekades: något svarade med en reset, eller så rapporterade stacken en oåtkomlig port. Ett certifikatproblem kan inte ge det felet, eftersom TLS-handskakningen aldrig börjar utan en transportanslutning. Ser du ett nekande kom klienten aldrig tillräckligt långt för att presentera ett certifikat. Det enda faktumet utesluter återkallning som orsak.

Det omvända gäller också. Ett återkallat certifikat ger en fullbordad TCP-anslutning och en misslyckad handskakning, som loggas på servern som ett verifieringsfel.

TCP-nekande: ingen lyssnar

För TCP, kontrollera om den avsedda instansen körs och är bunden till adressen och porten i profilen. ss -lntp visar lyssnare, och avsaknaden av en är den vanliga förklaringen. En brandvägg som nekar i stället för att släppa producerar samma meddelande på klientsidan, därför kontrollerar du båda.

Kontrollera även adressfamiljen. En tjänst bunden till 127.0.0.1 eller bara till IPv6 nekar en klient som löses till den andra.

Läs sedan tjänstens logg i stället för att gissa. En omstart efter CA-underhåll kan misslyckas på en oläsbar eller saknad fil och aldrig nå lyssnarläget, och loggen namnger filen. Det är ett startfel, en annan bugg än ett nekat certifikat.

UDP har ingen handskakning att neka

OpenVPN över UDP upprättar ingen anslutning i TCP-bemärkelse, så det finns inget att neka vid connect. På Linux kan ett fel som en UDP-anslutning visar komma från en ICMP port-unreachable som ett tidigare datagram skapade. man-sidan udp(7) beskriver det asynkrona beteendet.

Därför kan en UDP-klient skriva ut ett nekande medan serverprocessen körs men inte är bunden till den förväntade adressen.

Var en CRL faktiskt kontrolleras

CRL:en konsulteras under TLS-handskakningen, efter att motparten har presenterat sitt certifikat, och bara om serverkonfigurationen tillåter det. OpenVPN:s crl-verify-alternativ pekar på filen, och ett fel visas i serverloggen som ett verifieringsfel som namnger certifikatet.

En återkallad klient ansluter alltså på transportlagret och misslyckas sedan i autentiseringen. Samma server, samma port, helt annat meddelande.

Kontrollera CRL:ens utgivare och giltighetsdatum när du når det steget. En CRL som signerats av fel CA, eller en som gick ut innan klienten anslöt, ger verifieringsfel som inte har något med klientens eget certifikat att göra.

En kort körbok för nästa gång

Bekräfta först transporten: lyssnare finns, rätt adressfamilj, brandvägg som inte nekar. Bekräfta sedan att tjänsten nådde sitt lyssnarläge genom att läsa startloggen. Och först då titta på handskakningsfel efter verifieringsmeddelanden. Håll den ordningen fast, eftersom varje steg utesluter en hel klass av orsaker.

Skriv ned transporten, den upplösta destinationen, porten och den exakta feltexten. En ominstallation av klienten förstör beviset och ändrar vanligtvis ingenting.