SSTP autentica prima il server e poi l’utente

Un client SSTP può completare TLS e rifiutare comunque l’utente un secondo dopo. Questa sequenza non è un bug, è lo stack di protocolli: prima la sicurezza del trasporto, poi l’autenticazione dell’utente. Poiché le due fasi falliscono con messaggi diversi, richiedono anche correzioni diverse. Leggere quale fase ha prodotto l’errore è la maggior parte della diagnosi.

Un certificato attendibile dimostra l’endpoint; non dice nulla sull’account.

Che cosa stabilisce l’handshake TLS

Il client convalida il certificato presentato dal server rispetto al proprio archivio di fiducia, al nome host richiesto, alla finestra di validità e a qualsiasi politica aggiuntiva applicata dalla piattaforma. Ciò protegge la connessione verso l’endpoint previsto. Non dimostra che un determinato account sia abilitato, non scaduto o autorizzato all’accesso remoto. Sono domande separate che un altro componente pone più tardi.

Per questo rimuovere i controlli sui certificati per raggiungere la richiesta di accesso è la riparazione sbagliata. Si ottiene una richiesta di accesso su una connessione che non si può verificare. Un errore di certificato appartiene al nome host, all’orologio, alla catena o alla configurazione di fiducia.

Che cosa aggiungono SSTP e PPP sopra

SSTP funziona su HTTPS e trasporta PPP al suo interno, con il proprio scambio di controllo attorno alla connessione. PPP esegue quindi le sue fasi di collegamento e autenticazione, e il metodo di autenticazione dipende dalla politica del server e dalle capacità del client. PAP, CHAP, MS-CHAPv2 ed EAP sono tutte opzioni di autenticazione PPP con proprietà molto diverse. Il controllo utente della VPN è quella fase PPP, non lo strato TLS sottostante.

Un rifiuto dell’utente può quindi significare credenziali, una restrizione dell’account o una discrepanza di metodo.

La ragione lato server è molto più utile che reimpostare ogni segreto del profilo. Un evento di account disabilitato e un fallimento della negoziazione del metodo appaiono simili sul client e non hanno nulla in comune sul server.

Associare l’errore alla fase

Verificare se la connessione raggiunge TLS, poi lo scambio HTTP di SSTP, poi la fase PPP. Mantenere i timestamp dei log allineati tra i tentativi, così che un fallimento precedente non venga confuso con un successo successivo. Un client che registra due tentativi in una finestra sembrerà altrimenti aver fallito nell’ultima fase raggiunta. Leggere il primo errore rilevante, non l’ultima riga.

Lo stesso allineamento conta lato server, dove il record di autenticazione e il log di trasporto sono spesso file separati con orologi separati. Due minuti di scarto bastano a far sembrare impossibile una causa evidente.

Dopo l’accesso, l’autorizzazione resta separata

Un accesso riuscito non concede ogni risorsa privata. Le rotte determinano ciò che è raggiungibile, il DNS determina ciò che viene risolto, e ogni servizio applica ancora i propri permessi. Una sessione che mostra connesso è un’affermazione sul tunnel, non sulla condivisione di file. Quando un utente può connettersi e non riesce a raggiungere un host, la fase del tunnel è già terminata.

È la stessa stratificazione mostrata dall’handshake, un livello più in alto.

Mantenere il recupero dell’account nel processo supportato dall’operatore invece di modificare le impostazioni di trasporto in risposta a un rifiuto esplicito dell’utente. Modificare il trasporto per riparare un account disabilitato è il tipo di riparazione che sembra funzionare quando l’account viene riabilitato per un motivo non correlato.