Dietro la frase «il VPN non funziona su eduroam» ci sono due accessi, e team diversi se ne occupano. Iscriversi a eduroam porta il dispositivo su una rete di accesso; iscriversi a un VPN costruisce una seconda relazione sopra quella connessione. Entrambi possono essere gestiti dalla stessa istituzione, ma le credenziali, il profilo e la fase in cui qualcosa si rompe restano separati. Stabilite quale dei due è fallito davvero prima che qualcuno modifichi un numero di porta. Tutto ciò che segue è organizzato attorno a questa unica biforcazione.

Un campus in cui OpenVPN rispondeva sulla UDP 1194 è storia utile, non una ricetta per il prossimo.

Dimostrate prima il lato accesso

Spegnete il tunnel e caricate una pagina HTTP semplice o un portale captivo. Se si apre, la rete di accesso fa il suo lavoro e la questione del VPN è davvero aperta. Se non si carica nulla, il guasto sta nell’associazione, nell’account o nel profilo di configurazione. Nessuna modifica al VPN toccherà nessuno di quei tre.

La guida alla connessione eduroam rende l’istituzione di origine la fonte dell’identità dell’utente. Quando un assistente di configurazione costruisce un profilo, scegliere l’istituzione visitata invece di quella di origine produce una configurazione che non riesce ad autenticarsi. Usate ciò che pubblica l’istituzione di origine, e non un pacchetto di certificati che arriva da altrove.

Disattivare un controllo di certificato o di autenticazione per superare un accesso trasforma una configurazione errata riparabile in un difetto permanente. Se il profilo installato viene da una fonte non approvata, sostituitelo prima di esaminare qualunque altra cosa.

Chi possiede quale guasto

Quando l’accesso funziona, ogni domanda che resta ha esattamente un proprietario. Questa è tutta la divisione:

OwnerQuestions that belong to them
VPN operatorServer name, protocol, transport, port, client compatibility, VPN authentication
Visited network operatorWhich traffic the local arrangement permits, and any observed path problem
Device or client administratorLocal policy, client build, server-identity errors

La riga del trasporto è il punto in cui falliscono la maggior parte dei tentativi fatti da soli. Ciò su cui il server ascolta è fissato nella sua configurazione, e modificare il profilo del client non può cambiarlo, quindi chiedete all’operatore il profilo attuale invece di alternare TCP e UDP. L’alternanza cambia solo il modo in cui il client fallisce.

Sul lato visitato, un’autenticazione eduroam riuscita non dice nulla sul fatto che quel percorso trasporti o meno un dato trasporto VPN, e un timeout da solo non è prova di un blocco. Entrambe le affermazioni vengono fatte ogni giorno, e ciascuna ha bisogno di un’osservazione dietro.

Sul lato dispositivo, una regola di sicurezza gestita, una versione client incompatibile e un errore di identità del server sono tre guasti diversi. Raggrupparli in un solo ticket rallenta tutti e tre.

Scegliete la prova prima della teoria

Dove il profilo è vostro da provare e l’operatore l’ha approvato, un confronto vince una discussione: lo stesso profilo si connette da un’altra rete fidata? Un «sì» indica il percorso visitato, un «no» indica il profilo, il server o il client. Fate quella prova dentro le regole che valgono per l’account, e mai installando un client che nessuno ha approvato.

Se l’operatore pubblica un profilo alternativo approvato, usatelo. Inventare un ascoltatore su una nuova porta o allentare le regole della rete produce un risultato che nessuno potrà difendere in seguito, e nasconde il guasto originale.

Scrivete il risultato nella forma su cui i tre proprietari possono agire, non in quella più rapida da digitare. Un timeout nudo non dice nulla di utile all’operatore del VPN, e un errore di autenticazione dice altrettanto poco all’operatore della rete visitata.

Spesso basta una sola riga di log. TLS Error: TLS key negotiation failed to occur within 60 seconds indica il percorso o la porta, mentre AUTH_FAILED significa che il tunnel è stato raggiunto e le credenziali sono state rifiutate.

Scrivete il passaggio di consegne in cinque righe

Un passaggio di consegne conciso porta cinque cose: il luogo visitato, l’ora del tentativo, la versione client approvata, il server e il trasporto verso cui puntava il profilo, e il primo errore informativo. Aggiungete se l’accesso ordinario funzionava e se è stato fatto un confronto approvato tra reti, se avete questi due dati. Oscurate password, token e chiavi private prima che questo lasci la vostra scrivania.

Se il VPN si autentica e poi un’applicazione privata fallisce, inoltrate quel risultato successivo a parte. Le due domande precedenti a quel punto hanno già risposta, e ripiegarle in un nuovo rapporto «ancora rotto» rimanda tutti all’inizio.

Cinque righe, tre proprietari, una biforcazione: è tutta la decisione, e di solito si risolve prima che qualcuno tocchi un numero di porta.

Articoli correlati