Perché la tua VM GCP non riesce a rispondere al pool IPv6 di OpenVPN

Il tuo client VPN IPv6 raggiunge il carico di lavoro, il carico risponde nel tunnel e la risposta non arriva mai. L’istinto è dare la colpa al firewall o al tunnel, e di solito nessuno dei due è colpevole. Un indirizzo assegnato da OpenVPN è una rete interna che esiste solo dentro il tunnel; Google Cloud non ha idea che fd42:90::/64 debba stare dietro una VM specifica finché non glielo dici.

Due sistemi separati devono imparare questo fatto, e solo uno di essi è OpenVPN. La VPC ha bisogno di una rotta prima di poter rimandare qualcosa indietro, e alla VM deve essere permesso inoltrare ciò che arriva. Sbaglia una delle due metà e il sintomo appare identico.

Il pool è una rete interna, non una sottorete

OpenVPN può assegnare indirizzi IPv6 da un intervallo che scegli tu, e quell’intervallo è una finzione su cui concordano le due estremità del tunnel. Non è una sottorete Google Cloud, non compare nell’elenco delle sottoreti della VPC e l’interfaccia di rete della VM non acquisisce quegli indirizzi. Un carico che risponde a un client invia quindi un pacchetto a un indirizzo che la rete considera non instradabile.

Tieni il pool fuori da ogni intervallo che la VPC usa già. Tienilo fuori anche dagli intervalli dietro i tuoi altri tunnel. La sovrapposizione trasforma un guasto di instradamento pulito in uno intermittente che si manifesta solo sotto carico.

Un indirizzamento locale univoco come fd42:90::/64 è una scelta ragionevole per questa rete interna. Il prefisso ricorda anche che il progetto è privato per costruzione. Nulla di un pool ULA lo rende una fonte legittima su internet pubblico.

Dai alla VPC una destinazione e un next hop

La risposta ha bisogno di una rotta VPC la cui destinazione sia il pool e il cui next hop sia la VM VPN. La documentazione attuale sulle rotte statiche copre gli intervalli di destinazione IPv6 e indica quali tipi di next hop sono ammessi, quindi verifica la forma supportata per la tua topologia invece di copiare un vecchio esempio IPv4.

Un indirizzo di next hop deve essere uno effettivamente assegnato all’interfaccia cloud dell’istanza. L’indirizzo interno del tunnel della VM non è quell’indirizzo. Usarlo comunque produce una rotta che si installa senza errori e non corrisponde mai a un pacchetto. Leggi l’elenco delle interfacce prima di scrivere la rotta.

La precedenza delle rotte conta quanto la voce stessa. Le rotte di sottorete sono più specifiche delle rotte personalizzate che aggiungi, quindi un pool ricavato da un intervallo di sottorete esistente perderà contro la rotta di sottorete, indipendentemente da come è scritta la rotta personalizzata. Scegli un pool distinto, poi conferma che la rotta mostri l’istanza come next hop e il prefisso di destinazione corretto:

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

L’inoltro deve essere abilitato due volte

Una rotta consegna il pacchetto all’istanza. Non rende l’istanza disposta a inoltrare qualcosa che non è indirizzato a lei, e questa autorizzazione esiste su due livelli.

Il lato cloud ha bisogno della capacità di inoltro dell’istanza abilitata; è l’impostazione che consente a una VM di ricevere traffico per indirizzi che non possiede e di trasmetterlo. Il lato guest ha bisogno del proprio inoltro IPv6, perché il kernel applica una decisione separata dopo l’arrivo del pacchetto. Entrambi devono essere attivi prima che una sola risposta attraversi il tunnel.

sysctl -w net.ipv6.conf.all.forwarding=1

Le regole del firewall devono poi ammettere l’intervallo sorgente interno in entrambe le direzioni. Google Cloud valuta il pacchetto decapsulato, quindi una regola che copre solo la sottorete della VPC scarta il traffico del pool dopo che il tunnel ha già avuto successo. Aggiungi il pool come intervallo sorgente nella regola di ingresso e verifica che nessuna policy di uscita personalizzata blocchi la risposta. La regola di autorizzazione implicita copre il caso predefinito, una regola di uscita scritta a mano no.

Di’ a OpenVPN chi possiede cosa

OpenVPN inoltra a un client quando sa che quel client possiede la destinazione. Gli indirizzi client del pool sono gestiti dalla direttiva server che definisce il pool, ma una sottorete dietro un client è una disposizione diversa e richiede una voce di proprietà esplicita per quel client.

Confondere le due cose produce un tunnel in cui i ping verso il server funzionano e nulla dietro di esso. Decidi quale caso stai costruendo, poi scrivi la voce corrispondente invece di aggiungere una seconda riga push e sperare.

Tieni l’uscita internet fuori da questo progetto

L’accesso privato e l’accesso a internet sono piani separati. Un pool ULA può raggiungere i carichi di lavoro della VPC attraverso il tunnel una volta che instradamento e inoltro concordano, e quello stesso pool non ha alcun percorso verso internet pubblico attraverso la VPC, perché il gateway cloud non accetterà una sorgente tunnel arbitraria come propria.

Se i client hanno bisogno anche di uscita internet, pianifica per essa un progetto di indirizzamento e instradamento supportato, tienilo indipendente dal pool privato e prova i due percorsi separatamente. Un percorso funzionante non dice nulla sull’altro, e un progetto che li confonde fallisce in un modo che sembra un tunnel rotto.