Configurazione di una singola connessione VPN in uscita da un cluster multizona

La soluzione più semplice per configurare il servizio VPN strongSwan in un cluster multizona consiste nell'utilizzare una singola connessione VPN in uscita che fluttua tra diversi nodi di lavoro in tutte le zone di disponibilità nel tuo cluster.

Quando la connessione VPN è in uscita dal cluster multizona, è necessaria solo una singola distribuzione strongSwan. Se un nodo di lavoro viene rimosso o se riscontra dei tempi di inattività, kubelet ripianifica il pod VPN su un nuovo nodo di lavoro. Se una zona di disponibilità riscontra un'interruzione, kubelet ripianifica il pod VPN su un nuovo nodo di lavoro in una zona differente.

1. Configura un grafico Helm VPN strongSwan. Quando si seguono i passi di questa sezione, assicurarsi di specificare le seguenti impostazioni.

   • ipsec.auto: modifica in start. Le connessioni sono in uscita dal cluster.
   • loadBalancerIP: non specificare un indirizzo IP. Lascia questa impostazione vuota.
   • zoneLoadBalancer: specifica un indirizzo IP di programma di bilanciamento del carico pubblico per ciascuna zona dove hai dei nodi di lavoro. Puoi verificare se visualizzare i tuoi indirizzi IP pubblici disponibili o liberare un indirizzo IP utilizzato. Poiché il pod VPN strongSwan può essere pianificato su un nodo di lavoro in qualsiasi zona, questo elenco di IP garantisce che possa essere utilizzato un IP di programma di bilanciamento del carico in qualsiasi zona dove è pianificato il pod VPN.
   • connectUsingLoadBalancerIP: imposta su true. Quando il pod VPN strongSwan è pianificato su un nodo di lavoro, il servizio strongSwan seleziona l'indirizzo IP del programma di bilanciamento del carico che si trova nella stessa zona e utilizza questo IP per stabilire la connessione in uscita.
   • local.id: specifica un valore fisso che è supportato dal tuo endpoint VPN remoto. Se l'endpoint VPN remoto richiede di impostare l'opzione local.id (valore leftid in ipsec.conf) sull'indirizzo IP pubblico del tunnel IPSec VPN, impostare local.id su %loadBalancerIP. Questo valore configura automaticamente il valore leftid in ipsec.conf all'indirizzo IP del programma di bilanciamento del carico utilizzato per la connessione.
   • Facoltativo: nascondere tutti gli indirizzi IP del cluster dietro un singolo indirizzo IP in ogni zona impostando enableSingleSourceIP su true. Questa opzione fornisce una delle configurazioni più sicure per la connessione VPN perché non è consentita alcuna connessione dalla rete remota che vada nuovamente nel cluster. Devi anche impostare local.subnet sulla variabile %zoneSubnet e utilizzare local.zoneSubnet per specificare un indirizzo IP come una sottorete /32 per ciascuna zona del cluster.

2. Nel tuo firewall di rete remota, consenti le connessioni VPN IPSec in entrata dagli indirizzi IP pubblici che hai elencato nell'impostazione zoneLoadBalancer.

3. Configura l'endpoint VPN remoto per consentire una connessione VPN in entrata da ciascuno dei possibili IP di programma di bilanciamento del carico che hai elencato nell'impostazione zoneLoadBalancer.

Configurazione d una singola connessione VPN in entrata da un cluster multizona

Quando hai bisogno di connessioni VPN in entrata e l'endpoint VPN remoto può ristabilire automaticamente la connessione VPN a un IP diverso quando viene rilevato un malfunzionamento, puoi utilizzare una singola connessione VPN in entrata che fluttua tra i diversi nodi di lavoro in tutte le zone di disponibilità nel tuo cluster.

L'endpoint VPN remoto può stabilire la connessione VPN a uno qualsiasi dei programmi di bilanciamento del carico strongSwan in una qualsiasi delle zone. La richiesta in entrata viene inviata al pod VPN indipendentemente da quale sia la zona in cui si trova il pod VPN. Le risposte dal pod VPN vengono restituite tramite il programma di bilanciamento del carico originale all'endpoint VPN remoto. Questa opzione garantisce l'alta disponibilità perché kubelet ripianifica il pod VPN su un nuovo nodo di lavoro, se un nodo di lavoro viene rimosso o se riscontra dei tempi di inattività. Inoltre, se una zona di disponibilità riscontra un'interruzione, l'endpoint VPN remoto può ristabilire la connessione VPN all'indirizzo IP del programma di bilanciamento del carico in una zona differente in modo che sia ancora possibile raggiungere il pod VPN.

