Serverbûn profyl mislearret efter in TLS-proxy: hokker generaasje?
Access Server 2.8 en 2.9 bouwe serverbûne profilen oars. Bepale hokker paad jo proxy brekt foardat jo it front-end feroarje.
Ien brûker kin ferbine en in oar net, fia itselde portaal, op deselde dei. Beide hawwe serverbûne profilen, beide binne op deselde Access Server-bou, en it iennichste ferskil is wannear't harren profyl oanmakke is. Dat is it patroan dat it wurdich is om te herkennen, want "serverbûn" neamt in belied en net in ferbiningssekwinsje. Access Server hat twa generaasjes fan dat artefakt levere, en in TLS-omkearde proxy stiet foar mar ien fan harren paden. Trije betingsten beslisse yn hokker tûke jo binne.
Twa generaasjes, twa ferbiningssekwinsjes
Yn it âldere ûntwerp, jildich oant 2.8, is it ymporteare bestân in pseudo-profyl. OpenVPN Connect brûkt it om him oer HTTPS by de web-API fan Access Server te autentisearjen, krijt in tydlik brûkersbûn profyl en in sesjetoken, en makket pas dêrnei de VPN oan. Twa transporten rinne efterinoar, en it earste is in gewoane webfersyk.
It formaat dat mei 2.9 yntrodusearre is, docht dy opstart per ferbining net. It is in natif profyl dat brûkt wurde kin troch kompatibele OpenVPN kliïnten, net allinnich troch OpenVPN Connect. It downloade of ymportearjen fia URL kin noch HTTPS omfetsje — dat is in publikaasjestap, net it opheljen fan in tydlik profyl per ferbining.
| 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 |
In upgrade skriuwt al útjûne profilen net needsaaklik oer, dat in aktuele serverferzje kin noch it âlde artefakt útjaan. De serverbou fertelt jo wat mooglik is, net wat dizze brûker ymportearre hat.
Trije betingsten dy't jo tûke kieze
De earste betingst is de generaasje fan it artefakt. Freegje it bestân op, sjoch hoe't it makke is, en notearje de kliïntferzje dy't it ymportearre hat. As jo de generaasje net út it bestân fêststelle kinne, sil in nij profyl dat foar in testaccount útjûn is jo fertelle wat de server hjoed produsearret, en dat is oare ynformaasje as dy't de mislearjende brûker hat.
De twadde is wat jo front-end eins beëiniget. In HTTP-omkearde proxy op laach sân dy't TLS ôflaadt is net itselde objekt as in TCP-trochstjoerder op laach fjouwer, en in UDP-trochstjoerder ek net. De gewoane regeling fan Access Server op poarte 443 lit de OpenVPN TCP-daemon browserferkear werkenne en oan de websjinsten jaan, dat in net-relatearre HTTPS-beëiniger foaroan pleatse behâldt de protokolbehanneling fan dy daemon net. It dielen fan it nûmer 443 makket twa ûntwerpen net lykweardich.
De tredde is wêr't de mislearring telâne komt. In mislearring foar de VPN en in mislearring fan it kontrôlekanaal lykje op inoar yn in kliïnt dy't allinnich "ferbynt" seit, mar se litte bewiis op ferskate plakken efter. As it âlde formaat yn spiel is, is de opstart in kandidaat. As it nije formaat yn spiel is, is in leech webtagongslokboek ferwachte en bewiist it neat yn ien fan beide rjochtingen.
As it artefakt âld is: de opstart mislearret earst
Lês de werklike flater fan 'e kliïnt ynstee fan syn einstatus. De nijsgjirrige fjilden binne de HTTPS-flater, de serveridentiteit dy't de kliïnt ferwachte, de bestimming dêr't it fersyk hinne gie, en oft de sertifikaatfalidaasje foltôge is. Ferlykje se dêrnei mei de logboeken fan de websjinst en de proxy oan 'e serverkant.
Dat in browser de oanmeldside berikt is gjin bewiis dat de API-autentikaasje fan dizze kliïnt slagge is. It binne ferskate fersiken, mei ferskate sertifikaatferwachtings en faaks ferskate hostnammen. As it portaal korrekt betsjinne wurdt en de kliïnt mislearret noch, dan leit it skeel yn it opstartpaad, net yn it wachtwurd fan 'e brûker.
Meitsje de ferliking net slagge troch TLS-ferifikaasje út te skeakeljen of it autentikaasjebelied te fersêftsjen. Dat feroaret in diagnoazeare konfiguraasje-ôfwiking yn in paad dat wurket mar net ferifiearre is, en it is krekt dy feroaring dy't in tydlike test yn in permanint gat feroaret. De Access Server-dokumintaasje oer ferbindingsprofilen beskriuwt beide generaasjes en de stream fan it tydlike profyl, en it is de referinsje om te kontrolearjen foardat jo oannimme dat in proxy skuldich is.
As it artefakt nij is: lês dan it kontrôlekanaal
Mei in profyl yn 2.9-styl giet de kliïnt streekrjocht nei it natife VPN-einpunt. Undersykje de einpunten yn it profyl, it transport dat brûkt wurdt, en de flater fan it kontrôlekanaal. As de kliïnt nea in HTTP-fersyk docht, is dat yn oerienstimming mei it ûntwerp en net in symptoom.
Hjir feroaret de proxy-fraach ek fan foarm. In HTTPS-ôflaai kin in stream dy't allinnich TCP is net brekke, om't er dy nea sjocht, mar it kin noch wol de download brekke dy't it profyl publisearret, en in trochstjoerder dy't allinnich TCP is sil UDP hielendal net drage. Kontrolearje hokker transport it profyl freget foardat jo konkludearje dat it front-end net fan belang is.
TLS-trochgong foar ien stream is in nauwe regeling. It biedt gjin UDP-trochstjoering en it reprodusearret it eigen tsjinsttrochstjoergedrach fan 'e daemon op 443 net. As jo front-end ien fan dy dingen docht, sis hokker, want it remedial ferskilt.
Remedys dy't nau bliuwe
De minst yngeande kontrôle is om in nij stipe profyl foar in testaccount oan te meitsjen en fia it bedoelde natife einpunt te ferbinen mei deselde autentikaasjeeasken. As dat wurket en it bewarre âlde profyl net, dan hawwe jo it artefakt yn ien stap fan 'e server en fan 'e proxy skieden.
De fersprieding fan in brûkersbûn profyl hellet de ferâldere opstartôfhinklikheid hielendal fuort, want der is gjin útwikseling fan in tydlik profyl dy't mislearje kin. It moat foar de bedoelde brûker útjûn wurde, nea fan in administrateur kopiearre, en it feroaret wat de kliïnt autorisearre is te dwaan, behannelje it dêrom as in beliedsbeslissing en net as in omgong.
Reparearje dan de publikaasje-yndieling sadat elk fereaske paad bestiet: it webpaad foar downloads en portaalbebrûk, en it natife VPN-paad op it transport dat de profilen ferwachtsje. Hâld it wurk fan 'e proxy op ien laach. In wurkjende brûkersbûne tunnel bewiist dat dat paad wurket; it bewiist net dat elke proxy-regeling elke generaasje stipet, en in âlde opstartflater feroardielet it nijere formaat net.
- Bepale de generaasje fan it artefakt foardat jo de proxy oanreitsje.
- Bepale oft de mislearring foar de tunnel of deryn bart.
- Befêstigje wat it front-end beëiniget: HTTP, TCP-stream of UDP.
- Test in nij útjûn profyl tsjin it natife einpunt mei belied ûnferoare.