Il tunnel completo in strongSwan richiede 0.0.0.0/0 su entrambi i lati

Una connessione strongSwan che funziona per una singola sottorete privata non trasporterà traffico internet solo perché qualcuno ha modificato una riga. Un tunnel completo è un accordo tra due parti su quali indirizzi protegge la child SA, e ciascuna parte nomina l'altra rispetto a sé stessa. Azzeccate un lato e sbagliate l'altro, e la child SA o non si alza o si alza più stretta del previsto. I cinque controlli seguenti seguono quell'accordo dal client, attraverso il gateway, fino a internet.

Controllate prima il selettore del client

Il client descrive ciò che vuole proteggere sul lato remoto come remote_ts, e tutto ciò che invia parte dal proprio indirizzo assegnato. Per il traffico internet quel valore deve coprire le destinazioni che l'utente raggiungerà davvero, il che in pratica significa tutto lo spazio IPv4. Un client che elenca ancora una sottorete chiede un tunnel diviso, qualunque sia il nome del profilo nell'interfaccia. Il lato sorgente è di solito dynamic perché l'indirizzo viene assegnato al momento della connessione. Una sorgente fissa scritta lì si rompe non appena cambia il pool di indirizzi.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Il frammento non è un file di connessione completo, e questo presuppone che autenticazione, identità e pool di indirizzi virtuali siano già configurati. Il selettore di sorgente del client e l'indirizzo assegnato dal server devono ancora coincidere, altrimenti la child SA si alza con un ambito che nessuno dei due lati si aspettava. Caricatelo con swanctl --load-all e leggete l'output prima di presumere il successo. Un file che si analizza può comunque essere rifiutato per un selettore che non si sovrappone alla proposta dell'altra parte.

Controllate il selettore del gateway sul suo lato

Il gateway legge lo stesso concetto dalla direzione opposta. Le destinazioni internet sono locali per il gateway, quindi il suo local_ts è quello ampio e il suo remote_ts descrive il pool di client. Questa inversione è l'errore più comune in una configurazione di tunnel completo, e sopravvive alla revisione perché entrambe le righe sembrano plausibili da sole.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

Copiare il frammento del client nel file del gateway produce una coppia di selettori che non descrive nulla di utile, perché entrambi i lati rivendicherebbero lo stesso ruolo. La guida all'inoltro di strongSwan documenta esplicitamente l'accoppiamento client-gateway, e vale la pena leggerla accanto al file di connessione invece che dopo il guasto. Il file del gateway ha bisogno anche della definizione del pool a cui fa riferimento remote_ts. Un selettore che nomina un pool inesistente si carica senza lamentarsi e fallisce alla connessione.

Il vecchio ipsec.conf usa ruoli sinistro e destro con chiavi diverse, e una riga rightsubnet non è un sostituto diretto del valore swanctl. Tenete le due sintassi in file separati invece di incollare l'una nell'altra. Mescolarle in un'unica directory è il modo in cui una connessione funzionante torna in silenzio dopo un riavvio.

Controllate la child SA negoziata, non il file

Una configurazione salvata dimostra l'intenzione e nulla di più. L'altra parte può restringere quanto richiesto, e una child SA esistente non viene sostituita solo perché il file sotto è cambiato. Confermate cosa è realmente installato prima di cambiare qualsiasi altra cosa.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

Il primo comando mostra cosa ha caricato il demone, il secondo mostra le child SA stabilite e il terzo le politiche che il kernel applicherà. Se il file dice 0.0.0.0/0 e l'elenco mostra una sola sottorete, la negoziazione ha ristretto l'ambito e rileggere il file non lo spiegherà. Terminate la child, riavviatela e confrontate di nuovo tutti e tre gli output. Una child che torna con lo stesso ambito ristretto è ristretta dall'altra parte e non dal file locale, e questa è una conversazione con l'altro amministratore invece di una modifica locale.

Leggete entrambe le direzioni nell'elenco delle politiche, perché un tunnel che installa una direzione e non l'altra è un problema di routing in costume da configurazione. Le politiche di andata e ritorno devono nominare la stessa coppia di selettori in immagine speculare, e uno specchio mancante è un difetto del demone o della proposta, non del testo del selettore.

Controllate l'inoltro e la rotta di ritorno

Un selettore ammette il traffico verso il gateway; non fa sì che il gateway instradi quel traffico oltre. L'inoltro deve essere abilitato, il firewall deve consentire il flusso e la risposta deve trovare la via del ritorno al pool di client. Sono tre requisiti separati, e ciascuno fallisce con un sintomo diverso. Una regola di inoltro mancante si comporta come un buco nero, mentre una rotta di ritorno mancante si comporta come un tunnel a senso unico.

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

Gli indirizzi privati dei client di solito richiedono una traduzione di sorgente deliberata prima di poter uscire da un'interfaccia pubblica, mentre un'assegnazione instradata esplicitamente richiede un trattamento diverso. Se c'è di mezzo NAT, mantenete le eccezioni supportate dall'implementazione così che il traffico che una politica di sicurezza deve ispezionare non venga tradotto oltre. Una regola masquerade ampia copiata da un altro gateway cambia molti più flussi di quanti ne intendesse l'autore. Scrivete la regola solo per il pool di client e lasciate un commento che spieghi perché esiste.

Sul client, confermate le rotte installate dal backend invece delle rotte che avete supposto. Un gestore con l'installazione delle rotte disattivata ha bisogno di un progetto di routing mantenuto a mano, e quel progetto va aggiornato ogni volta che il tunnel cambia. Controllate la tabella di routing dopo una riconnessione, non solo dopo un avvio pulito.

Controllate cosa il tunnel continua a non coprire

La coppia di selettori copre IPv4 e nient'altro. IPv6, DNS e qualsiasi politica a livello applicativo sono decisioni separate che un selettore IPv4 ampio ignora in silenzio. Un tunnel che trasporta ogni pacchetto IPv4 può comunque far trapelare ogni ricerca di nome.

Dichiarate esplicitamente il percorso DNS previsto, perché un tunnel completo che risolve ancora i nomi tramite il resolver locale fa trapelare le query fuori dal tunnel e rompe i nomi privati. Se al client viene assegnato un indirizzo IPv6, quella famiglia di indirizzi ha bisogno dello stesso trattamento, altrimenti l'host preferirà un percorso che il tunnel non protegge. Provate con un nome a cui solo il lato privato può rispondere, e trattate una risposta pubblica come una fuga.

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Confermate la catena con questi due comandi più i selettori negoziati dall'elenco sopra. Se il traceroute mostra il router locale come primo hop, il traffico non usa il tunnel qualunque cosa affermino i selettori. L'accesso a internet è completo solo quando il traffico scelto viene ammesso, inoltrato e restituito attraverso il gateway progettato. Trovare 0.0.0.0/0 in un profilo è l'inizio di quella catena, non la sua prova.