A hiba hitelesítő adatokkal kapcsolatos problémának tűnik: az openfortivpn elkéri a jelszót, elküldi, és az átjáró elutasítással vagy a bejelentkező oldalra történő átirányítással válaszol. Ezután a felhasználók újra beírják a jelszót, kipróbálják a tartománnyal minősített fióknevet, végül pedig beillesztik a böngésző portál URL-jét a gazdagép mezőbe. Ez az utolsó lépés az, amely egy apró konfigurációs hibát zavaró hibává tesz.

Egy Fortinet portálcím, például https://vpn.example.com/ext, egyszerre több információt hordoz, és ezek közül csak néhány tartozik a VPN-ügyfélhez.

A végpont és a realm külön bemenet

Az openfortivpn host vagy host:port formájú végpontot vár, valamint fiókot és, ahol a telepítés használ ilyet, realm-értéket. A realm megmondja az átjárónak, melyik hitelesítési szabályzatot alkalmazza a fiók értékelése előtt. Ez külön mező, nem olyan utótag, amelyet az ügyfél egy URL-ből kinyer.

Olyan telepítésnél, amelynek üzemeltetője megerősíti, hogy a realm ext, egy nem titkos hívás így néz ki: openfortivpn vpn.example.com:443 --username=alice --realm=ext. Ugyanezek az értékek a konfigurációs fájlba host, port, username és realm bejegyzésként kerülnek. Hagyja a jelszót mindkét formán kívül, és hagyja, hogy az ügyfél kérje, hogy ne kerüljön a shell-előzményekbe vagy egy mindenki által olvasható fájlba. Egy második próbálkozás, miközben az első ügyfél még tartja az alagutat, olyan okból fog kudarcot vallani, amelynek semmi köze a realmhez.

openfortivpn kézikönyv mindkét lehetőséget felsorolja, így a pontos helyesírás könnyen ellenőrizhető a támogatás hívása előtt. Azt azonban nem tudja megmondani, melyik realm van beállítva az átjárón.

Egy útvonalszegmens nem automatikusan realm

A portál URL-ek mindenfélét gyűjtenek a gazdagépnév után: bejelentkező alkalmazást, nyelvválasztót, átirányítási célt, munkamenet-azonosítót. Az utolsó útvonalszegmens levágása és realmnek nevezése elég gyakran működik ahhoz, hogy veszélyes legyen. Kérdezze meg az üzemeltetőtől a beállított értéket, vagy olvassa ki abból a profilból, amelyet a szervezete terjeszt.

A realm nem ugyanaz, mint a felhasználónév tartomány-utótagja vagy az a régió, ahol az átjáró található. Egyes telepítések alice-et akarnak, mások alice@corp-et, és a realm dönti el, melyiket fogadja el az átjáró. A fiókformátum módosítása egy hibás realm kompenzálására általában egy második, kevésbé informatív elutasítást eredményez.

Ne javítsa a realm-hibát a gazdagép módosításával

A gazdagépnév IP-címre cserélése úgy tűnik, mintha elvennénk egy réteget, és többet ront, mint amennyit javít. A TLS-névellenőrzés a tanúsítványt az ügyfél által használt névhez hasonlítja, és egy IP-cím ritkán szerepel a tanúsítvány alternatív tárgynevei között. A kiszolgálónév-jelzés a címmel együtt változik, ezért előfordulhat, hogy egy címen több portált kiszolgáló átjáró a rosszal válaszol. Tartsa érintetlenül a gazdagépnevet és a bizalmi konfigurációt, miközben a hitelesítési paramétert javítja.

Ha a tanúsítvány nem megbízható a környezetében, javítsa a bizalmi tárolót, vagy szándékosan rögzítse az elvárt tanúsítványt. Az ellenőrzés kikapcsolása egy realm-hiba megkerüléséhez egy bejelentkezési problémát cserél csendes lehallgatási kockázatra.

Különítse el az elutasított bejelentkezést a sikertelen alagúttól

A hitelesítési hibák és az alagúthibák különböző pillanatokban érkeznek, és az üzenetek eltérnek. A névfeloldási hiba minden TLS-kézfogás előtt történik. A TLS-elutasítás a hitelesítő adatok elküldése előtt történik. A realm vagy fiók elutasítása HTTP-szintű válaszként jön vissza a portáltól. Csak e szakaszok után kezdődik a PPP-tárgyalás, és csak akkor jelennek meg az útválasztási és DNS-problémák.

A helyes realm nem hoz létre hiányzó útvonalat, és nem tesz működőképessé egy nem támogatott bejelentkezési módot. Ha a portál ragaszkodik a böngészőalapú folyamathoz, használja az ügyfél által támogatott utat ehhez a folyamathoz, ahelyett hogy megismételné a jelszóváltást és abban bízna, hogy a munkamenet megegyezik.

Tartsa az értékeket ott, ahol a következő indítás megtalálja őket

Amikor egy kapcsolat sikerül, írja az átjárót, a portot, a fiókot és a realm-et a kezelt profilba shell-alias helyett. A tárolóban vagy konfigurációkezelő rendszerben tartott profilok megakadályozzák, hogy a következő indítás csendben egy másik profil realmjét vegye át.

Teszteljen újra egy kapcsolatot elejétől a végéig, és erősítse meg az alkalmazott szabályzatot és egy valóban szükséges erőforráshoz való hozzáférést is. A hitelesítés sikere ezen ellenőrzés kezdete, nem a vége.

Kapcsolódó cikkek