Accesso remoto IKEv2: client Windows verso Ubuntu con strongSwan

Che cosa costruiamo

Finora la serie ha collegato sedi intere. Qui colleghi le singole persone: il portatile di chi lavora da casa o in trasferta si connette alla sede B e ottiene un indirizzo della VPN. È lo scenario che in gergo si chiama road warrior.

Usi il client VPN già presente in Windows 10 e 11, senza installare niente sui portatili. Il protocollo è IKEv2, che regge bene i cambi di rete (Wi-Fi → 4G) e attraversa il NAT incapsulando tutto in UDP 4500. L’autenticazione è a due livelli:

• il server si presenta con un certificato emesso da una tua CA, che i portatili verificano;
• l’utente si autentica con nome e password tramite EAP-MSCHAPv2.

È la combinazione più diffusa perché non richiede di distribuire un certificato a ogni utente. L’alternativa con certificati macchina, più robusta ma più laboriosa, è descritta in fondo.

Lo scenario

Il server Ubuntu della sede B ha un indirizzo pubblico statico e un nome DNS, vpn.example.com, che punta a quell’indirizzo. I portatili si collegano da reti qualsiasi, quasi sempre dietro NAT.

Usa un nome DNS e non l’indirizzo IP: Windows confronta il nome che scrivi nella connessione con quello nel certificato del server. Se proprio devi usare l’IP, vedi la nota sugli errori in fondo.

Pacchetti, CA e certificato del server

1. Installare i pacchetti

sudo apt update
sudo apt install charon-systemd strongswan-swanctl strongswan-pki \
     libcharon-extra-plugins libstrongswan-extra-plugins

• charon-systemd è il demone IKE gestito da systemd, servizio strongswan;
• strongswan-pki contiene il comando pki per creare CA e certificati;
• libcharon-extra-plugins porta i plugin eap-mschapv2 ed eap-identity;
• libstrongswan-extra-plugins aggiunge altri fornitori di algoritmi, utile per MD4 (vedi più sotto).

2. Creare la CA e il certificato del server

Crei una piccola CA privata e un certificato per il server. Windows è esigente su alcuni dettagli:

• chiave RSA oppure ECDSA P-256/P-384: Windows rifiuta Ed25519 e P-521;
• il nome del server in un subjectAltName di tipo DNS, oltre che nel CN;
• uso esteso della chiave serverAuth; aggiungi anche ikeIntermediate, che male non fa e serve ai client macOS meno recenti.

Lavora in una cartella protetta. La chiave della CA, in produzione, va conservata fuori dal server VPN.

mkdir -p ~/pki-vpn && cd ~/pki-vpn
umask 077

# chiave e certificato della CA (10 anni)
pki --gen --type ecdsa --size 384 --outform pem > caKey.pem
pki --self --ca --lifetime 3652 --in caKey.pem \
    --dn "C=IT, O=Esempio Srl, CN=Esempio VPN Root CA" \
    --outform pem > caCert.pem

# chiave del server
pki --gen --type ecdsa --size 384 --outform pem > serverKey.pem

# certificato del server (5 anni), firmato dalla CA
pki --pub --in serverKey.pem --type ecdsa \
  | pki --issue --lifetime 1826 \
        --cacert caCert.pem --cakey caKey.pem \
        --dn "C=IT, O=Esempio Srl, CN=vpn.example.com" \
        --san vpn.example.com \
        --flag serverAuth --flag ikeIntermediate \
        --outform pem > serverCert.pem

# controllo: SAN e flag devono comparire nell'output
pki --print --in serverCert.pem

Copia i file nelle cartelle che swanctl legge da solo:

sudo cp caCert.pem     /etc/swanctl/x509ca/
sudo cp serverCert.pem /etc/swanctl/x509/
sudo cp serverKey.pem  /etc/swanctl/private/
sudo chmod 600 /etc/swanctl/private/serverKey.pem

Il file caCert.pem è l’unico che distribuirai ai portatili. È pubblico: contiene solo il certificato, non la chiave.

Configurazione di strongSwan

Crea un file dedicato agli utenti remoti. swanctl carica in automatico tutto ciò che trova in /etc/swanctl/conf.d/.

connections {
  rw-windows {
    version = 2
    local_addrs = 203.0.113.10
    pools = pool-rw
    send_cert = always
    # IKE: AES-GCM (o AES-CBC) con SHA-256 e curva P-256
    proposals = aes256gcm16-prfsha256-ecp256, aes256-sha256-ecp256
    dpd_delay = 60s

    local {
      auth = pubkey
      certs = serverCert.pem
      id = vpn.example.com
    }
    remote {
      auth = eap-mschapv2
      eap_id = %any
    }
    children {
      rw-lan {
        local_ts = 0.0.0.0/0
        # ESP: AES-GCM 256 con PFS sulla curva P-256
        esp_proposals = aes256gcm16-ecp256
        # lascia che sia Windows a rinnovare le SA figlie
        rekey_time = 0s
        dpd_action = clear
      }
    }
  }
}

