Il profilo bloccato al server fallisce dietro un proxy TLS: quale generazione?

Un utente riesce a connettersi e un altro no, attraverso lo stesso portale, lo stesso giorno. Entrambi hanno profili bloccati al server, entrambi sono sulla stessa build di Access Server, e l'unica differenza è quando è stato generato il loro profilo. È lo schema che vale la pena riconoscere, perché "bloccato al server" nomina una politica e non una sequenza di connessione. Access Server ha distribuito due generazioni di quell'artefatto, e un proxy inverso TLS si trova davanti a uno solo dei loro percorsi. Tre condizioni decidono in quale ramo siete.

Due generazioni, due sequenze di connessione

Nel progetto più vecchio, valido fino alla 2.8, il file importato è uno pseudo-profilo. OpenVPN Connect lo usa per autenticarsi all'API web di Access Server tramite HTTPS, riceve un profilo temporaneo bloccato all'utente e un token di sessione, e solo dopo stabilisce la VPN. Due trasporti vengono eseguiti in sequenza, e il primo è una normale richiesta web.

Il formato introdotto con la 2.9 non esegue quel bootstrap per connessione. È un profilo nativo utilizzabile dai OpenVPN client compatibili, non solo da OpenVPN Connect. Scaricarlo o importarlo via URL può ancora comportare HTTPS — è un passo di pubblicazione, non un recupero di un profilo temporaneo per connessione.

Un aggiornamento non riscrive necessariamente i profili già emessi, quindi una versione attuale del server può ancora distribuire l'artefatto vecchio. La build del server dice cosa è possibile, non cosa ha importato questo utente.

Tre condizioni che scelgono il vostro ramo

La prima condizione è la generazione dell'artefatto. Chiedete il file, guardate come è stato prodotto e annotate la versione del client che lo ha importato. Se non riuscite a stabilire la generazione dal file, un profilo nuovo emesso per un account di prova vi dirà cosa produce il server oggi, e questa è un'informazione diversa da quella che ha l'utente che fallisce.

La seconda è cosa termina realmente il vostro front-end. Un proxy inverso HTTP di livello sette che scarica il TLS non è lo stesso oggetto di un inoltro TCP di livello quattro, e nemmeno un inoltro UDP lo è. La disposizione abituale di Access Server sulla porta 443 fa sì che il demone OpenVPN TCP riconosca il traffico del browser e lo consegni ai servizi web, quindi inserire davanti un terminatore HTTPS estraneo non preserva la gestione del protocollo di quel demone. Condividere il numero 443 non rende equivalenti due progetti.

La terza è dove atterra il guasto. Un guasto prima della VPN e un guasto del canale di controllo sembrano simili in un client che dice solo "connessione", ma lasciano prove in posti diversi. Se è in gioco il formato vecchio, il bootstrap è un candidato. Se è in gioco il formato nuovo, un registro di accesso web vuoto è atteso e non prova nulla in nessuna direzione.

Quando l'artefatto è vecchio: il bootstrap fallisce per primo

Leggete l'errore reale del client invece del suo stato finale. I campi interessanti sono l'errore HTTPS, l'identità del server che il client si aspettava, la destinazione verso cui è andata la richiesta e se la validazione del certificato è stata completata. Poi confrontateli con i registri del servizio web e del proxy sul lato server.

Che un browser raggiunga la pagina di accesso non è prova che l'autenticazione API di questo client sia riuscita. Sono richieste diverse, con aspettative di certificato diverse e spesso nomi host diversi. Se il portale è servito correttamente e il client fallisce ancora, il disaccordo è nel percorso di bootstrap, non nella password dell'utente.

Non fate passare il confronto disabilitando la verifica TLS o allentando la politica di autenticazione. Questo trasforma una discrepanza di configurazione diagnosticabile in un percorso che funziona ma non è verificato, ed è esattamente la modifica che trasforma un test temporaneo in un buco permanente. La documentazione di Access Server sui profili di connessione descrive entrambe le generazioni e il flusso del profilo temporaneo, ed è il riferimento da controllare prima di supporre che un proxy sia la causa.

Quando l'artefatto è nuovo: leggete invece il canale di controllo

Con un profilo in stile 2.9, il client va direttamente all'endpoint nativo della VPN. Esaminate gli endpoint del profilo, il trasporto in uso e l'errore del canale di controllo. Se il client non emette mai una richiesta HTTP, ciò è coerente con il progetto e non è un sintomo.

È anche qui che la questione del proxy cambia forma. Uno scarico HTTPS non può rompere un flusso solo TCP che non vede mai, ma può ancora rompere il download che pubblica il profilo, e un inoltro solo TCP non trasporterà affatto UDP. Verificate quale trasporto chiede il profilo prima di concludere che il front-end è irrilevante.

Il passthrough TLS per un singolo flusso è una disposizione ristretta. Non fornisce inoltro UDP e non riproduce il comportamento di inoltro dei servizi del demone stesso sulla 443. Se il vostro front-end fa una di queste cose, dite quale, perché il rimedio è diverso.

Rimedi che restano ristretti

Il controllo meno invasivo è generare un profilo nuovo supportato per un account di prova e connettersi tramite l'endpoint nativo previsto con gli stessi requisiti di autenticazione. Se questo funziona e il profilo vecchio conservato no, avete separato l'artefatto dal server e dal proxy in un solo passo.

La distribuzione di un profilo bloccato all'utente elimina del tutto la dipendenza dal bootstrap legacy, perché non c'è alcuno scambio di profilo temporaneo che possa fallire. Deve essere emesso per l'utente previsto, mai copiato da un amministratore, e cambia ciò a cui il client è autorizzato, quindi trattatelo come una decisione di politica e non come un aggiramento.

Poi correggete la disposizione di pubblicazione in modo che esista ogni percorso richiesto: il percorso web per i download e l'uso del portale, e il percorso VPN nativo sul trasporto che i profili si aspettano. Mantenete il lavoro del proxy su un solo livello. Un tunnel bloccato all'utente che funziona dimostra che quel percorso funziona; non dimostra che ogni disposizione di proxy supporti ogni generazione, e un vecchio guasto di bootstrap non condanna il formato più recente.

• Identificate la generazione dell'artefatto prima di toccare il proxy.
• Stabilite se il guasto avviene prima del tunnel o al suo interno.
• Confermate cosa termina il front-end: HTTP, flusso TCP o UDP.
• Provate un profilo appena emesso contro l'endpoint nativo con la politica invariata.