Proč vaše VM v GCP nemůže odpovědět na IPv6 pool OpenVPN

Váš IPv6 VPN klient dosáhne na workload, workload odpovídá do tunelu a odpověď nikdy nedorazí. První instinkt je vinit firewall nebo tunel, a obvykle není na vině ani jedno. Adresa, kterou přiděluje OpenVPN, je vnitřní síť, která existuje jen uvnitř tunelu; Google Cloud netuší, že fd42:90::/64 má být za jednou konkrétní VM, dokud mu to neřeknete.

Tuto skutečnost se musí naučit dva oddělené systémy a jen jeden z nich je OpenVPN. VPC potřebuje trasu, než může cokoli poslat zpět, a VM musí mít povoleno přeposílat to, co dorazí. Pokazte kteroukoli polovinu a symptom vypadá stejně.

Pool je vnitřní síť, ne podsíť

OpenVPN může přidělovat adresy IPv6 z rozsahu, který si vyberete, a tento rozsah je fikce, na níž se oba konce tunelu shodnou. Není to podsíť Google Cloud, neobjevuje se v seznamu podsítí VPC a síťové rozhraní VM tyto adresy nezíská. Workload, který odpovídá klientovi, proto posílá paket na adresu, kterou fabric považuje za nesměrovatelnou.

Držte pool mimo každý rozsah, který VPC už používá. Držte ho také mimo rozsahy za vašimi dalšími tunely. Překryv mění čisté selhání směrování na občasné, které se projeví jen pod zátěží.

Unikátní lokální adresování jako fd42:90::/64 je pro tuto vnitřní síť rozumná volba. Prefix také připomíná, že návrh je od základu privátní. Nic na poolu ULA z něj nedělá legitimní zdroj na veřejném internetu.

Dejte VPC cíl a další hop

Odpověď potřebuje trasu VPC, jejíž cíl je pool a jejíž další hop je VM s VPN. Aktuální dokumentace statických tras pokrývá cílové rozsahy IPv6 a uvádí, které typy dalšího hopu jsou přípustné, takže si ověřte podporovanou podobu pro svou topologii, místo abyste kopírovali starší příklad IPv4.

Adresa dalšího hopu musí být ta, která je skutečně přiřazena cloudovému rozhraní instance. Vnitřní adresa tunelu VM touto adresou není. Když ji přesto použijete, vznikne trasa, která se čistě nainstaluje a nikdy neodpovídá žádnému paketu. Přečtěte si seznam rozhraní, než trasu napíšete.

Priorita trasy je stejně důležitá jako samotný záznam. Trasy podsítí jsou konkrétnější než vlastní trasy, které přidáte, takže pool vyříznutý z existujícího rozsahu podsítě prohraje s trasou podsítě bez ohledu na to, jak je vlastní trasa napsaná. Vyberte samostatný pool a pak potvrďte, že trasa ukazuje instanci jako další hop a správný cílový prefix:

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

Forwarding je třeba povolit dvakrát

Trasa doručí paket instanci. Neudělá však instanci ochotnou přeposílat něco, co jí není adresováno, a toto oprávnění existuje ve dvou vrstvách.

Cloudová strana potřebuje zapnutou schopnost forwardingu instance; to je nastavení, které nechá VM přijímat provoz pro adresy, které nevlastní, a předávat ho dál. Hostující strana potřebuje své vlastní IPv6 forwarding, protože jádro po doručení paketu rozhoduje zvlášť. Obě musí být zapnuté, než jediná odpověď projde tunelem.

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

Potom musí pravidla firewallu propustit vnitřní rozsah zdroje v obou směrech. Google Cloud vyhodnocuje dekapsulovaný paket, takže pravidlo, které pokrývá jen podsíť VPC, zahodí provoz poolu poté, co tunel už uspěl. Přidejte pool jako rozsah zdroje do ingress pravidla a zkontrolujte, že odpověď neblokuje žádná vlastní egress politika. Implicitní pravidlo povolení pokrývá výchozí případ, ručně psané egress pravidlo ne.

Řekněte OpenVPN, kdo co vlastní

OpenVPN přeposílá klientovi, když ví, že tento klient vlastní cíl. Klientské adresy z poolu obsluhuje direktiva serveru, která pool definuje, ale podsíť za klientem je jiné uspořádání a potřebuje pro tohoto klienta výslovný záznam vlastnictví.

Záměna obojího vytvoří tunel, kde pingy na server fungují a nic za ním ne. Rozhodněte, který případ stavíte, a pak napište odpovídající záznam, místo abyste přidali druhý řádek push a doufali.

Držte internetový egress mimo tento návrh

Privátní přístup a přístup k internetu jsou oddělené plány. Pool ULA může dosáhnout na workloady VPC tunelem, jakmile se směrování a forwarding shodnou, a tentýž pool nemá cestu na veřejný internet přes VPC, protože cloudová brána nepřijme libovolný zdroj tunelu jako svůj.

Pokud klienti potřebují i internetový egress, naplánujte pro něj podporovaný návrh adresování a směrování, držte ho nezávislý na privátním poolu a testujte obě cesty odděleně. Jedna funkční cesta nic neříká o druhé a návrh, který je slije, selže způsobem, který vypadá jako rozbitý tunel.