Plaasbediener-geslote profiel misluk agter 'n TLS-volmag: watter generasie?
Access Server 2.8 en 2.9 bou bediener-geslote profiele verskillend. Besluit watter pad jou volmag breek voordat jy die front-end verander.
Een gebruiker kan verbind en 'n ander nie, deur dieselfde portaal, op dieselfde dag. Albei het bediener-geslote profiele, albei is op dieselfde Access Server-bou, en die enigste verskil is wanneer hul profiel geskep is. Dit is die patroon wat die moeite werd is om te herken, want "bediener-geslote" dui op 'n beleid eerder as 'n verbindingsreeks. Access Server het twee generasies van daardie artefak uitgestuur, en 'n TLS-omgekeerde volmag staan voor net een van hul paaie. Drie voorwaardes bepaal in watter tak jy is.
Twee generasies, twee verbindingsreekse
In die ouer ontwerp, geldig tot 2.8, is die ingevoerde lêer 'n pseudo-profiel. OpenVPN Connect gebruik dit om teen die Access Server-web-API oor HTTPS te verifieer, ontvang 'n tydelike gebruikersgeslote profiel en 'n sessietoken, en bou eers daarna die VPN op. Twee vervoermiddels loop in volgorde, en die eerste een is 'n gewone webversoek.
Die formaat wat met 2.9 ingevoer is, doen nie daardie per-verbinding-opstarting nie. Dit is 'n inheemse profiel wat deur versoenbare OpenVPN kliënte gebruik kan word, nie net deur OpenVPN Connect nie. Om dit af te laai of per URL in te voer kan steeds HTTPS behels — dit is 'n publikasiestap, nie 'n per-verbinding-ophaal van 'n tydelike profiel nie.
| 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 |
'n Opgradering skryf nie noodwendig profiele oor wat reeds uitgereik is nie, so 'n huidige bedienerweergawe kan steeds die ou artefak uitdeel. Die bedienerbou vertel jou wat moontlik is, nie wat hierdie gebruiker ingevoer het nie.
Drie voorwaardes wat jou tak kies
Die eerste voorwaarde is die artefak se generasie. Vra die lêer, kyk hoe dit geskep is, en let op die kliëntweergawe wat dit ingevoer het. As jy die generasie nie uit die lêer kan vasstel nie, sal 'n nuwe profiel wat vir 'n toetsrekening uitgereik is, jou vertel wat die bediener vandag produseer, wat ander inligting is as wat die falende gebruiker het.
Die tweede is wat jou front-end werklik termineer. 'n Laag-sewe HTTP-omgekeerde volmag wat TLS oorneem is nie dieselfde objek as 'n laag-vier TCP-aanstuurder nie, en 'n UDP-aanstuurder is ook nie dieselfde nie. Access Server se gewone reëling op poort 443 laat die OpenVPN TCP-daemon browsverkeer herken en aan die webdienste oorhandig, so om 'n onverwante HTTPS-termineerder voor in te voeg, behou nie daardie daemon se protokolhantering nie. Om dieselfde nommer 443 te deel maak nie twee ontwerpe gelykwaardig nie.
Die derde is waar die fout beland. 'n Voor-VPN-fout en 'n beheerkoordfout lyk soortgelyk in 'n kliënt wat net "koppel" sê, maar hulle laat bewyse op verskillende plekke. As die ou formaat in spel is, is die opstarting 'n kandidaat. As die nuwe formaat in spel is, is 'n leë webtoegangslog verwag en bewys dit niks in enige rigting nie.
Wanneer die artefak oud is: die opstarting misluk eerste
Lees die kliënt se werklike fout eerder as sy finale toestand. Die interessante velde is die HTTPS-fout, die bedieneridentiteit wat die kliënt verwag het, die bestemming waarheen die versoek gegaan het, en of sertifikaatvalidering voltooi is. Pas dié dan teen die webdiens- en volmaglogboeke aan die bedienerkant.
Dat 'n blaaier die aanmeldbladsy bereik, is nie bewys dat hierdie kliënt se API-verifikasie geslaag het nie. Dit is verskillende versoeke, met verskillende sertifikaatverwagtings en dikwels verskillende gasheername. As die portaal korrek bedien word en die kliënt steeds misluk, is die meningsverskil in die opstartpad, nie in die gebruiker se wagwoord nie.
Moenie die vergelyking laat slaag deur TLS-verifikasie af te skakel of verifikasiebeleid te verslap nie. Dit verander 'n diagnoseerbare konfigurasie-mismatch in 'n werkende-maar-onbevestigde pad, en dit is juis die verandering wat 'n tydelike toets in 'n permanente gat omskep. Die Access Server-dokumentasie oor verbindingsprofiele beskryf beide generasies en die tydelike-profielvloei, en dit is die verwysing om na te gaan voordat jy aanneem 'n volmag is skuldig.
Wanneer die artefak nuut is: lees eerder die beheerkoord
Met 'n 2.9-styl profiel gaan die kliënt reguit na die inheemse VPN-eindpunt. Ondersoek die eindpunte in die profiel, die vervoermiddel in gebruik, en die beheerkoordfout. As die kliënt nooit 'n HTTP-versoek uitstuur nie, is dit in ooreenstemming met die ontwerp en nie 'n simptoom nie.
Dit is ook waar die volmagvraag van vorm verander. 'n HTTPS-ontlading kan nie 'n slegs-TCP-stroom breek wat dit nooit sien nie, maar dit kan steeds die aflaai breek wat die profiel publiseer, en 'n slegs-TCP-aanstuurder sal glad nie UDP dra nie. Gaan na watter vervoermiddel die profiel vra voordat jy aflei dat die front-end irrelevant is.
TLS-deurvoer vir 'n enkele stroom is 'n nou reëling. Dit voorsien nie UDP-aansturing nie, en dit reproduseer nie die daemon se eie diens-aansturingsgedrag op 443 nie. As jou front-end een van daardie dinge doen, sê watter, want die oplossing verskil.
Oplossings wat nou bly
Die minste ingrypende toets is om 'n nuwe ondersteunde profiel vir 'n toetsrekening te skep en deur die beoogde inheemse eindpunt te koppel met dieselfde verifikasievereistes. As dit werk en die behoue ou profiel nie, het jy die artefak in een stap van die bediener en van die volmag geskei.
Die verspreiding van 'n gebruikersgeslote profiel verwyder die ou opstartafhanklikheid heeltemal, want daar is geen tydelike-profieluitruiling om te misluk nie. Dit moet vir die beoogde gebruiker uitgereik word, nooit van 'n administrateur gekopieer nie, en dit verander wat die kliënt gemagtig is om te doen, so behandel dit as 'n beleidsbesluit eerder as 'n tydelike oplossing.
Maak dan die publikasieuitleg reg sodat elke vereiste pad bestaan: die weblad vir aflaaie en portaalgebruik, en die inheemse VPN-pad op die vervoermiddel wat die profiele verwag. Hou die volmag se taak by een laag. 'n Werkende gebruikersgeslote tonnel bewys daardie pad werk; dit bewys nie elke volmagreëling ondersteun elke generasie nie, en 'n ou opstartfout veroordeel nie die nuwer formaat nie.
- Identifiseer die artefak se generasie voordat jy aan die volmag raak.
- Stel vas of die fout voor die tonnel of binne-in dit plaasvind.
- Bevestig wat die front-end termineer: HTTP, TCP-stroom of UDP.
- Toets 'n nuut uitgereikte profiel teen die inheemse eindpunt met beleid onveranderd.