Waarom uw GCP-VM niet kan antwoorden op de OpenVPN IPv6-pool

Uw IPv6 VPN-client bereikt de workload, de workload antwoordt de tunnel in, en het antwoord komt nooit aan. De reflex is de firewall of de tunnel de schuld geven, en meestal is geen van beide schuldig. Een adres dat door OpenVPN wordt uitgegeven, is een intern netwerk dat alleen binnen de tunnel bestaat; Google Cloud heeft geen idee dat fd42:90::/64 achter één bepaalde VM hoort te zitten totdat u het vertelt.

Twee afzonderlijke systemen moeten dat feit leren, en slechts één daarvan is OpenVPN. De VPC heeft een route nodig voordat er iets terug kan, en de VM moet toestemming krijgen om door te sturen wat binnenkomt. Zit u aan één van beide helften fout, dan ziet het symptoom er identiek uit.

De pool is een intern netwerk, geen subnet

OpenVPN kan IPv6-adressen uitdelen uit een bereik dat u kiest, en dat bereik is een fictie waarover beide tunneluiteinden het eens zijn. Het is geen Google Cloud-subnet, het staat niet in de subnetlijst van de VPC, en de netwerkinterface van de VM krijgt die adressen niet. Een workload die een client antwoordt, stuurt daarom een pakket naar een adres dat het netwerk als niet-routeerbaar beschouwt.

Houd de pool buiten elk bereik dat de VPC al gebruikt. Houd hem ook buiten de bereiken achter uw andere tunnels. Overlap maakt van een schone routeringsfout een periodieke fout die alleen onder belasting optreedt.

Unieke lokale adressering zoals fd42:90::/64 is een redelijke keuze voor dit interne netwerk. Het prefix herinnert er ook aan dat het ontwerp van nature privé is. Niets aan een ULA-pool maakt hem een legitieme bron op het openbare internet.

Geef de VPC een bestemming en een volgende hop

Het antwoord heeft een VPC-route nodig waarvan de bestemming de pool is en waarvan de volgende hop de VPN-VM is. De huidige documentatie over statische routes behandelt IPv6-bestemmingsbereiken en vermeldt welke soorten volgende hop in aanmerking komen, dus verifieer de ondersteunde vorm voor uw topologie in plaats van een ouder IPv4-voorbeeld te kopiëren.

Een adres voor de volgende hop moet er een zijn dat daadwerkelijk is toegewezen aan de cloud-interface van de instantie. Het interne tunneladres van de VM is dat adres niet. Het toch gebruiken levert een route op die netjes wordt geïnstalleerd en nooit een pakket raakt. Lees de interfacelijst voordat u de route schrijft.

Routprioriteit is net zo belangrijk als de vermelding zelf. Subnetroutes zijn specifieker dan de aangepaste routes die u toevoegt, dus een pool die uit een bestaand subnetbereik is gesneden, verliest het van de subnetroute, ongeacht hoe de aangepaste route is geschreven. Kies een aparte pool en bevestig daarna dat de route de instantie als volgende hop en het juiste bestemmingsprefix toont:

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

Doorsturen moet twee keer worden ingeschakeld

Een route bezorgt het pakket bij de instantie. Die maakt de instantie niet bereid om iets door te sturen dat niet aan hem is geadresseerd, en die toestemming bestaat op twee niveaus.

De cloudkant heeft de doorstuurmogelijkheid van de instantie ingeschakeld nodig; dat is de instelling waarmee een VM verkeer kan ontvangen voor adressen die hij niet bezit en dat kan doorgeven. De gastkant heeft zijn eigen IPv6-doorsturen nodig, omdat de kernel na aankomst van het pakket een aparte beslissing neemt. Beide moeten aan staan voordat één antwoord de tunnel oversteekt.

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

Daarna moeten firewallregels het interne bronbereik in beide richtingen toestaan. Google Cloud beoordeelt het gedecapsuleerde pakket, dus een regel die alleen het VPC-subnet dekt, laat het poolverkeer vallen nadat de tunnel al is geslaagd. Voeg de pool als bronbereik toe aan de ingress-regel en controleer dat geen aangepast egress-beleid het antwoord blokkeert. De impliciete toestaansregel dekt het standaardgeval, een handgeschreven egress-regel niet.

Vertel OpenVPN wie wat bezit

OpenVPN stuurt door naar een client wanneer het weet dat die client de bestemming bezit. Clientadressen uit de pool worden afgehandeld door de serverrichtlijn die de pool definieert, maar een subnet achter een client is een andere opzet en vereist een expliciete eigendomsvermelding voor die client.

De twee verwarren levert een tunnel op waarin pings naar de server werken en niets erachter. Bepaal welk geval u bouwt en schrijf dan de bijbehorende vermelding, in plaats van een tweede push-regel toe te voegen en te hopen.

Houd internet-uitgaand verkeer buiten dit ontwerp

Privétoegang en internettoegang zijn aparte plannen. Een ULA-pool kan VPC-workloads via de tunnel bereiken zodra routering en doorsturen het eens zijn, en diezelfde pool heeft geen pad naar het openbare internet via de VPC, omdat de cloudgateway een willekeurige tunnelbron niet als de zijne accepteert.

Als clients ook internet-uitgaand verkeer nodig hebben, ontwerp daar dan een ondersteunde adresserings- en routeringsoplossing voor, houd die onafhankelijk van de privépool en test de twee paden apart. Eén werkend pad zegt niets over het andere, en een ontwerp dat ze vermengt faalt op een manier die op een kapotte tunnel lijkt.