1. Configura un grafico Helm VPN strongSwan. Quando si seguono i passi di questa sezione, assicurarsi di specificare le seguenti impostazioni.

   • ipsec.auto: modifica in add. Le connessioni sono in entrata al cluster.
   • loadBalancerIP: non specificare un indirizzo IP. Lascia questa impostazione vuota.
   • zoneLoadBalancer: specifica un indirizzo IP di programma di bilanciamento del carico pubblico per ciascuna zona dove hai dei nodi di lavoro. Puoi verificare se visualizzare i tuoi indirizzi IP pubblici disponibili o liberare un indirizzo IP utilizzato.
   • local.id: se l'endpoint VPN remoto richiede di impostare l'opzione local.id (valore leftid in ipsec.conf) sull'indirizzo IP pubblico del tunnel IPSec VPN, impostare local.id su %loadBalancerIP. Questo valore configura automaticamente il valore leftid in ipsec.conf all'indirizzo IP del programma di bilanciamento del carico utilizzato per la connessione.

2. Nel tuo firewall di rete remota, consenti le connessioni VPN IPSec in uscita agli indirizzi IP pubblici che hai elencato nell'impostazione zoneLoadBalancer.

Configurazione di una connessione VPN in entrata in ciascuna zona di un cluster multizona

Quando si richiedono connessioni VPN in entrata e l'endpoint VPN remoto non può ristabilire la connessione VPN a un IP diverso, è necessario distribuire un servizio VPN strongSwan separato in ogni zona.

L'endpoint VPN remoto deve essere aggiornato per stabilire una connessione VPN separata a un programma di bilanciamento del carico in ciascuna delle zone. Devi inoltre configurare le impostazioni specifiche per la zona sull'endpoint VPN remoto in modo che ciascuna di queste connessioni VPN sia univoca. Assicurarsi che queste connessioni VPN multiple in entrata rimangano attive.

Dopo che hai distribuito ciascun grafico Helm, ogni distribuzione VPN strongSwan viene avviata come un servizio di programma di bilanciamento del carico Kubernetes nella zona corretta. Le richieste in entrata a tale IP pubblico sono inoltrate al pod VPN che è anche allocato nella stessa zona. Se la zona riscontra un'interruzione, le connessioni VPN stabilite nelle altre zone non ne risentono.

1. Configura un grafico Helm VPN strongSwan per ciascuna zona. Quando ti attieni alla procedura indicata in tale sezione, assicurati di specificare le seguenti impostazioni:

   • loadBalancerIP: specifica un indirizzo IP di programma di bilanciamento del carico pubblico disponibile che sia nella zona dove distribuisci questo servizio strongSwan. Puoi verificare se visualizzare i tuoi indirizzi IP pubblici disponibili o liberare un indirizzo IP utilizzato.
   • zoneSelector: specifica la zona dove desideri che sia pianificato il pod VPN.
   • Potrebbero essere necessarie delle ulteriori impostazioni, come zoneSpecificRoutes, remoteSubnetNAT, localSubnetNAT o enableSingleSourceIP, a seconda di quali siano le risorse che devono essere accessibili sulla VPN. Per ulteriori dettagli, vedi il prossimo passo.

2. Configurare le impostazioni specifiche per la zona su entrambi i lati del tunnel VPN per garantire che ciascuna connessione VPN sia univoca. A seconda di quali risorse devono essere accessibili sulla VPN, disponi di due opzioni per rendere le connessioni distinguibili:

   • Se i pod del cluster devono accedere ai servizi della rete remota on-premises,
     • zoneSpecificRoutes: imposta su true. Questa impostazione limita la connessione VPN a una singola regione del cluster. I pod in una zona specifica utilizzano solo la connessione VPN configurata per quella specifica zona. Questa soluzione riduce il numero di pod strongSwan richiesti per supportare più VPN in un cluster multizona, migliora le prestazioni della VPN perché il traffico della VPN fluisce solo ai nodi di lavoro che si trovano nella zona corrente e assicura che la connettività VPN per ciascuna zona non sia influenzata dalla connettività VPN, dai pod per cui si è verificato un arresto anomalo o dalle interruzioni che si sono verificate in altre zone. Non è necessario configurare remoteSubnetNAT. Più VPN che utilizzano l'impostazione zoneSpecificRoutes possono avere la stessa sottorete remota (remote.subnet) perché l'instradamento è configurato in base a ogni singola zona.
     • enableSingleSourceIP: imposta su true e imposta la sottorete locale (local.subnet) su un singolo indirizzo IP /32. Questa combinazione di impostazioni nasconde tutti gli indirizzi IP privati del cluster dietro un singolo indirizzo IP /32. Questo indirizzo /32 univoco consente alla rete in loco remota di inviare risposte sulla connessione VPN corretta al pod corretto nel cluster che ha avviato la richiesta. Tieni presente che il singolo indirizzo IP /32 configurato per l'opzione (local.subnet) deve essere univoco in ciascuna configurazione VPN strongSwan.
   • Se le applicazioni della rete remota on-premises devono accedere ai servizi del cluster,
     • localSubnetNAT: assicurati che un'applicazione nella rete remota in loco possa selezionare una connessione VPN specifica per inviare e ricevere traffico nel cluster. In ciascuna configurazione Helm strongSwan, utilizza localSubnetNAT per identificare in modo univoco le risorse del cluster a cui può accedere l'applicazione in loco remota. Poiché vengono stabilite più VPN dalla rete remota on-premises al cluster, è necessario aggiungere una logica all'applicazione sulla rete on-premises in modo che possa selezionare quale VPN utilizzare quando accede ai servizi nel cluster. Tieni presente che i servizi nel cluster sono accessibili tramite molteplici sottoreti differenti, a seconda di quello che hai configurato per localSubnetNAT in ciascuna configurazione VPN strongSwan.
     • remoteSubnetNAT assicurati che un pod nel tuo cluster utilizzi la stessa connessione VPN per restituire il traffico alla rete remota. In ogni file di distribuzione strongSwan, associa la sottorete in loco remota a una sottorete univoca utilizzando l'impostazione remoteSubnetNAT. Il traffico che viene ricevuto da un pod nel cluster da una remoteSubnetNAT specifica per la VPN viene restituito alla stessa remoteSubnetNAT specifica per la VPN e quindi su quella stessa connessione VPN.
   • Se i pod nel cluster devono accedere ai servizi sulla rete in loco remota e le applicazioni nella rete in loco remota devono accedere ai servizi nel cluster, configurare le impostazioni localSubnetNAT e remoteSubnetNAT elencate nel secondo punto elenco. Nota che se un pod nel cluster avvia una richiesta alla rete in loco remota, devi aggiungere la logica al pod in modo che possa selezionare quale connessione VPN utilizzare per accedere ai servizi sulla rete in loco remota.

