Az OpenConnect bejelentkezés rossz oldalra fut ki? Először az útvonalat ellenőrizze

Beilleszti a címet az induló e-mailből, az ügyfél eléri az átjárót, és a megjelenő bejelentkezési űrlap az általános portál, nem pedig a partnerportál, amelyet az üzemeltető leírt. Semmi nem jelez hibát, és éppen ez a zavaró: az alagút akár fel is jöhet, csak éppen a rossz belépési pont mögött. Az az útvonal munkát végzett, és bármi is váltotta fel, elejtette azt a munkát.

Válasszon ketté két dolgot, amely egyetlen karakterláncként érkezik egy jegyben: a címet, amely eléri a szolgáltatást, és a bemenetet, amely eldönti, hol kezdődik a hitelesítés. Az elsőt megjavítani a második figyelmen kívül hagyásával az az út, ahogyan egy helyes gazdanév mégis rossz bejelentkezést ad.

Mit küld az ügyfél, mielőtt űrlapot látna

Egy https://vpn.example.net/partners típusú címmel az ügyfél első tette HTTPS-kérés erre az útvonalra, nem pedig a csupasz gazdagépre. Ami visszajön, általában átirányítás a bejelentkezési végpontra, vagy maga az űrlap. Az az ügyfél, amely csak vpn.example.net-et kap, az éppen érvényes alapértelmezett nyitóoldalon indul, és ez lehet másik portál, másik csoportlista vagy egy oldal, amely teljesen más protokollt vár. A különbség jóval azelőtt látszik a válaszfejlécekben, hogy bármilyen hitelesítő adat beírásra kerülne.

Ezért nevezheti meg ugyanazt az átjárót egy működő böngészőfül és egy meghiúsuló ügyfélprofil, és mégis ellentmondhatnak egymásnak. A böngésző követte az útvonalat; a profilnak soha nem volt meg.

Két bemenet, amely felcserélhetőnek látszik, és nem az

Az OpenConnect a kezdeti HTTPS-útvonalat --usergroup néven teszi elérhetővé, és a kézikönyv oldala az ilyen útvonalat hordozó teljes URL-t ugyanazon kérés másképp írt formájaként kezeli. A --authgroup külön beállítás: egy bejegyzést választ abból a listából, amelyet az átjáró a bejelentkezési űrlapon belül mutat. Egyes protokollok ezt a bejegyzést csoportnak, mások tartománynak vagy átjárónak nevezik, és pontosan itt keveredik össze a két kapcsoló.

Egy szolgáltatásnak jogosan lehet szüksége mindkettőre. Az útvonal a megfelelő portálra viheti, miközben az űrlap még mindig arra kér, hogy azon belül csoportok közül válasszon. A portál nevét csoportnévként megadni, vagy fordítva, olyan bejelentkezést eredményez, amely elfogadottnak látszik, majd nem engedélyez, mert az érték szintaktikailag érvényes és szemantikailag hibás volt.

Kérje meg az üzemeltetőt, hogy minden értéket külön sorban adjon meg: belépési útvonal, űrlapválasztás, és hogy mindkettő szükséges-e. Ne vezesse le az egyiket a másikból, csak mert a címkék hasonlóan hangzanak.

Miért változtatja meg az útvonal levágása az eredményt

A csak gazdagépet és portot elfogadó ügyfelek gyakran mégis csatlakoznak, ezért a tünet ritkán kemény hiba. Helyette rossz bejelentkezési oldalt, üres csoportlistát, olyan tanúsítványnevet kap, amely már nem egyezik azzal, amit az üzemeltető közzétett, vagy olyan alagutat, amely a kívánt szolgáltatás felé vezető útvonal nélkül jön fel. Mindegyikük más rétegen ül, és egyiket sem javítja meg egy hosszabb karakterlánc beillesztése egy gazdanévként dokumentált mezőbe. Kettő közülük kívülről sem megkülönböztethető, mivel mindkettő olyan bejelentkezési űrlapként érkezik, amely egyszerűen nem folytatódik.

A gazdanév IP-címre cserélése külön hiba, amely gyakran ezzel együtt utazik. A névalapú szolgáltatásválasztás és a tanúsítvány-érvényesítés egyaránt a névtől függ, ezért egy numerikus cím az útvonalformátum problémáját TLS-hibává alakíthatja.

A böngészőcímek az útvonalaknál is többet hordoznak. A munkamenet-azonosítók, az átirányítási célok, a nyelvi előtagok és az ideiglenes bejelentkezési paraméterek mind megjelennek a címsorban, és egyik sem tartozik egy mentett ügyfélprofilba.

Erősítse meg a belépési pontot, mielőtt bármi mást szerkesztene

Olvassa el a kapott útvonal fejléceit. Egy curl -sS -o /dev/null -D - https://vpn.example.net/partners típusú kérés kiírja az állapotsort és minden Location fejlécet anélkül, hogy követné az átirányítást. A megnevezett bejelentkezési végpontra mutató 302 megerősíti, hogy az útvonal létezik, és megmutatja, hová vezet; a 404 azt jelenti, hogy az üzemeltető címe elavult.

Ezután reprodukálja ugyanazt a belépési pontot a jóváhagyott ügyfélben, például openconnect --usergroup=partners vpn.example.net, és figyelje, melyik űrlap jelenik meg. Ha az űrlap helyes, és az alagút mégis meghiúsul, az útvonal soha nem volt a probléma, és a következő állomás a szabályzat vagy az útválasztás.

Rögzítse a gazdanevet, a portot, a protokollt, a belépési útvonalat és az űrlapválasztást öt külön mezőként a jegyben. Ez a lista teszi lehetővé a következő mérnök számára, hogy megkülönböztessen egy elérhetetlen kiszolgálót egy TLS-elutasítástól, egy elutasított választástól és egy olyan alagúttól, amely a szükséges útvonalak nélkül jött fel.