Profil zaključan na server ne uspijeva iza TLS proxyja: koja generacija?

Jedan korisnik se može povezati, a drugi ne, kroz isti portal, istog dana. Oba imaju profile zaključane na server, oba su na istoj verziji Access Servera, a jedina razlika je kada je njihov profil generisan. To je obrazac koji vrijedi prepoznati, jer "zaključan na server" označava politiku, a ne redoslijed povezivanja. Access Server je isporučio dvije generacije tog artefakta, a TLS obrnuti proxy stoji samo ispred jedne od njihovih putanja. Tri uslova odlučuju na kojoj ste grani.

Dvije generacije, dva redoslijeda povezivanja

U starijem dizajnu, važećem do 2.8, uvezeni fajl je pseudo-profil. OpenVPN Connect ga koristi za autentifikaciju prema web API-ju Access Servera preko HTTPS-a, prima privremeni profil zaključan na korisnika i sesijski token, i tek tada uspostavlja VPN. Dva transporta rade uzastopno, a prvi je običan web zahtjev.

Format uveden s 2.9 ne izvodi to početno podizanje za svaku vezu. To je izvorni profil koji mogu koristiti kompatibilni OpenVPN klijenti, ne samo OpenVPN Connect. Njegovo preuzimanje ili uvoz putem URL-a još uvijek može uključivati HTTPS — to je korak objavljivanja, a ne dohvatanje privremenog profila za svaku vezu.

Nadogradnja ne mora prepisati profile koji su već izdati, pa trenutna verzija servera još uvijek može dijeliti stari artefakt. Verzija servera vam kaže šta je moguće, a ne šta je ovaj korisnik uvezao.

Tri uslova koja biraju vašu granu

Prvi uslov je generacija artefakta. Zatražite fajl, pogledajte kako je proizveden i zabilježite verziju klijenta koja ga je uvezla. Ako ne možete utvrditi generaciju iz fajla, svježi profil izdat za testni račun reći će vam šta server danas proizvodi, što je drugačija informacija od one koju ima korisnik kod kojeg dolazi do kvara.

Drugi je šta vaš frontend zapravo terminira. HTTP obrnuti proxy sedmog sloja koji rasterećuje TLS nije isti objekat kao TCP prosljeđivač četvrtog sloja, a ni UDP prosljeđivač. Uobičajeni raspored Access Servera na portu 443 navodi OpenVPN TCP demon da prepozna saobraćaj preglednika i preda ga web servisima, pa umetanje nepovezanog HTTPS terminatora ispred ne čuva obradu protokola tog demona. Dijeljenje broja 443 ne čini dva dizajna ekvivalentnim.

Treći je gdje kvar završava. Kvar prije VPN-a i kvar kontrolnog kanala izgledaju slično u klijentu koji samo kaže "povezivanje", ali ostavljaju tragove na različitim mjestima. Ako je stari format u igri, početno podizanje je kandidat. Ako je novi format u igri, prazan web dnevnik pristupa je očekivan i ne dokazuje ništa ni u jednu stranu.

Kada je artefakt star: početno podizanje prvo pada

Čitajte stvarnu grešku klijenta, a ne njegovo konačno stanje. Zanimljiva polja su greška HTTPS-a, identitet servera koji je klijent očekivao, odredište na koje je zahtjev otišao i da li je provjera certifikata završena. Zatim ih uporedite s dnevnicima web servisa i proxyja na strani servera.

To što preglednik dosegne stranicu za prijavu nije dokaz da je autentifikacija ovog klijenta preko API-ja uspjela. To su različiti zahtjevi, s različitim očekivanjima certifikata i često različitim imenima hostova. Ako se portal ispravno poslužuje, a klijent i dalje pada, neslaganje je na putu početnog podizanja, ne u korisničkoj lozinci.

Ne činite poređenje uspješnim isključivanjem TLS provjere ili popuštanjem politike autentifikacije. To pretvara diagnozabilno neslaganje konfiguracije u putanju koja radi ali nije provjerena, i upravo ta promjena pretvara privremeni test u trajnu rupu. Dokumentacija Access Servera o profilima za povezivanje opisuje obje generacije i tok privremenog profila, i to je referenca koju treba provjeriti prije nego pretpostavite da je proxy kriv.

Kada je artefakt nov: čitajte kontrolni kanal

S profilom u stilu 2.9 klijent ide ravno na izvornu VPN krajnju tačku. Istražite krajnje tačke u profilu, transport koji se koristi i grešku kontrolnog kanala. Ako klijent nikada ne uputi HTTP zahtjev, to je u skladu s dizajnom, a ne simptom.

Tu i pitanje proxyja mijenja oblik. HTTPS rasterećenje ne može slomiti tok samo preko TCP-a koji nikada ne vidi, ali još uvijek može slomiti preuzimanje koje objavljuje profil, a prosljeđivač samo preko TCP-a uopće neće prenositi UDP. Provjerite koji transport profil traži prije nego zaključite da je frontend nevažan.

TLS prosljeđivanje za jedan tok je uska postavka. Ono ne pruža UDP prosljeđivanje i ne reprodukuje ponašanje demona pri prosljeđivanju servisa na 443. Ako vaš frontend radi jedno od toga, recite koje, jer lijek je drugačiji.

Lijekovi koji ostaju uski

Najmanje invazivna provjera je generisati svježi podržani profil za testni račun i povezati se preko predviđene izvorne krajnje tačke uz iste zahtjeve autentifikacije. Ako to radi, a zadržani stari profil ne radi, odvojili ste artefakt od servera i od proxyja u jednom koraku.

Distribucija profila zaključanog na korisnika uklanja naslijeđenu zavisnost od početnog podizanja u potpunosti, jer nema razmjene privremenog profila koja može pasti. Mora biti izdat za predviđenog korisnika, nikada kopiran od administratora, i mijenja šta je klijent ovlašten da radi, pa ga tretirajte kao odluku o politici, a ne kao zaobilazno rješenje.

Zatim popravite raspored objavljivanja tako da postoji svaka potrebna putanja: web putanja za preuzimanja i korištenje portala, i izvorna VPN putanja na transportu koji profili očekuju. Držite posao proxyja na jednom sloju. Tunel zaključan na korisnika koji radi dokazuje da ta putanja radi; ne dokazuje da svaki raspored proxyja podržava svaku generaciju, a kvar starog početnog podizanja ne osuđuje noviji format.

• Utvrdite generaciju artefakta prije nego dirate proxy.
• Utvrdite da li se kvar javlja prije tunela ili unutar njega.
• Potvrdite šta frontend terminira: HTTP, TCP tok ili UDP.
• Testirajte svježe izdat profil prema izvornoj krajnjoj tački s nepromijenjenom politikom.