Profil, zaklenjen na strežnik, ne uspe za posredovalnim strežnikom TLS: katera generacija?

En uporabnik se lahko poveže, drugi pa ne, skozi isti portal, na isti dan. Oba imata profile, zaklenjene na strežnik, oba sta na isti graditvi Access Serverja, in edina razlika je, kdaj je bil njun profil ustvarjen. To je vzorec, ki se ga je vredno naučiti prepoznati, ker "zaklenjen na strežnik" poimenuje politiko in ne zaporedja povezave. Access Server je dostavil dve generaciji tega artefakta, obratni posredovalni strežnik TLS pa stoji pred samo eno od njunih poti. Trije pogoji odločajo, na kateri veji ste.

Dve generaciji, dve zaporedji povezave

V starejši zasnovi, veljavni do 2.8, je uvožena datoteka psevdoprofil. OpenVPN Connect jo uporabi za overjanje pri spletnem API-ju Access Serverja prek HTTPS, prejme začasni profil, zaklenjen na uporabnika, in žeton seje, in šele nato vzpostavi VPN. Dva prenosa tečeta zaporedno, prvi pa je običajna spletna zahteva.

Oblika, uvedena z 2.9, te zagonske priprave na posamezno povezavo ne izvede. To je izvorni profil, ki ga lahko uporabljajo združljivi OpenVPN odjemalci, ne samo OpenVPN Connect. Njegov prenos ali uvoz prek URL-ja lahko še vedno vključuje HTTPS — to je korak objave, ne pridobivanje začasnega profila na posamezno povezavo.

Nadgradnja ne prepiše nujno že izdanih profilov, zato lahko trenutna različica strežnika še vedno izdaja stari artefakt. Graditev strežnika vam pove, kaj je mogoče, ne pa, kaj je ta uporabnik uvozil.

Trije pogoji, ki izberejo vašo vejo

Prvi pogoj je generacija artefakta. Zahtevajte datoteko, poglejte, kako je nastala, in zabeležite različico odjemalca, ki jo je uvozil. Če generacije iz datoteke ne morete ugotoviti, vam bo svež profil, izdan za preizkusni račun, povedal, kaj strežnik proizvaja danes, in to so drugačne informacije od tistih, ki jih ima uporabnik, pri katerem prihaja do napake.

Drugi je, kaj vaš čelni del dejansko zaključi. Obratni posredovalni strežnik HTTP sedmega sloja, ki razbremeni TLS, ni isti objekt kot posredovalnik TCP četrtega sloja, in posredovalnik UDP prav tako ne. Običajna postavitev Access Serverja na vratih 443 povzroči, da demonski proces OpenVPN TCP prepozna promet brskalnika in ga preda spletnim storitvam, zato vstavljanje nepovezanega zaključevalnika HTTPS spredaj ne ohrani obdelave protokola tega demonskega procesa. Skupna številka 443 ne naredi dveh zasnov enakovrednih.

Tretji je, kje napaka pristane. Napaka pred VPN in napaka krmilnega kanala sta v odjemalcu, ki pravi samo "povezovanje", videti podobni, a puščata dokaze na različnih mestih. Če je v igri stara oblika, je zagonska priprava kandidat. Če je v igri nova oblika, je prazen dnevnik spletnega dostopa pričakovan in ne dokaže ničesar v nobeno smer.

Ko je artefakt star: zagonska priprava ne uspe prva

Berite dejansko napako odjemalca, ne njegovega končnega stanja. Zanimiva polja so napaka HTTPS, identiteta strežnika, ki jo je odjemalec pričakoval, cilj, kamor je šla zahteva, in ali se je preverjanje potrdila končalo. Nato jih primerjajte z dnevniki spletne storitve in posredovalnega strežnika na strežniški strani.

To, da brskalnik doseže prijavno stran, ni dokaz, da je overjanje API-ja tega odjemalca uspelo. To so različne zahteve, z različnimi pričakovanji glede potrdila in pogosto različnimi imeni gostiteljev. Če je portal pravilno postrežen in odjemalec še vedno ne uspe, je neskladje na poti zagonske priprave, ne v uporabnikovem geslu.

Ne dosezite uspešne primerjave z izklopom preverjanja TLS ali z omilitvijo politike overjanja. To spremeni diagnosticirano neskladje konfiguracije v pot, ki deluje, a ni preverjena, in prav ta sprememba spremeni začasni preizkus v trajno luknjo. Dokumentacija Access Serverja o profilih povezave opisuje obe generaciji in potek začasnega profila, in to je referenca, ki jo je treba preveriti, preden domnevate, da je kriv posredovalni strežnik.

Ko je artefakt nov: berite krmilni kanal

S profilom v slogu 2.9 gre odjemalec naravnost na izvorno končno točko VPN. Raziščite končne točke v profilu, uporabljeni prenos in napako krmilnega kanala. Če odjemalec nikoli ne izda zahteve HTTP, je to skladno z zasnovo in ni simptom.

Tu se tudi vprašanje posredovalnega strežnika spremeni. Razbremenitev HTTPS ne more zlomiti toka samo po TCP, ki ga nikoli ne vidi, lahko pa še vedno zlomi prenos, ki objavlja profil, in posredovalnik samo po TCP sploh ne bo prenesel UDP. Preverite, kateri prenos zahteva profil, preden sklenete, da čelni del ni pomemben.

Prehod TLS za en sam tok je ozka postavitev. Ne zagotavlja posredovanja UDP in ne poustvari lastnega vedenja demonskega procesa pri posredovanju storitev na 443. Če vaš čelni del počne eno od tega, povejte katero, ker je zdravilo drugačno.

Zdravila, ki ostanejo ozka

Najmanj invaziven pregled je ustvariti svež podprt profil za preizkusni račun in se povezati prek predvidene izvorne končne točke z enakimi zahtevami za overjanje. Če to deluje in shranjeni stari profil ne, ste artefakt ločili od strežnika in od posredovalnega strežnika v enem koraku.

Razširjanje profila, zaklenjenega na uporabnika popolnoma odpravi odvisnost od stare zagonske priprave, ker ni izmenjave začasnega profila, ki bi lahko spodletela. Izdati ga je treba predvidenemu uporabniku, nikoli ga ne kopirati od skrbnika, in spreminja, kaj je odjemalec pooblaščen, zato ga obravnavajte kot odločitev o politiki in ne kot obvoz.

Nato popravite postavitev objave, tako da obstaja vsaka potrebna pot: spletna pot za prenose in uporabo portala ter izvorna pot VPN na prenosu, ki ga profili pričakujejo. Delo posredovalnega strežnika naj ostane na enem sloju. Delujoč tunel, zaklenjen na uporabnika, dokazuje, da ta pot deluje; ne dokazuje, da vsaka postavitev posredovalnega strežnika podpira vsako generacijo, in napaka stare zagonske priprave ne obsodi novejše oblike.

• Ugotovite generacijo artefakta, preden se dotaknete posredovalnega strežnika.
• Ugotovite, ali napaka nastane pred tunelom ali v njem.
• Potrdite, kaj čelni del zaključi: HTTP, tok TCP ali UDP.
• Preizkusite sveže izdan profil proti izvorni končni točki z nespremenjeno politiko.