Perché PPTP e L2TP/IPsec si fermano prima della richiesta del nome utente?

L'assenza della richiesta del nome utente è un regalo diagnostico: PPP non è ancora partito, quindi l'account, la password e i criteri di dominio non sono ancora stati interrogati. In una connessione PPTP o L2TP/IPsec il client chiede le credenziali solo dopo che il tunnel esiste e il server ha avviato una sessione PPP. Tutto ciò che può fallire prima di quel momento è trasporto, scambio di chiavi o configurazione del tunnel, una superficie molto più piccola di «la VPN è rotta».

Una richiesta assente riduce il guasto a tre fasi

Annotate l'ultima fase che ha avuto successo visibile, perché ciascuna ha un proprietario e una correzione diversi. Indovinare le impostazioni dell'account mentre siete bloccati due fasi prima è come un pomeriggio svanisce.

Un client che scade senza richiesta non ha mai ottenuto un'associazione IPsec, quindi il guasto è in IKE o nel fatto che i vostri pacchetti raggiungano la gateway. Quello che segnala di star verificando le credenziali e poi cade è arrivato più avanti di quanto il messaggio suggerisca. Una richiesta seguita da un rifiuto è autenticazione PPP, e appartiene a un articolo sull'account, non a questo.

Prima fase: il protocollo che un firewall scarta in silenzio

PPTP richiede TCP 1723 per il canale di controllo e il protocollo IP 47 per il percorso dati, e i due viaggiano separatamente. Molte reti inoltrano 1723 e scartano il protocollo 47, il che produce un tunnel che negozia e poi non trasporta assolutamente nulla. Un router che fa NAT ha bisogno anche di un passaggio compatibile con GRE, e un percorso di accesso solo IPv6 non può trasportare PPTP in nessuna configurazione.

L2TP su IPsec consuma la porta 500 per IKE e la porta 4500 per l'attraversamento NAT, poi incapsula il traffico L2TP stesso nella 1701, mentre ESP trasporta il carico protetto una volta che l'associazione esiste. Consentite le due porte di controllo ma non ESP, e otterrete esattamente il sintomo del titolo: progresso visibile e poi un client morto prima di qualsiasi finestra delle credenziali. Provare da un hotspot del telefono è un modo economico per separare un problema di client da un problema di percorso.

Seconda fase: una chiave che non è la chiave, una proposta che non viene offerta

Una chiave precondivisa che non corrisponde fallisce in fretta e in silenzio, e la versione abituale è una chiave che sembra corretta sullo schermo mentre porta un ritorno a capo incollato o uno spazio finale. Su un client Linux la finestra non è necessariamente la fonte della verità: il plugin L2TP di NetworkManager tiene i segreti in file sotto /etc/ipsec.d/, e un vecchio file per connessione che /etc/ipsec.secrets include ancora verrà usato al posto di quello appena digitato. Copiate quel file in un luogo sicuro, toglietelo dal percorso di inclusione, poi ridigitate la chiave a mano.

L'altra metà di questa fase è la proposta. Entrambe le estremità devono accordarsi sullo stesso insieme di algoritmi di fase 1 — cifratura, integrità e gruppo Diffie-Hellman — e su trasformazioni ESP corrispondenti per la fase 2, altrimenti l'associazione non si forma affatto. Una gateway che offre solo 3DES, SHA1 e MODP1024 rifiuterà un client configurato per algoritmi più forti, e il suo log nomina la trasformazione rifiutata. Il log nomina la discrepanza se lo leggete invece di riavviare il servizio ancora una volta. Invece di copiare una stringa di algoritmi da un thread di forum, chiedete alla gateway quali trasformazioni negozierà davvero: ike-scan puntato al suo indirizzo restituisce le trasformazioni che negozierà. Se l'unica offerta è crittografia che la vostra politica non consente più, la correzione appartiene alla gateway, non a un declassamento del client.

Su Windows la chiave e il metodo di autenticazione vivono nel profilo VPN, e una discrepanza emerge prima della richiesta delle credenziali, non dopo. Dove il ricevitore è un Windows Server, confermate che il ruolo di accesso remoto sia installato, che il certificato corrisponda al nome a cui si connettono i client e che nessun filtro di porte sia più stretto dei protocolli qui sopra.

Terza fase: il tunnel esiste e PPP non parte mai

Quando IKE è completo e la richiesta ancora non appare, guardate il demone del tunnel invece del firewall. L2TP ha bisogno di qualcosa in ascolto su UDP 1701 — xl2tpd o kl2tpd su Linux, il servizio di accesso remoto su Windows — e un servizio installato ma fermo appare dal lato client identico a un pacchetto scartato. Controllate l'ascoltatore prima di riaprire regole che avete già verificato. Poi PPP deve negoziare, e il primo scambio LCP è dove di solito atterra un guasto silenzioso.

Una trappola di questa fase non è affatto un guasto di rete: Windows consente una sola connessione di un dato tipo di VPN alla volta, quindi un secondo tentativo restituisce l'errore 937, «un'altra connessione di questo tipo è in uso». È una regola locale, e il modo per aggirarla è un altro dispositivo, un altro tipo di tunnel o la condivisione dell'unica connessione già esistente.

Leggete il log nell'ordine delle fasi invece di indovinare

Fermate il client, riavviatelo e leggete i componenti nell'ordine in cui scrivono nel log. Cioè prima il demone IPsec — strongSwan o Libreswan, e ipsec --version vi dice quale — poi il demone L2TP, poi pppd. Qualunque componente abbia scritto per ultimo prima del guasto segna la fase da investigare, perché tutto ciò che viene dopo nella sequenza non è stato eseguito affatto.

Verificate con una connessione nuova e non con una sessione salvata, perché un client che si riconnette dalla cache può saltare parti dello scambio e riprodurre un risultato obsoleto. Confermate raggiungibilità, scambio di chiavi, tunnel e PPP uno alla volta, in quest'ordine. Allora la richiesta assente smette di essere un mistero e diventa la seconda riga di un elenco che potete davvero percorrere. Quell'elenco è anche ciò che consegnate al team di rete, a cui altrimenti verrebbe chiesto di controllare il firewall per un guasto che vive in un demone non avviato.