Selhání vypadá jako problém s přihlašovacími údaji: openfortivpn se zeptá na heslo, odešle ho a brána odpoví odmítnutím nebo přesměrováním zpět na přihlašovací stránku. Uživatelé pak heslo zadávají znovu, zkoušejí jméno účtu s doménou a nakonec vloží URL portálu z prohlížeče do pole hostitele. Právě tento poslední krok mění drobnou chybu v konfiguraci v matoucí chybu.

Adresa portálu Fortinet, například https://vpn.example.com/ext, nese několik informací najednou a jen některé z nich patří klientovi VPN.

Koncový bod a realm jsou samostatné vstupy

openfortivpn očekává koncový bod ve tvaru host nebo host:port, dále účet a tam, kde ho nasazení používá, hodnotu realm. Realm říká bráně, jakou zásadu ověřování má použít, než vyhodnotí účet. Je to samostatné pole, nikoli přípona, kterou klient vytáhne z URL.

U nasazení, jehož správce potvrdí, že realm je ext, vypadá volání bez tajemství takto: openfortivpn vpn.example.com:443 --username=alice --realm=ext. Stejné hodnoty patří do konfiguračního souboru jako položky host, port, username a realm. Heslo nechte mimo obě podoby a nechte klienta, aby se na ně zeptal, aby neskončilo v historii shellu nebo v souboru čitelném pro všechny. Druhý pokus, zatímco první klient stále drží tunel, selže z důvodu, který s realm nemá nic společného.

Příručka openfortivpn uvádí obě volby, takže přesný pravopis lze snadno ověřit před voláním podpory. Nemůže vám ale říct, který realm je na vaší bráně nastaven.

Segment cesty není automaticky realm

URL portálů shromažďují po názvu hostitele ledacos: přihlašovací aplikaci, přepínač jazyka, cíl přesměrování, identifikátor relace. Odříznout poslední segment cesty a nazvat ho realm funguje dost často na to, aby to bylo nebezpečné. Zeptejte se správce na nastavenou hodnotu nebo ji přečtěte z profilu, který vaše organizace distribuuje.

Realm také není totéž co přípona domény ve jménu uživatele nebo oblast, ve které brána sídlí. Některá nasazení chtějí alice, jiná chtějí alice@corp, a realm rozhoduje, kterou z nich brána přijme. Změna formátu účtu, která má vykompenzovat špatný realm, obvykle přinese druhé, méně informativní odmítnutí.

Neopravujte chybu realmu změnou hostitele

Nahrazení názvu hostitele IP adresou vypadá jako odebrání vrstvy a rozbije víc, než opraví. Ověření názvu v TLS porovnává certifikát s názvem, který klient použil, a IP adresa se v alternativních jménech subjektu certifikátu objevuje jen zřídka. Indikace názvu serveru se s adresou mění, takže brána hostující několik portálů na jedné adrese může odpovědět tím špatným. Zachovejte název hostitele i konfiguraci důvěry beze změny, dokud opravujete parametr ověřování.

Pokud certifikát ve vašem prostředí není důvěryhodný, opravte úložiště důvěry nebo očekávaný certifikát vědomě připněte. Vypnutí ověření, aby se obešla chyba realmu, vyměňuje problém s přihlášením za riziko tichého zachycení.

Oddělte odmítnuté přihlášení od neúspěšného tunelu

Selhání ověřování a selhání tunelu přicházejí v různých okamžicích a zprávy se liší. Chyba překladu názvu nastane před jakýmkoli TLS handshake. Odmítnutí TLS nastane před odesláním údajů. Odmítnutí realmu nebo účtu se vrací jako odpověď na úrovni HTTP od portálu. Teprve po těchto fázích začíná vyjednávání PPP a teprve tehdy se objevují problémy se směrováním a DNS.

Správný realm nevytváří chybějící trasu a nezpůsobí, že nepodporovaný způsob přihlášení bude fungovat. Pokud portál trvá na toku v prohlížeči, použijte pro tento tok klientem podporovanou cestu, místo abyste opakovali výměnu hesla a doufali, že relace bude odpovídat.

Uchovejte hodnoty tam, kde je najde příští spuštění

Jakmile spojení uspěje, zapište bránu, port, účet a realm do spravovaného profilu místo aliasu v shellu. Profily uložené v repozitáři nebo v systému správy konfigurace zabrání tomu, aby příští spuštění tiše převzalo realm jiného profilu.

Znovu otestujte jedno spojení od začátku do konce a potvrďte jak uplatněnou zásadu, tak přístup ke zdroji, který skutečně potřebujete. Úspěšné ověření je začátek této kontroly, ne její konec.

Související články