Odmowa połączenia to nie problem z certyfikatem: instrukcja VPN

Klient mówi, że połączenie zostało odrzucone zaraz po ponownym wygenerowaniu CRL, więc CRL wygląda na winny. Nie jest. Odmowa to odpowiedź warstwy transportowej, a walidacja certyfikatu następuje później, w uścisku dłoni tunelu. Zbieżność czasu to kontekst, nie dowód.

Dwie kontrole rozdzielają przypadki w mniej niż minutę i żadna z nich nie dotyka ustawień zaufania.

Czytaj błąd na warstwie, która go wytworzyła

ECONNREFUSED z connect oznacza, że próba transportowa została odrzucona: coś odpowiedziało resetem albo stos zgłosił nieosiągalny port. Problem z certyfikatem nie może wytworzyć tego błędu, ponieważ uścisk dłoni TLS nigdy nie zaczyna się bez połączenia transportowego. Jeśli widzisz odmowę, klient nigdy nie dotarł do etapu przedstawiania certyfikatu. Ten jeden fakt wyklucza unieważnienie jako przyczynę.

Jest też odwrotnie. Unieważniony certyfikat daje ukończone połączenie TCP i nieudany uścisk dłoni, zapisywany na serwerze jako błąd weryfikacji.

Odmowa TCP: nikt nie nasłuchuje

Dla TCP sprawdź, czy zamierzona instancja działa i jest przypisana do adresu i portu z profilu. ss -lntp pokazuje nasłuchujących, a ich brak to zwykłe wyjaśnienie. Zapora, która odrzuca zamiast porzucać, daje ten sam komunikat po stronie klienta, dlatego sprawdzasz oba.

Sprawdź także rodzinę adresów. Usługa przypisana do 127.0.0.1 albo tylko do IPv6 odrzuci klienta, który rozwiązuje się na drugą.

Potem czytaj dziennik usługi, zamiast zgadywać. Restart po konserwacji CA może się nie powieść na nieczytelnym lub brakującym pliku i nigdy nie osiągnąć stanu nasłuchiwania, a dziennik podaje nazwę pliku. To błąd startu, inny błąd niż odrzucony certyfikat.

UDP nie ma uścisku dłoni do odrzucenia

OpenVPN przez UDP nie nawiązuje połączenia w sensie TCP, więc w momencie connect nie ma czego odrzucać. W systemie Linux błąd zgłoszony przez gniazdo UDP może pochodzić od ICMP port-unreachable wygenerowanego przez wcześniejszy datagram. strona podręcznika udp(7) opisuje to asynchroniczne zachowanie.

Dlatego klient UDP może wypisać odmowę, gdy proces serwera działa, ale nie jest przypisany do oczekiwanego adresu.

Gdzie naprawdę sprawdzana jest CRL

CRL jest sprawdzana podczas uścisku dłoni TLS, po przedstawieniu certyfikatu przez drugą stronę, i tylko jeśli konfiguracja serwera na to pozwala. Opcja OpenVPN crl-verify wskazuje plik, a niepowodzenie pojawia się w dzienniku serwera jako błąd weryfikacji z nazwą certyfikatu.

Unieważniony klient łączy się więc na warstwie transportowej, a potem zawodzi na uwierzytelnianiu. Ten sam serwer, ten sam port, zupełnie inny komunikat.

Sprawdź wystawcę i daty ważności CRL, gdy dotrzesz do tego etapu. CRL podpisana przez niewłaściwe CA albo taka, która wygasła przed połączeniem klienta, daje błędy weryfikacji niemające nic wspólnego z certyfikatem samego klienta.

Krótka instrukcja na następny raz

Najpierw potwierdź transport: nasłuchujący istnieje, właściwa rodzina adresów, zapora nie odrzuca. Potem potwierdź, że usługa osiągnęła stan nasłuchiwania, czytając dziennik startu. I dopiero wtedy patrz na błędy uścisku dłoni w poszukiwaniu komunikatów weryfikacji. Utrzymuj tę kolejność, bo każdy krok eliminuje całą klasę przyczyn.

Zapisz transport, rozwiązaną destynację, port i dokładny tekst błędu. Ponowna instalacja klienta niszczy ten dowód i zwykle niczego nie zmienia.