A szerverhez kötött profil meghiúsul egy TLS-proxy mögött: melyik generáció?

Az egyik felhasználó tud csatlakozni, a másik nem, ugyanazon a portálon, ugyanazon a napon. Mindkettőjüknek szerverhez kötött profilja van, mindketten ugyanazon az Access Server builden vannak, és az egyetlen különbség az, hogy mikor generálták a profiljukat. Ez az a minta, amelyet érdemes felismerni, mert a "szerverhez kötött" irányelvet jelöl, nem kapcsolódási sorrendet. Az Access Server ennek az artefaktnak két generációját szállította, és egy TLS fordított proxy csak az egyik útvonaluk előtt áll. Három feltétel dönti el, melyik ágon van.

Két generáció, két kapcsolódási sorrend

A régebbi kialakításban, amely 2.8-ig érvényes, az importált fájl pszeudoprofil. Az OpenVPN Connect ezzel hitelesít az Access Server webes API-ja felé HTTPS-en, ideiglenes felhasználóhoz kötött profilt és munkamenet-tokent kap, és csak ezután építi fel a VPN-t. Két szállító réteg fut egymás után, és az első egy közönséges webkérés.

A 2.9-cel bevezetett formátum nem végzi el ezt a kapcsolatonkénti indítást. Ez egy natív profil, amelyet kompatibilis OpenVPN kliensek használhatnak, nem csak az OpenVPN Connect. Letöltése vagy URL-en keresztüli importálása továbbra is járhat HTTPS-sel — ez közzétételi lépés, nem kapcsolatonkénti ideiglenes profil-lekérés.

A frissítés nem feltétlenül írja át a már kiadott profilokat, ezért egy jelenlegi szerververzió még mindig kiadhatja a régi artefaktot. A szerver buildje azt mondja meg, mi lehetséges, nem azt, hogy ez a felhasználó mit importált.

Három feltétel, amely eldönti az ágát

Az első feltétel az artefakt generációja. Kérje el a fájlt, nézze meg, hogyan készült, és jegyezze fel az importáló kliens verzióját. Ha a fájlból nem tudja megállapítani a generációt, egy tesztfióknak kiadott friss profil megmutatja, mit állít elő a szerver ma, és ez más információ, mint amivel a hibát szenvedő felhasználó rendelkezik.

A második az, hogy az előoldala valójában mit terminál. A TLS-t tehermentesítő hetedik rétegbeli HTTP fordított proxy nem ugyanaz az objektum, mint egy negyedik rétegbeli TCP-továbbító, és egy UDP-továbbító sem az. Az Access Server szokásos elrendezése a 443-as porton arra készteti az OpenVPN TCP démont, hogy felismerje a böngészőforgalmat és átadja a webes szolgáltatásoknak, ezért egy nem kapcsolódó HTTPS-terminátor elé helyezése nem őrzi meg a démon protokollkezelését. A 443-as szám megosztása nem tesz két tervet egyenértékűvé.

A harmadik az, hogy hol landol a hiba. A VPN előtti hiba és a vezérlőcsatorna hibája hasonlónak tűnik egy kliensben, amely csak annyit mond, hogy "csatlakozás", de különböző helyeken hagynak nyomot. Ha a régi formátum van játékban, az indítás a jelölt. Ha az új formátum van játékban, az üres webes hozzáférési napló várható, és semmit nem bizonyít egyik irányban sem.

Amikor az artefakt régi: az indítás hibázik először

A kliens tényleges hibáját olvassa, ne a végállapotát. Az érdekes mezők a HTTPS-hiba, az a kiszolgálóidentitás, amelyet a kliens várt, a cél, ahová a kérés ment, és hogy befejeződött-e a tanúsítvány-ellenőrzés. Ezután vesse össze őket a kiszolgáló oldali webszolgáltatás és proxy naplóival.

