Servergebonden profiel mislukt achter een TLS-proxy: welke generatie?

De ene gebruiker kan verbinden en de andere niet, via dezelfde portal, op dezelfde dag. Beiden hebben servergebonden profielen, beiden zitten op dezelfde Access Server-build, en het enige verschil is wanneer hun profiel is gegenereerd. Dat is het patroon dat het waard is te herkennen, want "servergebonden" benoemt een beleid en geen verbindingsreeks. Access Server heeft twee generaties van dat artefact geleverd, en een TLS-reversproxy staat maar voor één van hun paden. Drie voorwaarden bepalen in welke tak u zit.

Twee generaties, twee verbindingsreeksen

In het oudere ontwerp, geldig tot en met 2.8, is het geïmporteerde bestand een pseudoprofiel. OpenVPN Connect gebruikt het om zich via HTTPS bij de web-API van Access Server te authenticeren, ontvangt een tijdelijk gebruikersgebonden profiel en een sessietoken, en pas daarna brengt het de VPN tot stand. Twee transporten lopen na elkaar, en het eerste is een gewone webaanvraag.

Het formaat dat met 2.9 is geïntroduceerd, voert die bootstrap per verbinding niet uit. Het is een native profiel dat bruikbaar is door compatibele OpenVPN clients, niet alleen door OpenVPN Connect. Downloaden of importeren via een URL kan nog steeds HTTPS inhouden — dat is een publicatiestap, geen ophaal van een tijdelijk profiel per verbinding.

Een upgrade herschrijft niet noodzakelijk al uitgegeven profielen, dus een huidige serverversie kan nog steeds het oude artefact uitgeven. De server-build vertelt u wat mogelijk is, niet wat deze gebruiker heeft geïmporteerd.

Drie voorwaarden die uw tak kiezen

De eerste voorwaarde is de generatie van het artefact. Vraag het bestand op, kijk hoe het is geproduceerd, en noteer de clientversie die het heeft geïmporteerd. Als u de generatie niet uit het bestand kunt afleiden, vertelt een nieuw profiel voor een testaccount u wat de server vandaag produceert, en dat is andere informatie dan die de falende gebruiker heeft.

De tweede is wat uw front-end feitelijk termineert. Een HTTP-reversproxy op laag zeven die TLS offloadt is niet hetzelfde object als een TCP-doorstuurder op laag vier, en een UDP-doorstuurder evenmin. De gebruikelijke opstelling van Access Server op poort 443 zorgt dat de OpenVPN TCP-daemon browserverkeer herkent en aan de webservices geeft, dus een ongerelateerde HTTPS-terminator ervoor plaatsen behoudt de protocolafhandeling van die daemon niet. Hetzelfde nummer 443 delen maakt twee ontwerpen niet gelijkwaardig.

De derde is waar de fout landt. Een fout vóór de VPN en een fout in het controlelkanaal lijken op elkaar in een client die alleen "verbinden" zegt, maar ze laten bewijs op verschillende plaatsen achter. Als het oude formaat in het spel is, is de bootstrap een kandidaat. Als het nieuwe formaat in het spel is, is een leeg weblog verwacht en bewijst het niets in welke richting dan ook.

Wanneer het artefact oud is: de bootstrap faalt eerst

Lees de werkelijke fout van de client in plaats van zijn eindtoestand. De interessante velden zijn de HTTPS-fout, de serveridentiteit die de client verwachtte, de bestemming waar de aanvraag heen ging, en of de certificaatvalidatie is voltooid. Vergelijk die vervolgens met de logboeken van de webservice en de proxy aan de serverkant.

Dat een browser de inlogpagina bereikt, is geen bewijs dat de API-authenticatie van deze client is geslaagd. Het zijn verschillende aanvragen, met verschillende certificaatverwachtingen en vaak verschillende hostnamen. Als de portal correct wordt bediend en de client faalt nog steeds, ligt de discrepantie in het bootstrappad, niet in het wachtwoord van de gebruiker.

Laat de vergelijking niet slagen door TLS-verificatie uit te schakelen of het authenticatiebeleid te versoepelen. Dat verandert een diagnosticeerbare configuratiemismatch in een pad dat werkt maar niet is geverifieerd, en het is precies die wijziging die een tijdelijke test in een permanent gat verandert. De Access Server-documentatie over verbindingsprofielen beschrijft beide generaties en de stroom van het tijdelijke profiel, en het is de referentie die u moet controleren voordat u aanneemt dat een proxy de schuld heeft.

Wanneer het artefact nieuw is: lees dan het controlelkanaal

Met een profiel in 2.9-stijl gaat de client rechtstreeks naar het native VPN-eindpunt. Onderzoek de eindpunten in het profiel, het gebruikte transport en de fout in het controlelkanaal. Als de client nooit een HTTP-aanvraag doet, is dat in overeenstemming met het ontwerp en geen symptoom.

Hier verandert ook de vorm van de proxyvraag. Een HTTPS-offload kan een stream die alleen TCP is en die hij nooit ziet niet breken, maar hij kan nog steeds de download breken die het profiel publiceert, en een doorstuurder die alleen TCP is zal UDP helemaal niet dragen. Controleer welk transport het profiel vraagt voordat u concludeert dat de front-end irrelevant is.

TLS-doorgifte voor één stream is een nauwe opstelling. Het biedt geen UDP-doorsturing en reproduceert niet het eigen service-doorstuurgedrag van de daemon op 443. Als uw front-end een van die dingen doet, zeg welke, want de oplossing verschilt.

Oplossingen die nauw blijven

De minst ingrijpende controle is een nieuw ondersteund profiel voor een testaccount genereren en verbinden via het bedoelde native eindpunt met dezelfde authenticatie-eisen. Als dat werkt en het bewaarde oude profiel niet, hebt u het artefact in één stap losgemaakt van de server en van de proxy.

De distributie van een gebruikersgebonden profiel verwijdert de verouderde bootstrap-afhankelijkheid volledig, omdat er geen uitwisseling van een tijdelijk profiel is die kan falen. Het moet worden uitgegeven voor de bedoelde gebruiker, nooit van een beheerder worden gekopieerd, en het verandert waartoe de client gemachtigd is, dus behandel het als een beleidsbeslissing en niet als een omweg.

Repareer daarna de publicatie-indeling zodat elk vereist pad bestaat: het webpad voor downloads en portaalgebruik, en het native VPN-pad op het transport dat de profielen verwachten. Houd het werk van de proxy op één laag. Een werkende gebruikersgebonden tunnel bewijst dat dat pad werkt; het bewijst niet dat elke proxy-opstelling elke generatie ondersteunt, en een oude bootstrap-fout veroordeelt het nieuwere formaat niet.

• Bepaal de generatie van het artefact voordat u de proxy aanraakt.
• Stel vast of de fout vóór de tunnel of erin optreedt.
• Bevestig wat de front-end termineert: HTTP, TCP-stream of UDP.
• Test een nieuw uitgegeven profiel tegen het native eindpunt met ongewijzigd beleid.