3. Configura il software dell'endpoint VPN remoto per stabilire una connessione VPN separata al programma di bilanciamento del carico in ciascuna zona.

Passo 1: ottieni il grafico Helm strongSwan

Installa Helm e ottieni il grafico Helm strongSwan per visualizzare le possibili configurazioni.

1. Segui le istruzioni per installare la versione 3 del client Helm sulla tua macchina locale.

2. Salva le impostazioni di configurazione predefinite per il grafico Helm strongSwan in un file YAML locale.

   helm show values iks-charts/strongswan > config.yaml
   

3. Apri il file config.yaml.

Passo 2: configura le impostazioni IPSec di base

Per controllare lo stabilimento della connessione VPN, modifica le seguenti impostazioni IPSec di base.

Per ulteriori informazioni su ciascuna impostazione, leggi la documentazione fornita nel file config.yaml per il grafico Helm.

1. Se il tuo endpoint del tunnel VPN in loco non supporta ikev2 come protocollo per inizializzare la connessione, modifica il valore di ipsec.keyexchange in ikev1.
2. Imposta ipsec.esp su un elenco degli algoritmi di autenticazione e crittografia ESP utilizzati dal tuo endpoint del tunnel VPN in loco per la connessione.
   • Se ipsec.keyexchange è impostata su ikev1, devi specificare questa impostazione.
   • Se ipsec.keyexchange è impostata su ikev2, questa impostazione è facoltativa.
   • Se lasci vuota questa impostazione, per la connessione vengono utilizzati gli algoritmi strongSwan aes128-sha1,3des-sha1 predefiniti.
3. Imposta ipsec.ike su un elenco degli algoritmi di autenticazione e crittografia IKE/ISAKMP SA utilizzati dal tuo endpoint del tunnel VPN in loco per la connessione. Gli algoritmi devono essere specifici nel formato encryption-integrity[-prf]-dhgroup.
   • Se ipsec.keyexchange è impostata su ikev1, devi specificare questa impostazione.
   • Se ipsec.keyexchange è impostata su ikev2, questa impostazione è facoltativa.
   • Se lasci vuota questa impostazione, per la connessione vengono utilizzati gli algoritmi strongSwan aes128-sha1-modp2048,3des-sha1-modp1536 predefiniti.
4. Modifica il valore di local.id in qualsiasi stringa che vuoi usare per identificare il lato cluster Kubernetes locale utilizzato dal tuo endpoint del tunnel VPN. Il valore predefinito è ibm-cloud. Alcune implementazioni VPN richiedono che tu utilizzi l'indirizzo IP pubblico per l'endpoint locale.
5. Modifica il valore di remote.id in qualsiasi stringa che vuoi usare per identificare il lato in loco remoto utilizzato dal tuo endpoint del tunnel VPN. Il valore predefinito è on-prem. Alcune implementazioni VPN richiedono che tu utilizzi l'indirizzo IP pubblico per l'endpoint remoto.
6. Modifica il valore di preshared.secret nel segreto precondiviso utilizzato dal tuo gateway dell'endpoint del tunnel VPN in loco per la connessione. Questo valore è memorizzato in ipsec.secrets.
7. Facoltativo: imposta remote.privateIPtoPing su qualsiasi indirizzo IP privato nella sottorete remota di cui eseguire il ping come parte del test di convalida della connettività Helm.

