Az elutasított kapcsolat nem tanúsítványprobléma: VPN-üzemeltetési útmutató

A kliens azt mondja, hogy a kapcsolatot közvetlenül a CRL újragenerálása után elutasították, így a CRL tűnik bűnösnek. Nem az. Az elutasítás a szállítási réteg válasza, a tanúsítvány ellenőrzése pedig később, az alagút kézfogásában történik. Az időzítés kontextus, nem bizonyíték.

Két ellenőrzés egy percen belül szétválasztja az eseteket, és egyik sem nyúl a bizalmi beállításokhoz.

A hibát azon a rétegen olvassa, amely létrehozta

A connect felől érkező ECONNREFUSED azt jelenti, hogy a szállítási kísérletet elutasították: valami reset-tel válaszolt, vagy a verem elérhetetlen portot jelentett. Tanúsítványprobléma nem hozhat létre ilyen hibát, mert a TLS-kézfogás soha nem indul el szállítási kapcsolat nélkül. Ha elutasítást lát, a kliens soha nem jutott el odáig, hogy tanúsítványt mutasson be. Ez az egyetlen tény kizárja a visszavonást mint okot.

Az ellenkezője is igaz. A visszavont tanúsítvány befejezett TCP-kapcsolatot és sikertelen kézfogást eredményez, amely a kiszolgálón ellenőrzési hibaként naplózódik.

TCP-elutasítás: senki sem figyel

TCP esetén ellenőrizze, hogy a szándékolt példány fut-e, és a profilban szereplő címhez és porthoz van-e kötve. A ss -lntp mutatja a figyelőket, és ezek hiánya a szokásos magyarázat. A tűzfal, amely elutasít ahelyett hogy eldobna, ugyanazt az üzenetet eredményezi a kliens oldalán, ezért ellenőrzi mindkettőt.

Ellenőrizze a címcsaládot is. A 127.0.0.1-hez vagy csak az IPv6-hoz kötött szolgáltatás elutasítja azt a klienst, amely a másikra oldódik fel.

Ezután olvassa a szolgáltatás naplóját ahelyett hogy találgatna. A CA-karbantartás utáni újraindulás meghiúsulhat egy olvashatatlan vagy hiányzó fájlon, és soha nem érheti el a figyelő állapotot, a napló pedig megnevezi a fájlt. Ez indítási hiba, más hiba, mint az elutasított tanúsítvány.

Az UDP-nek nincs kézfogása, amit el lehetne utasítani

OpenVPN UDP felett nem hoz létre kapcsolatot TCP értelemben, így a connect pillanatában nincs mit elutasítani. Linuxon az UDP-socket által jelzett hiba származhat egy korábbi adatgram által keltett ICMP port-unreachable üzenetből. Az udp(7) kézikönyvoldal leírja ezt az aszinkron viselkedést.

Ezért az UDP-kliens kiírhatja az elutasítást, miközben a kiszolgáló folyamat fut, de nincs a várt címhez kötve.

Hol ellenőrzik valójában a CRL-t

A CRL-t a TLS-kézfogás során konzultálják, miután a partner bemutatta a tanúsítványát, és csak akkor, ha a kiszolgáló konfigurációja engedélyezi. Az OpenVPN crl-verify beállítása a fájlra mutat, és a hiba a kiszolgáló naplójában ellenőrzési hibaként jelenik meg, megnevezve a tanúsítványt.

A visszavont kliens tehát a szállítási rétegen kapcsolódik, majd hitelesítési hibát szenved. Ugyanaz a kiszolgáló, ugyanaz a port, teljesen más üzenet.

Amikor eljut erre a szakaszra, ellenőrizze a CRL kiállítóját és érvényességi dátumait. A rossz CA által aláírt CRL, vagy az, amely a kliens kapcsolódása előtt lejárt, olyan ellenőrzési hibákat eredményez, amelyeknek semmi közük a kliens saját tanúsítványához.

Rövid útmutató a következő alkalomra

Először igazolja a szállítást: figyelő jelen van, megfelelő címcsalád, a tűzfal nem utasít el. Ezután igazolja, hogy a szolgáltatás elérte a figyelő állapotát az indítási napló olvasásával. És csak ezután nézze a kézfogási hibákat ellenőrzési üzenetek után. Tartsa ezt a sorrendet rögzítve, mert minden lépés kizárja az okok egy egész osztályát.

Írja fel a szállítást, a feloldott célt, a portot és a hiba pontos szövegét. A kliens újratelepítése megsemmisíti ezt a bizonyítékot, és általában semmit sem változtat.