Waarom jou GCP-VM nie op die OpenVPN-IPv6-poel kan antwoord nie

Jou IPv6-VPN-kliënt bereik die werklading, die werklading antwoord in die tonnel in, en die antwoord kom nooit aan nie. Die instink is om die firewall of die tonnel te blameer, en nie een van hulle is gewoonlik skuldig nie. ’n Adres wat deur OpenVPN uitgegee word, is ’n binneste netwerk wat net binne die tonnel bestaan; Google Cloud het geen idee dat fd42:90::/64 agter een bepaalde VM veronderstel is om te leef voordat jy dit vir hom sê nie.

Twee afsonderlike stelsels moet daardie feit leer, en net een van hulle is OpenVPN. Die VPC het ’n roete nodig voordat dit enigiets kan terugstuur, en die VM moet toegelaat word om aan te stuur wat aankom. Kry enige helfte verkeerd en die simptoom lyk identies.

Die poel is ’n binneste netwerk, nie ’n subnet nie

OpenVPN kan IPv6-adresse uit ’n reeks uitgee wat jy kies, en daardie reeks is ’n fiksie waaroor die twee tonnel-eindpunte ooreenkom. Dit is nie ’n Google Cloud-subnet nie, dit verskyn nie in die VPC-subnetlys nie, en die VM se netwerkkoppelvlak verkry nie daardie adresse nie. ’n Werklading wat aan ’n kliënt antwoord, stuur dus ’n pakket na ’n adres wat die netwerkweefsel as onroetebaar beskou.

Hou die poel uit elke reeks wat die VPC al gebruik. Hou dit ook uit die reekse agter jou ander tonnele. Oorvleueling verander ’n skoon roeteringsfout in ’n ongereelde een wat net onder las opduik.

Unieke plaaslike adressering soos fd42:90::/64 is ’n redelike keuse vir hierdie binneste netwerk. Die voorvoegsel dien ook as ’n herinnering dat die ontwerp van nature privaat is. Niks aan ’n ULA-poel maak dit ’n wettige bron op die openbare internet nie.

Gee die VPC ’n bestemming en ’n volgende sprong

Die antwoord het ’n VPC-roete nodig wie se bestemming die poel is en wie se volgende sprong die VPN-VM is. Huidige dokumentasie oor statiese roetes dek IPv6-bestemmingsreekse en lys watter tipes volgende sprong toelaatbaar is, so verifieer die ondersteunde vorm vir jou topologie eerder as om ’n ouer IPv4-voorbeeld te kopieer.

’n Volgende-sprongadres moet een wees wat werklik aan die instans se wolkkoppelvlak toegewys is. Die VM se binneste tonneladres is nie daardie adres nie. Om dit tog te gebruik lewer ’n roete wat skoon installeer en nooit ’n pakket pas nie. Lees die koppelvlaklys voordat jy die roete skryf.

Roetevoorrang is net so belangrik soos die inskrywing self. Subnetroetes is meer spesifiek as die pasgemaakte roetes wat jy byvoeg, so ’n poel wat uit ’n bestaande subnetreeks uitgekerf is, sal teen die subnetroete verloor, maak nie saak hoe die pasgemaakte roete geskryf is nie. Kies ’n aparte poel en bevestig dan dat die roete die instans as volgende sprong en die korrekte bestemmingsvoorvoegsel wys:

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

Aansturing moet twee keer aangeskakel word

’n Roete lewer die pakket by die instans af. Dit maak nie die instans gewillig om iets aan te stuur wat nie aan hom geadresseer is nie, en daardie toestemming bestaan op twee vlakke.

Die wolkekant het die instans-aansturingsvermoë geaktiveer nodig; dit is die instelling wat ’n VM verkeer vir adresse wat hy nie besit nie laat ontvang en aanstuur. Die gastekant het sy eie IPv6-aansturing nodig, want die kern pas ’n aparte besluit toe nadat die pakket aankom. Albei moet aan wees voordat ’n enkele antwoord die tonnel oorsteek.

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

Firewallreëls moet dan die binneste bronreeks in beide rigtings toelaat. Google Cloud evalueer die gedekapsuleerde pakket, so ’n reël wat net die VPC-subnet dek, laat die poelverkeer val nadat die tonnel al geslaag het. Voeg die poel as ’n bronreeks by die inkomende reël en kyk dat geen pasgemaakte uitgaande beleid die antwoord blokkeer nie. Die geïmpliseerde toelaatreël dek die standaardgeval, ’n handgeskrewe uitgaande reël nie.

Vertel vir OpenVPN wie wat besit

OpenVPN stuur aan ’n kliënt aan wanneer dit weet daardie kliënt besit die bestemming. Kliëntadresse uit die poel word deur die bediener-riglyn hanteer wat die poel definieer, maar ’n subnet agter ’n kliënt is ’n ander reëling en het ’n eksplisiete eienaarskapinskrywing vir daardie kliënt nodig.

Om die twee te verwar lewer ’n tonnel waar pings na die bediener werk en niks agter dit nie. Besluit watter geval jy bou en skryf dan die bypassende inskrywing eerder as om ’n tweede push-lyn by te voeg en te hoop.

Hou internet-uitgang uit hierdie ontwerp

Private toegang en internettoegang is aparte planne. ’n ULA-poel kan VPC-werkladings oor die tonnel bereik sodra roetering en aansturing ooreenstem, en daardie selfde poel het geen pad na die openbare internet deur die VPC nie, want die wolkpoort sal nie ’n willekeurige tonnelbron as sy eie aanvaar nie.

As kliënte ook internet-uitgang nodig het, beplan ’n ondersteunde adresserings- en roeteringsontwerp daarvoor, hou dit onafhanklik van die private poel en toets die twee paaie apart. Een werkende pad sê niks oor die ander nie, en ’n ontwerp wat hulle vereenselwig, misluk op ’n manier wat soos ’n stukkende tonnel lyk.