pools {
  pool-rw {
    addrs = 10.10.10.0/24
    dns = 192.168.20.1
  }
}

secrets {
  eap-mario {
    id = mario.rossi
    secret = "Cambia-Questa-Password-Lunga"
  }
  eap-anna {
    id = anna.bianchi
    secret = "Anche-Questa-Va-Cambiata"
  }
}

I punti da capire:

• id = vpn.example.com deve coincidere con il SAN del certificato e con il nome che userai su Windows;
• eap_id = %any fa sì che strongSwan chieda il nome utente al client: Windows infatti si presenta con il proprio indirizzo IP, non con il nome dell’utente;
• local_ts = 0.0.0.0/0 permette sia il tunnel completo sia lo split tunneling, che decidi lato Windows (vedi più avanti);
• rekey_time = 0s sulle SA figlie evita un problema noto: il rinnovo avviato dal server verso un client dietro NAT può essere rifiutato da Windows. Il client rinnova da solo, a tempo o dopo circa 200 MiB di traffico.

Carica la configurazione e controlla:

sudo systemctl enable --now strongswan
sudo swanctl --load-all
sudo swanctl --list-conns
sudo swanctl --list-certs
sudo swanctl --list-pools

Instradamento, firewall e NAT

1. Abilitare l’inoltro

net.ipv4.ip_forward = 1

sudo sysctl --system

2. Regole nftables

Con IKEv2 servono le porte UDP 500 e 4500, più il protocollo ESP (numero 50) per i client che non sono dietro NAT. Il traffico decifrato rientra da ens18 e si riconosce con l’espressione meta ipsec exists. Aggiungi alle catene della guida Firewall completo su Linux con nftables:

table inet filtro {
  chain input {
    # ... regole esistenti ...
    udp dport { 500, 4500 } accept
    ip protocol esp accept
  }
  chain forward {
    # ... regole esistenti (established,related in testa) ...
    # MSS ridotto per il traffico da e verso i client VPN
    ip saddr 10.10.10.0/24 tcp flags syn tcp option maxseg size set 1360
    ip daddr 10.10.10.0/24 tcp flags syn tcp option maxseg size set 1360
    # client VPN verso la LAN B (e verso Internet, se tunnel completo)
    meta ipsec exists ip saddr 10.10.10.0/24 accept
  }
}

table ip nat {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    # solo per il tunnel completo: i client escono su Internet con l'IP del server
    ip saddr 10.10.10.0/24 oifname "ens18" masquerade
  }
}

sudo nft -c -f /etc/nftables.conf   # controlla la sintassi
sudo systemctl reload nftables

Le risposte dalla LAN B ai client passano grazie alla regola ct state established,related accept che hai già in testa alla catena forward. I PC della LAN B non hanno bisogno di rotte particolari se il loro gateway è il server Ubuntu; altrimenti aggiungi sul loro gateway una rotta verso 10.10.10.0/24 via 192.168.20.1.

Con UFW l’equivalente minimo è:

sudo ufw allow 500,4500/udp
sudo ufw route allow from 10.10.10.0/24
# il masquerade va aggiunto in /etc/ufw/before.rules, sezione *nat

Configurazione dei client Windows

1. Importare la CA nell’archivio del computer

Il certificato della CA va nelle Autorità di certificazione radice attendibili del computer locale, non in quelle dell’utente: il client IKEv2 guarda solo l’archivio della macchina. Copia caCert.pem sul portatile e, da PowerShell come amministratore:

Import-Certificate -FilePath "C:\Temp\caCert.pem" `
    -CertStoreLocation Cert:\LocalMachine\Root

# verifica
Get-ChildItem Cert:\LocalMachine\Root |
    Where-Object Subject -like "*Esempio VPN Root CA*"

In alternativa, da interfaccia: certlm.msc → Autorità di certificazione radice attendibili → Certificati → Importa. Su molti portatili conviene distribuire la CA con un criterio di gruppo o con Intune.

2. Creare la connessione

Add-VpnConnection -Name "Sede B" `
    -ServerAddress "vpn.example.com" `
    -TunnelType Ikev2 `
    -AuthenticationMethod Eap `
    -EncryptionLevel Required `
    -AllUserConnection `
    -RememberCredential `
    -PassThru

Con -AuthenticationMethod Eap e senza un profilo EAP personalizzato, Windows usa EAP-MSCHAPv2 con nome e password. -AllUserConnection rende la connessione disponibile a tutti gli utenti del portatile (per questo serve la shell da amministratore); toglilo se vuoi crearla solo per l’utente corrente.

3. Allineare gli algoritmi

Questo passaggio non è facoltativo. Senza impostazioni personalizzate Windows propone ancora 3DES, SHA-1 e il gruppo Diffie-Hellman 2 (modp1024), e per ESP addirittura DES. strongSwan, configurato come sopra, li rifiuta: ed è giusto così.

