Zerbitzarira lotutako profila TLS proxy baten atzean huts egiten du: zein belaunaldi?
Access Server 2.8 eta 2.9 bertsioek zerbitzarira lotutako profilak modu ezberdinean eraikitzen dituzte. Erabaki zure proxyak zein bide hausten duen frontend-a aldatu aurretik.
Erabiltzaile batek konektatu dezake eta beste batek ez, portal beretik, egun berean. Biek dute zerbitzarira lotutako profila, biak Access Server beraren eraikuntza berean daude, eta desberdintasun bakarra haien profila noiz sortu zen da. Hori da ezagutzea merezi duen eredua, "zerbitzarira lotuta" politika bat izendatzen duelako eta ez konexio-sekuentzia bat. Access Serverrek artefaktu horren bi belaunaldi eman ditu, eta TLS alderantzizko proxy bat haien bideetako baten aurrean soilik dago. Hiru baldintzek erabakitzen dute zein adarretan zauden.
Bi belaunaldi, bi konexio-sekuentzia
Diseinu zaharrean, 2.8ra arte indarrean, inportatutako fitxategia sasiprofil bat da. OpenVPN Connectek HTTPS bidez Access Serverren web APIaren aurrean autentifikatzeko erabiltzen du, aldi baterako erabiltzailera lotutako profila eta saio-token bat jasotzen ditu, eta orduan soilik ezartzen du VPNa. Bi garraiok sekuentzian egiten dute lan, eta lehena web eskaera arrunta da.
2.9 bertsioarekin sartutako formatuak ez du konexio bakoitzeko hasieratze hori egiten. Profil natibo bat da, erabil dezaketena OpenVPN bezero bateragarriek, ez OpenVPN Connectek bakarrik. Hura deskargatzeak edo URL bidez inportatzeak HTTPSa ekar dezake oraindik — hori argitaratze-urrats bat da, ez konexio bakoitzeko aldi baterako profil baten bilketa.
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
Berritze batek ez ditu nahitaez berridazten jada emandako profilak, beraz uneko zerbitzari-bertsio batek artefaktu zaharra banatzen jarrai dezake. Zerbitzariaren eraikuntzak zer den posible esaten dizu, ez erabiltzaile honek zer inportatu zuen.
Zure adarra hautatzen duten hiru baldintza
Lehen baldintza artefaktuaren belaunaldia da. Eskatu fitxategia, begiratu nola sortu zen, eta idatzi inportatu zuen bezeroaren bertsioa. Fitxategitik belaunaldia zehaztu ezin baduzu, probako kontu baterako emandako profil berri batek esango dizu zerbitzariak gaur zer sortzen duen, eta hori huts egiten duen erabiltzaileak duen informaziotik ezberdina da.
Bigarrena zure frontend-ak benetan zer amaitzen duen da. TLSa deskargatzen duen zazpigarren geruzako HTTP alderantzizko proxy bat ez da laugarren geruzako TCP birbidaltzaile bat bezalako objektu bera, eta UDP birbidaltzailea ere ez. Access Serverren ohiko antolamenduak 443 portuan OpenVPN TCP daimonak nabigatzailearen trafikoa ezagutu eta web zerbitzuei ematen die, beraz aurretik zerikusirik ez duen HTTPS amaitzaile bat sartzeak ez du daimon horren protokolo-trataera mantentzen. 443 zenbakia partekatzeak ez ditu bi diseinu baliokide egiten.
Hirugarrena hutsa non gertatzen den da. VPNa baino lehenagoko huts batek eta kontrol-kanaleko huts batek antzeko itxura dute "konektatzen" soilik esaten duen bezero batean, baina frogak leku ezberdinetan uzten dituzte. Formatu zaharra martxan bada, hasieratzea da hautagai. Formatu berria martxan bada, web sarbide-erregistro huts bat espero da eta ez du ezer frogatzen inolako norabidetan.
Artefaktua zaharra denean: hasieratzeak lehenengo huts egiten du
Irakurri bezeroaren benetako errorea, haren azken egoera beharrean. Eremu interesgarriak HTTPS errorea, bezeroak espero zuen zerbitzari-nortasuna, eskaerak jo zuen helmuga, eta ziurtagiriaren balidazioa osatu zen ala ez dira. Gero alderatu horiek zerbitzari aldeko web zerbitzuaren eta proxyaren erregistroekin.
Nabigatzaile batek saioa hasteko orrialdea heltzeak ez du frogatzen bezero honen API autentifikazioak arrakasta izan duenik. Eskaera ezberdinak dira, ziurtagiri-itxaropen ezberdinekin eta askotan host-izen ezberdinekin. Ataria behar bezala zerbitzatzen bada eta bezeroak oraindik huts egiten badu, desadostasuna hasieratze-bidean dago, ez erabiltzailearen pasahitzan.
Ez egin konparazioa gainditzen TLS egiaztapena desgaituta edo autentifikazio-politika arinduta. Horrek diagnostika daitekeen konfigurazio-desadostasuna funtzionatzen duen baina egiaztatu gabeko bide bihurtzen du, eta aldaketa horixe da aldi baterako proba zulo iraunkor bihurtzen duena. Access Serverren konexio-profilei buruzko dokumentazioa bi belaunaldiak eta aldi baterako profilaren fluxua deskribatzen ditu, eta proxy bat erruduntzat jo aurretik egiaztatu beharreko erreferentzia da.
Artefaktua berria denean: irakurri kontrol-kanala
2.9 estiloko profil batekin, bezeroa zuzenean VPNaren amaiera-puntu natibora doa. Ikertu profileko amaiera-puntuak, erabiltzen den garraioa eta kontrol-kanaleko errorea. Bezeroak inoiz HTTP eskaerarik egiten ez badu, hori diseinuarekin bat dator eta ez da sintoma bat.
Hemen ere proxy galderak forma aldatzen du. HTTPS deskargak ezin du inoiz ikusten ez duen TCP soilikako fluxu bat hautsi, baina profilak argitaratzen dituen deskarga hauts dezake oraindik, eta TCP soilikako birbidaltzaileak ez du UDPa bat ere eramango. Egiaztatu profilak zein garraio eskatzen duen frontend-a garrantzirik gabea dela ondorioztatu aurretik.
Fluxu bakar baterako TLS pasabidea antolamendu estua da. Ez du UDP birbidalketarik eskaintzen, eta ez du daimonak 443 portuan duen zerbitzu-birbidalketa jokabidea erreproduzitzen. Zure frontend-ak horietako bat egiten badu, esan zein, sendagaia ezberdina delako.
Estu geratzen diren konponbideak
Esku-hartze gutxien duen egiaztapena probako kontu baterako onartutako profil berri bat sortzea eta ezarritako amaiera-puntu natibora autentifikazio-baldintza berberekin konektatzea da. Horrek funtzionatzen badu eta gordetako profil zaharrak ez, artefaktua zerbitzaritik eta proxytik urrats bakarrean bereizi duzu.
Erabiltzailera lotutako profilaren banaketa zaharkitutako hasieratze-mendekotasuna erabat kentzen du, ez baitago huts egin dezakeen aldi baterako profil-trukerik. Ezarritako erabiltzailearentzat eman behar da, inoiz ez administratzaile batengandik kopiatu, eta bezeroak egiteko baimena duena aldatzen du, beraz tratatu politika-erabaki gisa eta ez behin-behineko irtenbide gisa.
Gero konpondu argitaratze-antolamendua beharrezko bide bakoitza existi dadin: web bidea deskargetarako eta atariaren erabilerarako, eta VPN bide natiboa profilek espero duten garraioan. Eutsi proxyaren lana geruza bakarrean. Funtzionatzen duen erabiltzailera lotutako tunelak bide horrek funtzionatzen duela frogatzen du; ez du frogatzen proxy antolamendu bakoitzak belaunaldi bakoitza onartzen duenik, eta hasieratze-huts zahar batek ez du formatu berriagoa gaitzesten.
- Zehaztu artefaktuaren belaunaldia proxya ukitu aurretik.
- Zehaztu hutsa tunelaren aurretik edo haren barruan gertatzen den.
- Baieztatu frontend-ak zer amaitzen duen: HTTP, TCP fluxua edo UDP.
- Probatu berriki emandako profil bat amaiera-puntu natiboaren aurka politika aldatu gabe.