MSCHAPv2 non è un protocollo VPN: chiedi prima del tunnel

I nomi utente e le password viaggiano dentro un vettore, e MSCHAPv2 nomina solo il metodo che viaggia. Chiedi quale tunnel lo trasporta prima di scegliere un profilo client, perché la stessa stringa di account compare in assetti che non condividono una riga di codice. Ogni profilo che ti viene consegnato codifica entrambe le decisioni, anche quando il foglio di istruzioni ne stampa una sola. L’ordine qui sotto è ciò che un operatore può rispondere senza indovinare e ciò che tu puoi verificare senza catturare pacchetti.

L’autenticazione viaggia dentro un tunnel

Una VPN prende due decisioni che sembrano una: come le parti costruiscono un canale protetto e come una persona dimostra l’identità al suo interno. La seconda è stampata sul foglio di istruzioni perché è quella che digita un umano. La prima decide se un client funzionerà del tutto, ed è quella che la gente salta. Chiedi all’operatore di nominare prima il vettore e poi il metodo, in quest’ordine. Due connessioni possono richiedere lo stesso nome account e la stessa password senza condividere alcuna implementazione sotto il campo di accesso.

Per questo impostazioni copiate dal telefono funzionante di un collega possono fallire sul tuo, anche quando il server accetta entrambe le credenziali. La credenziale non è mai stata la differenza; lo era il profilo che la avvolge. entrambe le parti hanno ragione e nulla si connette di solito è proprio questa confusione, e si chiarisce non appena il vettore viene nominato.

Tre punti in cui compare lo stesso metodo

In PPP il passo di autenticazione attende che esista un collegamento, e RFC 2759 definisce MS-CHAPv2 come quel passo, per questo il metodo compare in L2TP e nelle distribuzioni PPTP più vecchie. Il tunnel termina per primo e la negoziazione PPP avviene al suo interno, quindi uno stadio PPP fallito può lasciare il tunnel come stabilito nel registro del server. Leggi quei due stadi separatamente prima di concludere che le credenziali siano state rifiutate. Un client configurato per L2TP può quindi essere del tutto corretto e restare il client sbagliato per un gateway che parla solo IKEv2.

IKEv2 mette invece EAP-MSCHAPv2 dentro lo scambio di chiavi, così la stessa credenziale fallisce in un altro momento e si presenta come errore di autenticazione anziché di sessione. Il profilo IKEv2 della piattaforma Android è l’esempio quotidiano, e chiede un certificato o un identificatore di server anziché opzioni PPP. Il nome account è identico in entrambi gli assetti, quindi non può dirti quale hai. Solo l’elenco dei protocolli supportati dall’operatore lo stabilisce.

Una VPN basata su TLS aggiunge un terzo assetto, con i propri campi di nome utente e password e nessun MS-CHAPv2 da nessuna parte nello scambio. Vedere un campo password non è quindi prova del protocollo che sta dietro, perché il modulo è costruito per sembrare familiare. Conferma il protocollo dalla documentazione del server, non dalla forma della finestra del client.

Le risposte che ti servono davvero

Invia la richiesta come elenco, perché un elenco è difficile da rispondere a metà. Chiedi il protocollo del tunnel, il metodo al suo interno e il client che l’operatore supporta sulla tua piattaforma. Poi chiedi l’identità e le impostazioni di fiducia del gateway, il formato dell’account e cosa dovrebbe essere raggiungibile una volta alzata la connessione.

Le prime tre decidono se ottieni un profilo che funziona. Le ultime tre decidono se quel profilo fa ciò che il lavoro richiede. Tieni la risposta allegata al ticket, perché la persona successiva farà le stesse sei domande. Dove manca una risposta, tratta il vuoto come una decisione che l’operatore non ha ancora preso, non come qualcosa che puoi dedurre.

Non allentare la verifica del gateway

Il server dimostra la propria identità anche al client, e quella metà dello scambio non è decorazione. Disattivare la verifica del certificato per far connettere un profilo ostinato accetta qualsiasi endpoint che risponda, compreso uno a cui nessuno intendeva arrivare. Nasconde anche una discrepanza reale invece di risolverla, il che spinge il guasto a un momento più tardo e meno evidente. Un profilo che richiede il controllo spento è un profilo che punta a qualcosa che non può verificare.

La discrepanza di solito è un nome, perché un certificato emesso per un nome host fallisce quando il profilo compone un indirizzo. Componi il nome invece di disattivare il controllo. Un’autorità di certificazione privata fallisce quando al dispositivo non è mai stata data la radice, e la correzione è distribuire quella radice per la via approvata. Gli ambienti gestiti si aspettano che l’operatore fornisca l’identità e l’ancora di fiducia, e che il profilo faccia riferimento a entrambe. Quando il campo è assente, chiedi l’artefatto invece di rinunciare alla verifica.

Adatta il profilo, poi dimostra ogni stadio

Una volta noto il vettore, segui il processo documentato di quel client e inserisci solo i campi che chiede. I campi extra compilati perché esistono restano valori sbagliati, e falliscono più tardi di quelli obbligatori. Salva il profilo invariato dopo la prima connessione riuscita, così una modifica successiva può essere confrontata con qualcosa che si sa funzionare.

Poi verifica per stadi: il tunnel si stabilisce, l’utente si autentica, compaiono l’indirizzo e le rotte assegnati, e un servizio consentito risponde. Ogni stadio lascia la propria riga di registro sul server, e leggerle in ordine trasforma un reclamo vago in un riscontro preciso. Se la piattaforma non supporta più l’assetto descritto dall’operatore, è una conversazione di migrazione e non un motivo per attivare ogni opzione legacy sul dispositivo. Vettore, metodo e profilo sono tre risposte separate, e una connessione che funziona le ha tutte e tre concordi.