Set-VpnConnectionIPsecConfiguration -ConnectionName "Sede B" `
    -EncryptionMethod GCMAES256 `
    -IntegrityCheckMethod SHA256 `
    -DHGroup ECP256 `
    -CipherTransformConstants GCMAES256 `
    -AuthenticationTransformConstants GCMAES256 `
    -PfsGroup ECP256 `
    -AllUserConnection `
    -Force -PassThru

Ecco come si corrispondono i due lati:

Con AES-GCM in ESP i due parametri -CipherTransformConstants e -AuthenticationTransformConstants devono avere lo stesso valore, perché GCM cifra e autentica insieme. Se un portatile datato non accetta GCM per IKE, usa -EncryptionMethod AES256: la seconda proposta in proposals (aes256-sha256-ecp256) lo copre già.

4. Collegarsi

Dall’icona di rete scegli “Sede B” → Connetti e inserisci nome utente e password definiti nei secrets. Per una prova da riga di comando:

rasdial "Sede B" mario.rossi "Cambia-Questa-Password-Lunga"
rasdial "Sede B" /disconnect

Tunnel completo o split tunneling

Hai due modi di instradare il traffico del portatile:

Il tunnel completo è il comportamento predefinito di Add-VpnConnection. Per passare allo split tunneling e indicare quali reti mandare nella VPN:

Set-VpnConnection -Name "Sede B" -SplitTunneling $true -AllUserConnection

Add-VpnConnectionRoute -ConnectionName "Sede B" `
    -DestinationPrefix "192.168.20.0/24" -AllUserConnection

# se usi anche le altre sedi della serie
Add-VpnConnectionRoute -ConnectionName "Sede B" `
    -DestinationPrefix "192.168.10.0/24" -AllUserConnection

Le rotte compaiono quando la VPN si connette e spariscono quando si disconnette. Se instradi verso la VPN anche 192.168.10.0/24, ricorda che anche il collegamento tra sede B e sede A deve conoscere la rete 10.10.10.0/24 (vedi il passo successivo in fondo).

Se usi lo split tunneling e vuoi irrigidire il server, puoi anche ridurre local_ts alle sole reti della sede (local_ts = 192.168.20.0/24): i client non potranno mandare altro nel tunnel.

Verifiche

Su Ubuntu

sudo swanctl --list-sas                # SA IKE e figlie con gli algoritmi negoziati
sudo swanctl --list-pools --leases     # indirizzi assegnati e a chi
sudo journalctl -u strongswan -f       # log in tempo reale durante la connessione
sudo ip xfrm state                     # SA nel kernel
sudo tcpdump -ni ens18 udp port 500 or udp port 4500

Nell’output di --list-sas controlla la riga dell’IKE SA: deve riportare AES_GCM_16-256/PRF_HMAC_SHA2_256/ECP_256 e l’identità EAP dell’utente (mario.rossi).

Su Windows

Get-VpnConnection -Name "Sede B" -AllUserConnection | Format-List *
Get-NetIPConfiguration | Where-Object InterfaceAlias -eq "Sede B"
Get-NetRoute -InterfaceAlias "Sede B"
Test-NetConnection 192.168.20.1
Resolve-DnsName server.sede-b.lan

Quando una connessione fallisce, il dettaglio è nel Visualizzatore eventi → Registri di Windows → Applicazione, origine RasClient: il messaggio riporta il codice di errore che trovi nella tabella dei problemi.

L’alternativa: certificati macchina

Invece di nome e password, ogni portatile può autenticarsi con un proprio certificato. È più sicuro (niente password da indovinare o riutilizzare) e si presta alla connessione automatica, ma devi emettere, distribuire e revocare un certificato per ogni dispositivo.

• emetti per ogni portatile un certificato con flag clientAuth, firmato dalla stessa CA, ed esportalo in PKCS#12 con openssl pkcs12 -export;
• importalo nell’archivio Personale del computer (Cert:\LocalMachine\My) con Import-PfxCertificate;
• crea la connessione con -AuthenticationMethod MachineCertificate invece di Eap;
• in strongSwan sostituisci il blocco remote con auth = pubkey e cacerts = caCert.pem, e togli eap_id.

In un dominio Active Directory con una CA aziendale, la registrazione automatica dei certificati computer rende questa strada molto più comoda.

Problemi comuni

Il passo successivo

Ora gli utenti remoti raggiungono la sede B. Se la sede B è già collegata alla sede A con la VPN IPsec tra Cisco e Ubuntu, puoi far arrivare i portatili anche lì: sul Cisco aggiungi una rotta verso 10.10.10.0/24 attraverso il tunnel della sede B e, su Ubuntu, una regola forward che consenta il traffico tra i client VPN e l’interfaccia di quel tunnel. Se quel collegamento usa una crypto map invece della VTI, aggiungi 10.10.10.0/24 ai selettori di traffico. Per collegare una terza sede con Windows Server vedi VPN IPsec site-to-site tra Cisco e Windows Server. Per filtrare con più precisione che cosa possono raggiungere gli utenti remoti, riprendi la catena forward della guida Firewall completo su Linux con nftables.