Passo 3: seleziona la connessione VPN in entrata o in uscita

Quando configuri una connessione VPN strongSwan, scegli se la connessione VPN è in entrata al cluster o in uscita dal cluster.

In entrata

L'endpoint VPN in loco dalla rete remota avvia la connessione VPN e il cluster è in ascolto per la connessione.

In uscita

Il cluster avvia la connessione VPN e l'endpoint VPN in loco dalla rete remota è in ascolto per la connessione.

Per stabilire una connessione VPN in entrata, modificare le seguenti impostazioni.

1. Verifica che ipsec.auto sia impostata su add.
2. Facoltativo: imposta loadBalancerIP su un indirizzo IP pubblico portatile per il servizio VPN strongSwan. La specifica di un indirizzo IP è utile quando hai bisogno di un indirizzo IP stabile, ad esempio quando devi designare quali indirizzi IP sono consentiti attraverso un firewall in loco. Il cluster deve avere almeno un indirizzo IP del programma di bilanciamento del carico pubblico. Puoi verificare se visualizzare i tuoi indirizzi IP pubblici disponibili o liberare un indirizzo IP utilizzato.
   • Se lasci vuota questa impostazione, viene utilizzato uno degli indirizzi IP pubblici portatili disponibili.
   • Devi anche configurare l'indirizzo IP pubblico che selezioni per l'endpoint VPN, o l'indirizzo IP pubblico ad esso assegnato, sull'endpoint VPN in loco.

Per stabilire una connessione VPN in uscita, modificare le seguenti impostazioni.

1. Modifica ipsec.auto in start.
2. Imposta remote.gateway sull'indirizzo IP pubblico per l'endpoint VPN in loco nella rete remota.
3. Scegli una delle seguenti opzioni per l'indirizzo IP per l'endpoint VPN del cluster:

   • Indirizzo IP pubblico del gateway privato del cluster: Se i nodi worker sono collegati solo a una VLAN privata, la richiesta VPN in uscita viene instradata attraverso il gateway privato per raggiungere Internet. L'indirizzo IP pubblico del gateway privato viene utilizzato per la connessione VPN.

   • Indirizzo IP pubblico del nodo di lavoro dove è in esecuzione il pod strongSwan: se il nodo di lavoro dove è in esecuzione il pod strongSwan è connesso a una VLAN pubblica, l'indirizzo IP pubblico del nodo di lavoro viene utilizzato per la connessione VPN.

     • Se il pod strongSwan viene eliminato e ripianificato su un nodo di lavoro differente nel cluster, l'indirizzo IP pubblico della VPN cambia. L'endpoint VPN in loco della rete remota deve consentire lo stabilimento della connessione VPN dall'indirizzo IP pubblico di uno qualsiasi dei nodi di lavoro del cluster.
     • Se l'endpoint VPN remoto non è in grado di gestire le connessioni VPN da più indirizzi IP pubblici, limitare i nodi a cui il pod VPN strongSwan viene distribuito. Imposta nodeSelector sugli indirizzi IP degli specifici nodi di lavoro o un'etichetta di nodo di lavoro. Ad esempio, il valore kubernetes.io/hostname: 10.232.xx.xx consente la distribuzione del pod VPN solo su tale nodo di lavoro. Il valore strongswan: vpn limita il pod VPN all'esecuzione su qualsiasi nodo di lavoro con quell'etichetta. Puoi utilizzare qualsiasi etichetta di nodo di lavoro. Per consentire l'utilizzo di diversi nodi worker con diverse distribuzioni di diagrammi di helm, utilizzare strongswan: <release_name>. Per l'alta disponibilità, seleziona almeno due nodi di lavoro.

   • Indirizzo IP pubblico del servizio strongSwan: per stabilire la connessione utilizzando l'indirizzo IP del servizio VPN strongSwan, imposta connectUsingLoadBalancerIP su true. L'indirizzo IP del servizio strongSwan è un indirizzo IP pubblico portatile che puoi specificare nell'impostazione loadBalancerIP oppure un indirizzo IP pubblico portatile disponibile che viene assegnato automaticamente al servizio.

     • Se scegli di selezionare un indirizzo IP utilizzando l'impostazione loadBalancerIP, il cluster deve avere almeno un indirizzo IP del programma di bilanciamento del carico pubblico disponibile. Puoi verificare se visualizzare i tuoi indirizzi IP pubblici disponibili o liberare un indirizzo IP utilizzato.
     • tutti i nodi worker del cluster devono trovarsi sulla stessa VLAN pubblica. In caso contrario, devi utilizzare l'impostazione nodeSelector per assicurarti che il pod VPN venga distribuito in un nodo di lavoro sulla stessa VLAN pubblica di loadBalancerIP.
     • Se connectUsingLoadBalancerIP è impostata su true e ipsec.keyexchange è impostata su ikev1, devi impostare enableServiceSourceIP su true.

Passo 4: accesso alle risorse del cluster sulla connessione VPN

