Pool VPN dual-stack: indirizzare entrambe le famiglie in strongSwan

Un gateway può assegnare a un lavoratore itinerante sia un indirizzo virtuale IPv4 sia uno IPv6, mentre il tunnel esterno viaggia ancora su IPv4. Sono decisioni indipendenti, ed è trattarle come una sola il punto in cui i piani dual-stack di solito si sfaldano. Le famiglie interne del client, i prefissi protetti che può raggiungere e il trasporto che porta l’incapsulamento sono tre scelte separate.

La maggior parte della confusione nasce dall’applicare la parola dual stack a un progetto che è dual stack in un solo punto. Un servizio può essere dual stack all’interno, single stack sul proprio indirizzo esterno e funzionare comunque perfettamente per i client. Ciò che non può fare è funzionare per caso.

Due famiglie dentro, un solo percorso fuori

La connessione esterna è IKE su UDP e richiede una famiglia di indirizzi raggiungibile da qualunque punto si trovi il client. Un indirizzo IPv6 interno non richiede un provider con IPv6, perché il pacchetto interno è il carico utile dentro quello esterno. Molte implementazioni funzionanti trasportano prefissi IPv6 attraverso un collegamento in salita solo IPv4.

Ciò che il percorso esterno vincola davvero è la raggiungibilità e la traversata NAT. Se il gateway annuncia solo un indirizzo IPv4, un client su una rete solo IPv6 non può connettersi affatto, qualunque pool abbiate configurato. Decidete la famiglia esterna in base alla vostra popolazione di client, non in base al piano di indirizzamento interno.

Date al client un indirizzo in ciascuna famiglia

Richiedere entrambe le famiglie è una riga sola lato client, a condizione che il gateway abbia qualcosa da distribuire. I pool denominati tengono le sorgenti separate dalle reti di servizio, ed è questa proprietà a rendere leggibili le regole del firewall sei mesi dopo.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Il vips valore richiede un indirizzo di ciascuna famiglia, e l’elenco dei pool decide da dove provengono quegli indirizzi. La documentazione di strongSwan sugli IP virtuali copre le richieste multiple e l’assegnazione dei pool, incluso il punto che un client che chiede un indirizzo specifico esprime solo una preferenza che il responder può ignorare. Non costruite una regola di accesso che presupponga che il client riceva sempre lo stesso valore.

Generati il vostro prefisso locale univoco invece di copiare quello dell’esempio. Due organizzazioni che entrambe fd42::/16 lo distribuiscono scopriranno la collisione la prima volta che si interconnettono, e diagnosticarla non è piacevole.

I selettori descrivono destinazioni, non sorgenti

I selettori di traffico locali della SA figlia indicano quali reti protette stanno dietro il gateway, e i selettori remoti descrivono ciò che il client può usare come sorgente. Un indirizzo di pool virtuale appartiene al lato sorgente di quella politica; metterlo nell’elenco delle destinazioni è una lettura errata comune della configurazione.

Entrambe le famiglie necessitano di rotte di ritorno e di inoltro consentito sul gateway. Aggiungere un prefisso a un selettore senza una rotta di ritorno verso il pool produce un tunnel che si stabilisce, fa passare una sola direzione del traffico e scarta silenziosamente la risposta. Il selettore è politica, non routing.

Tenete i pool e i prefissi di servizio in blocchi separati del vostro piano di indirizzamento. Quando si sovrappongono, una rotta che dovrebbe raggiungere un host protetto può corrispondere a un indirizzo di pool e sparire dentro il tunnel.

Il DNS e il percorso di risposta decidono se sembra finito

Le risposte del resolver sono indipendenti dal trasporto usato per raggiungerlo. Un nome può restituire un record A, un record AAAA o entrambi, e il client sceglie secondo le proprie regole di preferenza. Se un servizio interno pubblica un record AAAA ma nulla instrada quel prefisso, i client su reti dual-stack proveranno prima il percorso IPv6 e resteranno lì finché non fallisce. Nulla nella configurazione del tunnel sembra sbagliato mentre accade.

Decidete quindi per ogni nome quali famiglie debbano essere utilizzabili, poi verificate che il prefisso corrispondente sia nel selettore e abbia una rotta di ritorno. È una decisione servizio per servizio. Pubblicare entrambi i tipi di record indiscriminatamente è il modo in cui un servizio funzionante solo IPv4 inizia ad andare in timeout per metà dei suoi utenti.

Verificate entrambe le famiglie prima di dichiararlo finito

Una configurazione che si carica non è una configurazione che funziona. Leggete lo stato riportato dal demone, confermate le assegnazioni dei pool, poi guardate le rotte che il client ha davvero installato.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

I primi due comandi mostrano le SA figlie stabilite e quali pool hanno ancora indirizzi disponibili, così un piano che funziona per il primo client e fallisce per il decimo diventa visibile. Gli ultimi due mostrano se il client ha ricevuto un indirizzo IPv6 globale dal pool e dove andrebbe davvero il traffico verso un prefisso protetto. Confrontate l’indirizzo assegnato con il pool che avete configurato, non con l’indirizzo che speravate. Se il responder ha scelto un valore diverso secondo la sua politica, le rotte e le regole del firewall devono comunque allinearsi a ciò che ha scelto.

Poi provate un host protetto per famiglia, e provate un nome che risolva verso entrambe. Un test su una sola famiglia non vi dice nulla sulla metà del piano che non avete esercitato, e quella metà è di solito dove vive la rotta mancante.