Varför din GCP-VM inte kan svara på OpenVPN:s IPv6-pool

Din IPv6 VPN-klient når arbetslasten, arbetslasten svarar in i tunneln, och svaret kommer aldrig fram. Instinkten är att skylla på brandväggen eller tunneln, och ingen av dem är oftast skyldig. En adress som delas ut av OpenVPN är ett internt nätverk som bara finns inuti tunneln; Google Cloud har ingen aning om att fd42:90::/64 ska ligga bakom en viss VM förrän du berättar det.

Två separata system måste lära sig detta faktum, och bara ett av dem är OpenVPN. VPC:n behöver en rutt innan den kan skicka något tillbaka, och VM:en måste tillåtas vidarebefordra det som kommer in. Tar du fel i någon av halvorna ser symptomet identiskt ut.

Poolen är ett internt nätverk, inte ett subnät

OpenVPN kan dela ut IPv6-adresser från ett intervall du väljer, och det intervallet är en fiktion som tunnelns två ändar enas om. Det är inte ett Google Cloud-subnät, det syns inte i VPC:ns subnätlista, och VM:ens nätverksgränssnitt får inte de adresserna. En arbetslast som svarar en klient skickar därför ett paket till en adress som nätverket anser vara oroutbar.

Håll poolen utanför varje intervall som VPC:n redan använder. Håll den också utanför intervallen bakom dina andra tunnlar. Överlapp gör ett rent routingfel till ett periodiskt som bara syns under belastning.

Unik lokal adressering som fd42:90::/64 är ett rimligt val för detta interna nätverk. Prefixet påminner också om att designen är privat till sin natur. Inget med en ULA-pool gör den till en legitim källa på det öppna internet.

Ge VPC:n en destination och ett nästa hopp

Svaret behöver en VPC-rutt vars destination är poolen och vars nästa hopp är VPN-VM:en. Nuvarande dokumentation för statiska rutter täcker IPv6-destinationsintervall och listar vilka typer av nästa hopp som är tillåtna, så verifiera den form som stöds för din topologi i stället för att kopiera ett äldre IPv4-exempel.

En nästa-hopp-adress måste vara en som faktiskt är tilldelad instansens molngränssnitt. VM:ens interna tunneladress är inte den adressen. Att använda den ändå ger en rutt som installeras rent och aldrig matchar ett paket. Läs gränssnittslistan innan du skriver rutten.

Ruttprioritet är lika viktigt som posten själv. Subnät-rutter är mer specifika än de anpassade rutter du lägger till, så en pool som skurits ut ur ett befintligt subnätintervall förlorar mot subnät-rutten, oavsett hur den anpassade rutten är skriven. Välj en separat pool och bekräfta sedan att rutten visar instansen som nästa hopp och rätt destinationsprefix:

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

Vidarebefordran måste aktiveras två gånger

En rutt levererar paketet till instansen. Den gör inte instansen villig att vidarebefordra något som inte är adresserat till den, och det tillståndet finns på två nivåer.

Molnsidan behöver instansens vidarebefordringsförmåga aktiverad; det är inställningen som låter en VM ta emot trafik för adresser den inte äger och skicka vidare den. Gästsidan behöver sin egen IPv6-vidarebefordran, eftersom kärnan fattar ett separat beslut efter att paketet anlänt. Båda måste vara på innan ett enda svar korsar tunneln.

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

Därefter måste brandväggsreglerna tillåta det interna källintervallet i båda riktningarna. Google Cloud utvärderar det avkapslade paketet, så en regel som bara täcker VPC-subnätet släpper pooltrafiken efter att tunneln redan lyckats. Lägg till poolen som källintervall i ingressregeln och kontrollera att ingen anpassad egresspolicy blockerar svaret. Den implicita tillåtregeln täcker standardfallet, en handskriven egressregel gör det inte.

Berätta för OpenVPN vem som äger vad

OpenVPN vidarebefordrar till en klient när den vet att klienten äger destinationen. Klientadresser från poolen hanteras av serverdirektivet som definierar poolen, men ett subnät bakom en klient är ett annat arrangemang och kräver en uttrycklig ägarpost för den klienten.

Att blanda ihop de två ger en tunnel där ping till servern fungerar och inget bakom den. Bestäm vilket fall du bygger och skriv sedan den matchande posten i stället för att lägga till en extra push-rad och hoppas.

Håll internetutgången utanför denna design

Privat åtkomst och internetåtkomst är separata planer. En ULA-pool kan nå VPC-arbetslaster över tunneln när routing och vidarebefordran är överens, och samma pool har ingen väg till det öppna internet via VPC:n, eftersom molngatewayen inte accepterar en godtycklig tunnelkälla som sin egen.

Om klienterna också behöver internetutgång, planera en design för adressering och routing som stöds för det, håll den oberoende av den privata poolen och testa de två vägarna separat. En fungerande väg säger ingenting om den andra, och en design som blandar dem misslyckas på ett sätt som ser ut som en trasig tunnel.