Il tuo client dice Connected, il certificato è valido e la pagina della intranet scade ancora in timeout. Quel divario quasi mai è autenticazione. AWS Client VPN autorizza le destinazioni separatamente dall’accesso, e le due cause abituali sono un valore di gruppo che non corrisponde a quello inviato dal provider di identità e una regola di destinazione più specifica che prevale su quella ampia. Entrambe sono visibili nella configurazione dell’endpoint quando si sa dove guardare.

L’accesso è riuscito; la regola non corrispondeva

L’autenticazione risponde a chi è l’utente. Le regole di autorizzazione rispondono a quali prefissi di rete quella identità può raggiungere. Un utente può superare la prima e fallire la seconda, e il client non ti dà molto più di una connessione che resta attiva mentre ogni richiesta scade in timeout.

Inizia confermando che l’endpoint abbia una regola di autorizzazione la cui destinazione contiene l’indirizzo che non funziona. Se non esiste una regola corrispondente, la connessione si comporta correttamente; manca la policy.

Da dove arriva davvero il valore del gruppo

Con Active Directory, il campo access-group contiene il SID del gruppo, non il suo nome visualizzato. Con la federazione SAML, contiene l’ID o il nome del gruppo che l’attributo di gruppo SAML configurato porta davvero. Copia il valore dall’assertion o dalla ricerca nella directory, non da una pagina wiki.

Un gruppo IAM è un altro piano di controllo. Il permesso di amministrare un endpoint Client VPN non trasforma un gruppo IAM nel gruppo VPN di un utente, e incollare un nome di gruppo IAM nel campo access-group non lo traduce in un SID AD né in un valore di attributo SAML.

Un gruppo con un nome simile in un’altra directory non dimostra nulla. Controlla il metodo di autenticazione dell’endpoint e l’appartenenza o l’assertion dell’utente in quello stesso sistema.

Vince il prefisso più lungo, incluso 0.0.0.0/0

L’autorizzazione viene valutata con la corrispondenza di prefisso più lunga, e la regola per tutte le destinazioni viene valutata per ultima, non per prima. Aggiungi una regola 10.46.0.0/16 per Engineering e una regola 0.0.0.0/0 per tutti, e un utente fuori da Engineering non riesce comunque a raggiungere 10.46.20.10 tramite la regola ampia.

È qui che una correzione può andare storta. Eliminare la regola stretta ripristina l’accesso dell’utente e concede quella sottorete anche a ogni identità coperta dalla regola ampia. Costruisci la matrice gruppo-rete prima di eliminare qualcosa, e annota quali gruppi dovrebbero raggiungere quale intervallo. Queste regole solo consentono; non esiste una voce di diniego per ritagliare un’eccezione da un permesso ampio.

Le modifiche richiedono anche una connessione nuova per essere giudicate equamente. Riconnetti il client dopo aver modificato le regole, poi prova di nuovo.

Separate l’autorizzazione dal percorso dei dati

Una regola che corrisponde non è una rotta. L’endpoint ha bisogno di una sottorete associata e di una voce nella tabella di routing per la destinazione, e il gruppo di sicurezza della risorsa di destinazione deve accettare il traffico. Anche il traffico di ritorno e il DNS devono funzionare.

Prova un utente che dovrebbe riuscire e un utente che dovrebbe restare escluso. Entrambi possono accedere mentre solo uno raggiunge la sottorete, e quella differenza è la prova che cerchi.

Se un indirizzo IP funziona ma un nome host no, guarda il resolver prima di toccare l’autorizzazione. Se nessuna rotta copre l’indirizzo, correggi l’associazione o la tabella di routing. Se il pacchetto arriva e il servizio lo rifiuta, la policy di quel servizio è la tappa successiva. Ampliare la matrice di autorizzazione a tutti gli utenti nasconde quale di questi livelli fosse davvero rotto.

Prima di chiudere il ticket, annota la fonte di identità, il valore esatto del gruppo, i prefissi di destinazione e la rotta che porta il traffico. Quella nota trasforma il prossimo rapporto di connesso ma senza accesso in un confronto di due minuti invece di un altro giro di ipotesi.

Articoli correlati