strongSwan vips: chiedere un indirizzo virtuale a IKEv2

Il tuo client IKEv2 può chiedere un indirizzo interno al gateway, e il gateway decide cosa restituire. In strongSwan quella richiesta è l’impostazione vips, e resta una richiesta anche quando vi scrivi un indirizzo preciso. La guida qui sotto configura la richiesta, la carica e legge ciò che è tornato, perché questi tre passaggi falliscono in tre modi diversi. Nessuno di essi si accorcia digitando con più forza.

Cosa chiede vips e cosa non può promettere

vips appartiene a una definizione di connessione e chiede un indirizzo virtuale al responder. La guida di strongSwan sugli indirizzi virtuali è esplicita nel dire che la risposta può essere un altro indirizzo, o niente affatto, ed è proprio la frase che si salta quando si scrive un valore aspettandosi che compaia. La richiesta vale comunque la pena, perché ciò che verifichi è la risposta. Tratta l’impostazione come un’istruzione a chiedere, non come la configurazione dell’esito.

Chiedere 0.0.0.0 richiede qualsiasi indirizzo virtuale IPv4 disponibile, il che di solito è corretto quando il valore esatto non conta. Chiedere un indirizzo preciso è un suggerimento per il gateway, non una pretesa nei suoi confronti.

Il frammento swanctl e dove va

L’impostazione sta dentro il blocco della connessione, non in un file proprio e non in un profilo del sistema operativo. Questo frammento isolato mostra la forma:

connections {
  net {
    local_addrs = 192.0.2.10
    remote_addrs = 203.0.113.5
    vips = 10.77.0.31
    children {
      net { local_ts = dynamic remote_ts = 10.77.0.0/24 }
    }
  }
}

Caricalo con il file che possiede la connessione, poi avvia la connessione e leggi il risultato. Un frammento incollato nella sezione sbagliata produce un errore di analisi o, peggio, una connessione che si carica senza la richiesta che credevi di aver fatto. Esegui i tre comandi in ordine e conserva l’output.

swanctl --load-all --file /etc/swanctl/swanctl.conf
swanctl --initiate --child net
swanctl --list-sas

local_ts sceglie il traffico, non crea un indirizzo

local_ts nomina l’insieme di traffico che la SA figlia protegge; non mette un indirizzo su un’interfaccia. Una volta negoziato un IP virtuale, strongSwan smette di usare il suo selettore dinamico predefinito e usa invece l’indirizzo concesso. Se fissi il selettore a un indirizzo letterale, stai affermando qualcosa che il gateway forse non ha concesso, ed è per questo che il guasto appare come una SA funzionante con traffico che non va da nessuna parte. Il selettore descrive il traffico, mentre l’assegnazione arriva dall’altro scambio.

L’altro modo per ottenere un indirizzo interno stabile è possederlo localmente. Metti l’indirizzo su un’interfaccia prima che il tunnel salga, punta il selettore su ciò che esiste già e organizza il peer e la rotta intorno a questo.

In quel progetto non si negozia nulla, quindi nulla può essere riassegnato, e questo è lo scambio: determinismo in cambio del fare tu stesso il lavoro di indirizzamento. È un meccanismo diverso, non una variante di vips, per cui i due non vanno mescolati in un’unica connessione. Un selettore fissato accanto a un indirizzo negoziato è una connessione che funziona finché il gateway assegna qualcos’altro.

Verifica che cosa ha assegnato davvero il responder

Leggi l’elenco delle SA per trovare l’indirizzo che il gateway ha concesso, poi conferma che l’indirizzo esista sull’interfaccia. Se i due non concordano, il tunnel è attivo e il traffico non va dove pensi. Un indirizzo concesso che non raggiunge mai l’interfaccia è il guasto più confuso di questa sequenza, perché ogni metà sembra corretta da sola.

Tieni quattro indirizzi separati nelle tue note: l’indirizzo interno richiesto, quello concesso, l’indirizzo LAN della macchina e l’uscita pubblica che un sito web riporta. Appartengono a livelli diversi e compaiono in luoghi diversi. Una guida che li registra tutti e quattro è una che un’altra persona può seguire senza chiedere quale indirizzo intendessi. Rileggili dopo ogni ricaricamento, perché il valore concesso è l’unico che descrive il tunnel attivo.

Tieni separato il progetto statico

Se ti serve un indirizzo interno fisso, organizza la prenotazione sul gateway e lascia che la richiesta del client resti una richiesta. Mescolare un selettore fissato con un indirizzo negoziato dà una connessione che funziona finché il gateway assegna qualcos’altro. Annota la regola di prenotazione accanto alla connessione, perché è la parte che un collega non può dedurre dal file di configurazione. Così un nuovo client eredita la regola invece di riscoprirla.

Nel client Mac integrato nessuno di questi nomi di opzione esiste. Usa l’assegnazione o la prenotazione che il gateway offre e il profilo che l’operatore pubblica, e tratta qualsiasi valore lato client come un suggerimento finché non hai riletto l’assegnazione. Il rollback consiste nel rimuovere la riga vips e ricaricare, il che ti riporta a ciò che il gateway assegna per impostazione predefinita.