Determina le risorse cluster che devono essere accessibili dalla rete remota sulla connessione VPN.

1. Aggiungi i CIDR di una o più sottoreti del cluster all'impostazione local.subnet. Devi configurare i CIDR della sottorete locale sull'endpoint VPN in loco. Questo elenco può includere le seguenti sottoreti.

   • CIDR della sottorete del pod Kubernetes: 172.30.0.0/16. Le comunicazioni bidirezionali sono abilitate tra tutti i pod del cluster e uno qualsiasi degli host nelle sottoreti di rete remota che elenchi nell'impostazione remote.subnet. Se si deve impedire agli host remote.subnet di accedere ai pod del cluster per motivi di sicurezza, non aggiungere la subnet del pod Kubernetes all'impostazione local.subnet.
   • CIDR della sottorete del servizio Kubernetes: 172.21.0.0/16. Gli indirizzi IP del servizio forniscono un modo per esporre più pod dell'applicazione distribuiti su diversi nodi di lavoro dietro un singolo IP.
   • Se le tue applicazioni vengono esposte da un servizio NodePort sulla rete privata o un ALB Ingress privato, aggiungi il CIDR di sottorete privata del nodo di lavoro. Recuperate i primi tre ottetti dell'indirizzo IP privato del vostro lavoratore eseguendo ibmcloud ks worker <cluster_name>. Ad esempio, se è 10.176.48.xx, prendi nota di 10.176.48. Quindi, ottenere il CIDR della sottorete privata del lavoratore eseguendo il seguente comando, sostituendo <xxx.yyy.zz> con l'ottetto recuperato in precedenza: ibmcloud sl subnet list | grep <xxx.yyy.zzz>. Nota: se un nodo di lavoro viene aggiunto a una nuova sottorete privata, devi aggiungere il nuovo CIDR della sottorete privata sia all'impostazione local.subnet che all'endpoint VPN in loco. Bisogna quindi riavviare la connessione VPN.
   • Se hai delle applicazioni esposte dai servizi LoadBalancer sulla rete privata, aggiungi i CIDR della sottorete gestita dall'utente privata del cluster. Per trovare questi valori, eseguire ibmcloud ks cluster get --cluster <cluster_name> --show-resources. Nella sezione VLAN, ricerca i CIDR che hanno un valore Pubblico di false. Nota: se ipsec.keyexchange è impostata su ikev1, puoi specificare solo una sottorete. Puoi tuttavia utilizzare l'impostazione localSubnetNAT per combinare più sottoreti del cluster in una singola sottorete.

2. Facoltativo: riassocia le sottoreti del cluster utilizzando l'impostazione localSubnetNAT. NAT (Network Address Translation) per le sottoreti fornisce una soluzione temporanea per i conflitti di sottorete tra la rete del cluster e la rete remota in loco. Puoi utilizzare NAT per riassociare le sottoreti IP locali private del cluster, la sottorete del pod (172.30.0.0/16) o la sottorete del servizio pod (172.21.0.0/16) a una sottorete privata diversa. Il tunnel VPN vede le sottoreti IP riassociate invece delle sottoreti originali. La riassociazione avviene prima che i pacchetti vengano inviati attraverso il tunnel VPN e dopo che i pacchetti arrivano dal tunnel VPN. Puoi esporre contemporaneamente entrambe le sottoreti riassociate e non riassociate sulla VPN. Per abilitare NAT, puoi aggiungere un'intera sottorete o singoli indirizzi IP.

   • Se si aggiunge un'intera sottorete nel formato 10.171.42.0/24=10.10.10.0/24, la rimappatura è 1-to-1: tutti gli indirizzi IP della sottorete interna sono mappati sulla sottorete esterna e viceversa.
   • Se aggiungi singoli indirizzi IP nel formato 10.171.42.17/32=10.10.10.2/32,10.171.42.29/32=10.10.10.3/32, solo quegli indirizzi IP interni vengono associati agli indirizzi IP esterni specificati.

3. Opzionale per la versione 2.2.0 e successive strongSwan Helm grafici: nascondere tutti gli indirizzi IP del cluster dietro un singolo indirizzo IP impostando enableSingleSourceIP su true. Questa opzione fornisce una delle configurazioni più sicure per la connessione VPN perché non è consentita alcuna connessione dalla rete remota che vada nuovamente nel cluster.

   • Questa impostazione richiede che tutto il flusso di dati sulla connessione VPN sia in uscita indipendentemente dal fatto che la connessione VPN sia stabilita dal cluster o dalla rete remota.
   • Se installi strongSwan in un cluster a zona singola, devi impostare local.subnet su solo un singolo indirizzo IP come una sottorete /32. Se installi strongSwan in un cluster multizona, puoi impostare local.subnet sulla variabile %zoneSubnet e utilizzare local.zoneSubnet per specificare un indirizzo IP come una sottorete /32 per ciascuna zona del cluster.

