vpnc contro Check Point o Nortel: perché si blocca
vpnc parla solo IKEv1 con XAuth. Un gateway Check Point SNX o Nortel Aventail non arriva mai alla fase delle credenziali, quindi identifica prima il prodotto.
Il sintomo si legge facilmente male: vpnc parte, chiede la password di gruppo, poi resta su un passo di negoziazione finché non segnala che non arriva risposta dalla destinazione. Nulla nell’output menziona il prodotto del gateway, e l’account funziona dal browser, quindi la conclusione ovvia è una password sbagliata o una porta bloccata. Nella maggior parte di questi casi il gateway non è affatto un peer IPsec, quindi lo scambio non arriva mai a testare le credenziali. Vale la pena provare questo schema prima di cambiare qualsiasi altra cosa nel profilo.
Identifica il prodotto prima di modificare un altro campo del profilo.
Il guasto sembra credenziali errate
vpnc inizia inviando IKE verso UDP 500 e, se viene offerto il traversal NAT, verso UDP 4500. Un gateway che termina SSL invece di IPsec non risponde a nessuno dei due, quindi il client riprova e alla fine si arrende con un errore generico. Se lo stesso account funziona attraverso un portale browser che carica una piccola applicazione di supporto, è un forte indizio che il tunnel si basa su SSL e che il client pone la domanda sbagliata.
Un tentativo fallito qui non dice nulla sull’account utente, perché nessuna credenziale è mai stata presentata al gateway.
Verifica quale protocollo offre il gateway
Due minuti di sondaggio separano un peer IPsec da un portale SSL. Eseguili dalla stessa rete che userà il client, e leggi quali porte rispondono invece di quali compaiono in un documento. Conserva il risultato, perché sono proprio quelle porte a decidere quale client il proprietario del gateway dovrebbe supportare. Sonda dalla rete del client e non da un host accanto al gateway.
nc -zvu gw.example.com 500 nc -zvu gw.example.com 4500 nc -zvt gw.example.com 443 curl -sI https://gw.example.com/ | head -5 openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20
Una 443 aperta con un reindirizzamento a una pagina di accesso e silenzio su 500 e 4500 indica una SSL VPN. Le 500 e 4500 aperte con un certificato servito su 443 suggeriscono un gateway IPsec che esegue anche un frontend web, ed è il caso per cui vpnc è stato costruito.
Lo SSL Network Extender di Check Point e il client Aventail di Nortel appartengono entrambi alla seconda categoria, e nessuno dei due accetta un segreto di gruppo IKEv1.
Cosa può e cosa non può esprimere il profilo di vpnc
Sotto il cofano vpnc esegue IKEv1 contro una chiave precondivisa di gruppo, poi invia le credenziali del singolo utente tramite XAuth. Tutto nel suo file di configurazione appartiene a quello scambio: gateway, nome del gruppo, segreto del gruppo, nome utente e password utente. Quei campi descrivono un solo protocollo, e nessuna loro combinazione può far parlare al client un altro.
Per questo ampliare l’elenco dei cifrari o disattivare i controlli dei certificati non corregge mai questa classe di guasto. Quei cambiamenti indeboliscono una negoziazione che il gateway non sta ascoltando.
Scegliere il client che corrisponde al gateway
Per un gateway Check Point usa il pacchetto SNX compilato per quella versione del gateway, che il fornitore pubblica insieme alla documentazione sull’accesso remoto. Le build SNX più vecchie spesso falliscono sulle distribuzioni attuali perché si aspettano librerie 32-bit che non sono più installate, e rattoppare un pacchetto abbandonato è di solito peggio che eseguire il client supportato su una piattaforma supportata.
I client Aventail hanno perso il supporto molto tempo fa. Dove un gateway del genere è ancora in servizio, le scelte realistiche sono il portale browser se l’organizzazione lo abilita, o il client supportato del fornitore su un sistema operativo supportato.
Chiedi al proprietario del gateway il prodotto e la versione, il client che supporta su Linux e se esiste del tutto un profilo IPsec. Se esiste, richiedi l’identificatore di gruppo e il segreto di gruppo come elementi separati, perché non sono la password utente e una coppia scambiata è l’altra causa comune di un tunnel fallito. Quando una connessione finalmente riesce, annota quale protocollo è stato negoziato, così la persona successiva parte da un fatto invece di ripetere la stessa ipotesi.