Az, hogy egy böngésző eléri a bejelentkező oldalt, nem bizonyítja, hogy ennek a kliensnek az API-hitelesítése sikerült. Ezek különböző kérések, különböző tanúsítvány-elvárásokkal és gyakran különböző hosztnevekkel. Ha a portál megfelelően kiszolgált, és a kliens továbbra is hibázik, az eltérés az indítási útvonalban van, nem a felhasználó jelszavában.

Ne úgy érje el, hogy az összehasonlítás átmenjen, hogy kikapcsolja a TLS-ellenőrzést vagy enyhíti a hitelesítési irányelvet. Ez egy diagnosztizálható konfigurációeltérést működő, de nem ellenőrzött útvonallá alakít, és pontosan ez a változtatás tesz egy ideiglenes tesztet állandó lyukká. A Access Server csatlakozási profilokkal foglalkozó dokumentációja leírja mindkét generációt és az ideiglenes profil folyamatát, és ez a referencia, amelyet ellenőrizni kell, mielőtt azt feltételezné, hogy egy proxy a hibás.

Amikor az artefakt új: inkább a vezérlőcsatornát olvassa

2.9-stílusú profillal a kliens egyenesen a natív VPN-végponthoz megy. Vizsgálja meg a profil végpontjait, a használt szállítót és a vezérlőcsatorna hibáját. Ha a kliens soha nem indít HTTP-kérést, az megfelel a tervezésnek, és nem tünet.

Itt változik a proxy kérdésének formája is. A HTTPS-tehermentesítés nem tud megtörni egy csak TCP-s adatfolyamot, amelyet soha nem lát, de továbbra is megtörheti a profilt közzétevő letöltést, és egy csak TCP-s továbbító egyáltalán nem visz UDP-t. Ellenőrizze, milyen szállítót kér a profil, mielőtt arra következtet, hogy az előoldal lényegtelen.

Az egyetlen adatfolyamra vonatkozó TLS-átvezetés szűk elrendezés. Nem biztosít UDP-továbbítást, és nem reprodukálja a démon saját szolgáltatás-továbbítási viselkedését a 443-on. Ha az előoldala ezek egyikét teszi, mondja meg melyiket, mert a gyógymód eltér.

Szűk maradó megoldások

A legkevésbé zavaró ellenőrzés az, hogy generál egy friss, támogatott profilt egy tesztfióknak, és ugyanazokkal a hitelesítési követelményekkel csatlakozik a szándékolt natív végponthoz. Ha ez működik, a megtartott régi profil pedig nem, akkor egy lépésben elválasztotta az artefaktot a szervertől és a proxytól.

A felhasználóhoz kötött profil terjesztése teljesen megszünteti az örökölt indítási függőséget, mert nincs olyan ideiglenes profilcsere, amely meghiúsulhatna. A szándékolt felhasználónak kell kiadni, soha nem szabad adminisztrátortól másolni, és megváltoztatja, mire jogosult a kliens, ezért irányelvi döntésként kezelje, nem kerülőmegoldásként.

Ezután javítsa ki a közzétételi elrendezést, hogy minden szükséges útvonal létezzen: a webes útvonal a letöltésekhez és a portálhasználathoz, és a natív VPN-útvonal azon a szállítón, amelyet a profilok elvárnak. Tartsa a proxy munkáját egy rétegen. Egy működő, felhasználóhoz kötött alagút bizonyítja, hogy az az útvonal működik; nem bizonyítja, hogy minden proxy-elrendezés minden generációt támogat, és egy régi indítási hiba nem ítéli el az újabb formátumot.

• Azonosítsa az artefakt generációját, mielőtt hozzányúl a proxyhoz.
• Állapítsa meg, hogy a hiba az alagút előtt vagy benne történik-e.
• Erősítse meg, mit terminál az előoldal: HTTP, TCP-adatfolyam vagy UDP.
• Teszteljen egy frissen kiadott profilt a natív végpont ellen, változatlan irányelvvel.