4. Facoltativo per i grafici Helm strongSwan versione 2.2.0 e successive: abilita il servizio strongSwan per instradare le richieste in entrata dalla rete remota al servizio che esiste esternamente al cluster utilizzando impostazione localNonClusterSubnet.

   • Il servizio non cluster deve esistere sulla stessa rete privata o su una rete privata che sia raggiungibile dai nodi di lavoro.
   • Il nodo worker non cluster non può avviare il traffico verso la rete remota attraverso la connessione VPN, ma il nodo non cluster può essere il destinatario delle richieste in arrivo dalla rete remota.
   • Devi elencare i CIDR delle sottoreti non cluster nell'impostazione local.subnet.

Passo 5: accesso alle risorse di rete remota sulla connessione VPN

Determina quali risorse di rete remota devono essere accessibili dal cluster sulla connessione VPN.

1. Aggiungi i CIDR di una o più sottoreti private in loco all'impostazione remote.subnet. Nota: se ipsec.keyexchange è impostata su ikev1, puoi specificare solo una sottorete.
2. Facoltativo per i grafici Helm strongSwan versione 2.2.0 e successive: riassocia le sottoreti di rete remota utilizzando l'impostazione remoteSubnetNAT. NAT (Network Address Translation) per le sottoreti fornisce una soluzione temporanea per i conflitti di sottorete tra la rete del cluster e la rete remota in loco. Puoi utilizzare NAT per riassociare le sottoreti IP della rete remota a una sottorete privata differente. La riassociazione avviene prima che i pacchetti vengano inviati attraverso il tunnel VPN. I pod nel cluster vedono le sottoreti IP riassociate invece delle sottoreti originali. Prima che i pod ritrasmettano i dati attraverso il tunnel VPN, la sottorete IP riassociata viene riportata alla sottorete effettiva utilizzata dalla rete remota. Puoi esporre contemporaneamente entrambe le sottoreti riassociate e non riassociate sulla VPN.

Passo 6 (facoltativo): abilita il monitoraggio con l'integrazione del webhook Slack

Per monitorare lo stato della VPN strongSwan, puoi configurare un webhook per pubblicare automaticamente messaggi di connettività VPN in un canale Slack.

1. Accedi al tuo spazio di lavoro Slack.

2. Andare alla pagina dell'app WebHooks.

3. Fai clic su Request to Install. Se questa applicazione non è elencata nella tua configurazione Slack, contatta il proprietario del tuo spazio di lavoro Slack.

4. Una volta approvata la tua richiesta di installazione, fai clic su Add Configuration.

5. Scegli un canale Slack o crea un nuovo canale in cui inviare i messaggi VPN.

6. Copia l'URL webhook che viene generato. Il formato dell'URL è simile al seguente:

   https://hooks.slack.com/services/A1AA11A1A/AAA1AAA1A/a1aaaaAAAaAaAAAaaaaaAaAA
   

7. Per verificare che il webhook Slack sia installato, invia un messaggio di prova al tuo URL webhook eseguendo questo comando:

   curl -X POST -H 'Content-type: application/json' -d '{"text":"VPN test message"}' <webhook_URL>
   

8. Vai al canale Slack che hai scelto per verificare che il messaggio di prova abbia esito positivo.

9. Nel file config.yaml relativo al grafico Helm, configura il webhook per monitorare la tua connessione VPN.

   1. Modifica monitoring.enable in true.
   2. Aggiungi gli indirizzi IP privati o gli endpoint HTTP nella sottorete remota che vuoi che siano sempre raggiungibili tramite la connessione VPN a monitoring.privateIPs o monitoring.httpEndpoints. Ad esempio, potresti aggiungere l'IP dall'impostazione remote.privateIPtoPing a monitoring.privateIPs.
   3. Aggiungi l'URL webhook a monitoring.slackWebhook.
   4. Modifica le altre impostazioni monitoring facoltative in base alle necessità.

Passo 7: distribuisci il grafico Helm

Distribuisci il grafico Helm strongSwan nel tuo cluster con le configurazioni che hai scelto in precedenza.

1. Se devi configurare delle impostazioni più avanzate, attieniti alla documentazione fornita per ciascuna impostazione nel grafico Helm.

2. Salva il file config.yaml aggiornato.

3. Installa il grafico Helm nel tuo cluster con il file config.yaml aggiornato.

   Se hai più distribuzioni VPN in un singolo cluster, puoi evitare conflitti di denominazione e differenziare le distribuzioni scegliendo nomi di release più descrittivi rispetto a vpn. Per evitare il troncamento del nome della release, limita il nome a 35 caratteri o meno.

   helm install vpn iks-charts/strongswan -f config.yaml
   

4. Controlla lo stato di distribuzione del grafico. Quando il grafico è pronto, il campo STATUS vicino all'output ha un valore di DEPLOYED.

   helm status vpn
   

5. Dopo che il grafico è stato distribuito, verifica che siano state utilizzate le impostazioni aggiornate nel file config.yaml.

   helm get values vpn
   

