Adattare il client VPN Linux al protocollo dell'apparato vecchio

Quattro famiglie di protocolli coprono quasi ogni apparato ancora in un rack, e ciascuna fallisce in modo diverso su Linux. Le porte pubblicate e le proposte configurate dell'estremità remota decidono il pacchetto, non la distribuzione che si trova a eseguire. Installare ciò che menziona un post di un forum e poi modificare finché qualcosa si connette è il modo in cui un pomeriggio svanisce. Leggete l'apparato, installate per secondo, verificate per terzo.

Annotate ciò che pubblica l'estremità remota

Annotate il protocollo, le porte e l'autenticazione attese dall'apparato prima di aprire un gestore di pacchetti. Quattro famiglie coprono la maggior parte delle apparecchiature vecchie, e la tabella qui sotto è tutta la decisione in una schermata.

Il manuale e le regole del firewall dell'apparato stesso sono più affidabili del nome del protocollo nella sua pagina di accesso. Un dispositivo che annuncia IPsec può parlare solo IKEv1, e una versione di firmware che nessuno ha applicato è forse quella che alla fine aggiunge IKEv2. Confermate il percorso dati oltre alla porta di configurazione, perché è lì che l'apparecchiatura vecchia e le reti moderne divergono. Sbagliare questo passaggio significa eseguire il debug del client contro una funzione che l'altro capo non ha mai avuto.

PPTP: dimostrate GRE prima di modificare pppd

PPTP su Linux non è un demone da avviare ma una chiamata a pppd, e i parametri di connessione vivono in un file peer con nome che pppd legge quando viene chiamato. Le distribuzioni lo impacchettano ancora, benché le debolezze note del protocollo lo rendano inadatto a qualsiasi cosa sensibile, quindi tenetelo rigorosamente per un apparato che non offre altro. Osservate GRE mentre il client negozia, con una cattura breve invece di un'ipotesi. Il guasto che fa perdere più tempo non è l'autenticazione ma il percorso dati mancante.

pppd call branch-office
tcpdump -ni any proto gre -c 5

Se la configurazione termina e il collegamento non trasporta mai traffico, sospettate il percorso GRE prima di toccare le credenziali. I gruppi di sicurezza cloud richiedono una regola esplicita per il protocollo 47, e alcune reti lo bloccano del tutto senza errore visibile. Provate dalla rete che userete davvero, non da un laboratorio che permette tutto.

L2TP/IPsec: una proposta giusta batte dieci tentativi

Leggete il registro del demone invece della finestra del desktop, perché la finestra fonde diversi guasti distinti in un solo messaggio. Un errore NO_PROPOSAL_CHOSEN appartiene alla prima fase: il client ha offerto una crittografia, un hash o un gruppo Diffie-Hellman che il server non accetterà. Elencate ciò che l'apparato supporta e scrivete una proposta che vi corrisponda, perché le combinazioni casuali producono di solito lo stesso errore più lentamente. Su un desktop il client pratico è il plugin L2TP di NetworkManager con strongSwan o Libreswan sotto.

Una stringa di proposta che per un plugin desktop significa una cosa può significarne un'altra per il demone a cui affida il lavoro, quindi mantenete la sintassi adatta al livello che state modificando. Se l'apparato richiede anche un segreto di tunnel, è una fase separata dalla chiave IPsec. Confermate quale dei due chiede l'interfaccia prima di digitare qualcosa al suo interno.

IKEv1 aggressivo con XAuth, e il caso del portale

Un'estremità in stile FortiGate di solito vuole modalità aggressiva con XAuth e un indirizzo in modalità configurata, cosa che un plugin grafico potrebbe non esporre affatto. Il demone nativo se ne occupa, e il blocco qui sotto è la forma di quella configurazione, non un file completo. Consultate la documentazione aggiornata del fornitore per i valori della proposta.

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

Le versioni precedenti di strongSwan usavano xauth=client dove la versione 5 usa leftauth2=xauth, quindi uno snippet copiato può fallire solo per la sintassi. Per un portale TLS, openconnect, che parla il protocollo AnyConnect, gestisce Cisco e la maggior parte dei marchi rinominati, e richiede un dispositivo TUN più i privilegi per configurarlo. Passate l'indirizzo del portale esattamente come lo mostra il browser, incluso qualsiasi percorso atteso dall'apparato, poi controllate l'indirizzo assegnato prima di provare qualcosa dietro. Creare l'interfaccia in anticipo elimina una classe di sorprese durante la configurazione.

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

Collegate, poi verificate in un ordine fisso

Eseguite esattamente un gestore VPN alla volta, perché un profilo NetworkManager e un demone avviato a mano si contenderanno rotte e DNS. Disattivate il profilo prima di provare una connessione manuale, e confermate che nessuna vecchia interfaccia di tunnel sopravviva. Poi verificate in quest'ordine: indirizzo del tunnel, rotta verso l'unico host interno che vi serve, risoluzione dei nomi e infine una richiesta reale. Un'icona verde dimostra l'autenticazione e nient'altro.

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

Se un passaggio fallisce, fermatevi lì invece di provare il successivo, perché un guasto DNS a valle di una rotta rotta non vi insegna nulla. Salvate una copia del profilo funzionante prima di sperimentare, perché un file di connessione cancellato si perde facilmente e si ricostruisce faticosamente. Conservate i valori della proposta nella stessa nota del modello dell'apparato e della versione del firmware, perché quella nota è la differenza tra una migrazione e un progetto di archeologia quando la scatola viene sostituita.