Sono supportate solo le versioni del grafico strongSwan Helm rilasciate negli ultimi 6 mesi. Assicurati di aggiornare costantemente il tuo grafico strongSwan Helm per le funzioni e le correzioni di sicurezza più recenti.

Limitazione del traffico VPN strongSwan per spazio dei nomi

Se hai un cluster a singolo tenant o un cluster a più tenant, puoi limitare il traffico VPN ai pod che si trovano solo in determinati spazi dei nomi.

Ad esempio, supponiamo che desideri che i pod presenti solo in uno spazio dei nomi specifico, my-secure-namespace, inviino e ricevano i dati tramite la VPN. Non si vuole che i pod in altri spazi dei nomi, come kube-system, ibm-system, o default, accedano alla rete on-premises. Per limitare il traffico VPN solo a my-secure-namespace, puoi creare politiche di rete globali di Calico.

Prima di utilizzare questa soluzione, esamina le considerazioni e le limitazioni riportate di seguito.

• Non è necessario distribuire il grafico strongSwan Helm nello spazio dei nomi specificato. Il pod VPN strongSwan e la serie di daemon di instradamento essere distribuiti in kube-system o in qualsiasi altro spazio dei nomi. Se la VPN strongSwan non viene distribuita nello spazio dei nomi specificato, il test Helm vpn-strongswan-ping-remote-ip-1 avrà esito negativo. Questo errore è previsto ed accettabile. Il test esegue il ping dell'indirizzo IP privato remote.privateIPtoPing del gateway VPN in loco da un pod che non si trova nello spazio dei nomi che ha l'accesso diretto alla sottorete remota. Tuttavia, il pod VPN è ancora in grado di inoltrare il traffico ai pod negli spazi dei nomi che hanno instradamenti alla sottorete remota e il traffico può ancora scorrere correttamente. Lo stato della VPN è ancora ESTABLISHED e i pod nello spazio dei nomi specificato possono connettersi tramite la VPN.

• Le politiche di rete globali Calico descritte nei passaggi seguenti non impediscono ai pod Kubernetes che utilizzano la rete host di inviare e ricevere dati attraverso la VPN. Quando un pod è configurato con la rete host, l'applicazione in esecuzione nel pod può restare in ascolto sulle interfacce di rete del nodo di lavoro su cui si trova. Questi pod di rete host possono esistere in qualsiasi spazio dei nomi. Per determinare quali pod hanno una rete host, eseguire kubectl get pods --all-namespaces -o wide e cercare tutti i pod che non hanno un indirizzo IP del pod 172.30.0.0/16. Se vuoi impedire ai pod di rete host di inviare e ricevere dati tramite la VPN, puoi impostare le seguenti opzioni nel tuo file di distribuzione values.yaml: local.subnet: 172.30.0.0/16 e enablePodSNAT: false. Queste impostazioni di configurazione espongono tutti i pod Kubernetes attraverso la connessione VPN alla rete remota. Tuttavia, solo i pod che si trovano nello spazio dei nomi sicuro specificato sono raggiungibili tramite la VPN.

Prima di iniziare

• Distribuisci il grafico Helm strongSwan e assicurati che la connettività VPN funzioni correttamente.
• Installa e configura la CLI Calico.

Per limitare il traffico VPN a un determinato spazio dei nomi,

1. Crea una politica di rete globale Calico denominata allow-non-vpn-outbound.yaml. Questa politica consente a tutti gli spazi dei nomi di continuare a inviare il traffico in uscita a tutte le destinazioni, ad eccezione della sottorete remota a cui accede la VPN strongSwan. Sostituire <remote.subnet> con l'indirizzo remote.subnet specificato nel file di configurazione Helm values.yaml. Per specificare più subnet remote, consultare la documentazione Calico.

   apiVersion: projectcalico.org/v3
   kind: GlobalNetworkPolicy
   metadata:
     name: allow-non-vpn-outbound
   spec:
     selector: has(projectcalico.org/namespace)
     egress:
     - action: Allow
       destination:
         notNets:
         - <remote.subnet>
     order: 900
     types:
     - Egress
   

2. Applica la politica.

   calicoctl apply -f allow-non-vpn-outbound.yaml --config=filepath/calicoctl.cfg
   

3. Crea un'altra politica di rete globale Calico denominata allow-vpn-from-namespace.yaml. Questa politica consente solo a uno spazio dei nomi specificato di inviare il traffico in uscita alla sottorete remota a cui accede la VPN strongSwan. Sostituite <namespace> con lo spazio dei nomi che può accedere alla VPN e <remote.subnet> con il remote.subnet specificato nel file di configurazione Helm values.yaml. Per specificare più namespace o subnet remote, consultare la documentazione Calico.

   apiVersion: projectcalico.org/v3
   kind: GlobalNetworkPolicy
   metadata:
     name: allow-vpn-from-namespace
   spec:
     selector: projectcalico.org/namespace == "<namespace>"
     egress:
     - action: Allow
       destination:
         nets:
         - <remote.subnet>
   order: 900
   types:
     - Egress
   

4. Applica la politica.

   calicoctl apply -f allow-vpn-from-namespace.yaml --config=filepath/calicoctl.cfg
   

5. Verifica che le politiche di rete globali siano state create nel tuo cluster.

   calicoctl get GlobalNetworkPolicy -o wide --config=filepath/calicoctl.cfg
   

Limitazione del traffico VPN strongSwan per nodo di lavoro

Se hai più distribuzioni VPN strongSwan in un cluster a più tenant, puoi limitare il traffico VPN per ogni distribuzione a specifici nodi di lavoro dedicati a ciascun tenant.

Quando distribuisci un grafico Helm strongSwan, viene creata una distribuzione VPN strongSwan. I pod VPN strongSwan vengono distribuiti su qualsiasi nodo di lavoro senza taint. Inoltre, viene creata una serie di daemon Kubernetes. Questa serie di daemon configura automaticamente gli instradamenti su tutti i nodi di lavoro senza taint nel cluster a ognuna delle sottoreti remote. Il pod VPN strongSwan utilizza gli instradamenti sui nodi di lavoro per inoltrare le richieste alla sottorete remota nella rete in loco.

Gli instradamenti non vengono configurati sui nodi con taint a meno che non specifichi il taint nell'impostazione tolerations nel file value.yaml. Applicando il taint ai nodi di lavoro, puoi impedire che gli instradamenti VPN vengano configurati su questi nodi di lavoro. Quindi, puoi specificare il taint nell'impostazione tolerations solo per la distribuzione VPN che vuoi consentire sul nodo di lavoro con taint. In questo modo, i pod VPN strongSwan per la distribuzione del grafico Helm di un tenant utilizzano solo gli instradamenti sui nodi di lavoro di quel tenant per instradare il traffico attraverso la connessione VPN alla sottorete remota.

Prima di utilizzare questa soluzione, esamina le considerazioni e le limitazioni riportate di seguito.

• Per impostazione predefinita, Kubernetes posiziona i pod dell'applicazione su qualsiasi nodo di lavoro senza taint disponibile. Per assicurarti che questa soluzione funzioni correttamente, ciascun tenant deve prima garantire di distribuire i propri pod dell'applicazione solo ai nodi di lavoro con taint per il tenant corretto. Inoltre, ciascun nodo di lavoro con taint deve avere anche una tolleranza per consentire ai pod dell'applicazione di essere posizionati sul nodo. Per ulteriori informazioni su taint e tolleranze, consultare la documentazione Kubernetes.
• Le risorse del cluster potrebbero non essere utilizzate in modo ottimale perché nessuno dei tenant può posizionare i pod dell'applicazione sui nodi senza taint condivisi.

I seguenti passi per limitare il traffico VPN strongSwan per nodo di lavoro utilizzano questo scenario di esempio: supponiamo che tu abbia un cluster IBM Cloud Kubernetes Service a più tenant con sei nodi di lavoro. Il cluster supporta il tenant A e il tenant B. Corruzioni i nodi di lavoro nei modi seguenti.

• A due nodi di lavoro viene applicato il taint in modo che solo i pod del tenant A siano pianificati sui nodi di lavoro.
• A due nodi di lavoro viene applicato il taint in modo che solo i pod del tenant B siano pianificati sui nodi di lavoro.
• A due nodi di lavoro non viene applicato il taint perché sono richiesti almeno 2 nodi di lavoro per i pod VPN strongSwan e l'IP del programma di bilanciamento del carico sui cui eseguirli.

Per limitare il traffico VPN ai nodi contaminati per ogni tenant.

1. Per limitare il traffico VPN ai soli lavoratori dedicati al tenant A in questo esempio, si specifica quanto segue toleration nel file values.yaml per la tabella del tenant A strongSwan Helm.

   tolerations:
       - key: dedicated
   operator: "Equal"
   value: "tenantA"
   effect: "NoSchedule"
   

   Questa tolleranza consente al demone di route impostato di essere eseguito sui due nodi worker che hanno il taint dedicated="tenantA" e sui due nodi worker non contaminati. I pod VPN strongSwan per questa distribuzione vengono eseguiti sui due nodi di lavoro senza taint.

2. Per limitare il traffico VPN ai soli lavoratori dedicati al tenant B in questo esempio, si specifica il seguente toleration nel file values.yaml per il diagramma del tenant B strongSwan Helm.

   tolerations:
       - key: dedicated
   operator: "Equal"
   value: "tenantB"
   effect: "NoSchedule"
   

   Questa tolleranza consente al demone di route impostato di essere eseguito sui due nodi worker che hanno il taint dedicated="tenantB" e sui due nodi worker non contaminati. I pod VPN strongSwan per questa distribuzione vengono eseguiti anche sui due nodi di lavoro senza taint.