Dlaczego Twoja VM w GCP nie może odpowiedzieć na pulę IPv6 OpenVPN

Twój klient VPN IPv6 dociera do obciążenia, obciążenie odpowiada do tunelu, a odpowiedź nigdy nie nadchodzi. Pierwszym odruchem jest obwinianie zapory lub tunelu, a zwykle żadne z nich nie jest winne. Adres przydzielany przez OpenVPN to sieć wewnętrzna, która istnieje tylko wewnątrz tunelu; Google Cloud nie ma pojęcia, że fd42:90::/64 ma znajdować się za jedną konkretną VM, dopóki mu tego nie powiesz.

Ten fakt muszą poznać dwa osobne systemy, a tylko jeden z nich to OpenVPN. VPC potrzebuje trasy, zanim będzie mogła cokolwiek odesłać, a VM musi mieć pozwolenie na przekazywanie tego, co przychodzi. Pomylisz się w którejkolwiek połowie, a objaw wygląda identycznie.

Pula to sieć wewnętrzna, nie podsieć

OpenVPN może przydzielać adresy IPv6 z zakresu, który wybierzesz, a ten zakres to fikcja, na którą zgadzają się oba końce tunelu. To nie jest podsieć Google Cloud, nie pojawia się na liście podsieci VPC, a interfejs sieciowy VM nie otrzymuje tych adresów. Obciążenie, które odpowiada klientowi, wysyła więc pakiet na adres, który sieć uznaje za nieosiągalny.

Trzymaj pulę poza każdym zakresem, którego VPC już używa. Trzymaj ją też poza zakresami za Twoimi innymi tunelami. Nakładanie się zamienia czysty błąd routingu w okresowy, który ujawnia się tylko pod obciążeniem.

Unikalne adresowanie lokalne, takie jak fd42:90::/64, jest rozsądnym wyborem dla tej sieci wewnętrznej. Prefiks przypomina też, że projekt jest prywatny z założenia. Nic w puli ULA nie czyni jej legalnym źródłem w publicznym internecie.

Daj VPC cel i następny skok

Odpowiedź potrzebuje trasy VPC, której celem jest pula, a następnym skokiem jest VM VPN. Obecna dokumentacja tras statycznych obejmuje zakresy docelowe IPv6 i wymienia, jakie typy następnego skoku są dopuszczalne, więc sprawdź obsługiwaną formę dla swojej topologii, zamiast kopiować starszy przykład IPv4.

Adres następnego skoku musi być adresem faktycznie przypisanym do interfejsu chmurowego instancji. Wewnętrzny adres tunelu VM nie jest tym adresem. Użycie go mimo to daje trasę, która instaluje się czysto i nigdy nie pasuje do żadnego pakietu. Przeczytaj listę interfejsów, zanim napiszesz trasę.

Priorytet trasy jest tak samo ważny jak sam wpis. Trasy podsieci są bardziej szczegółowe niż dodawane trasy niestandardowe, więc pula wycięta z istniejącego zakresu podsieci przegra z trasą podsieci, niezależnie od tego, jak zapisano trasę niestandardową. Wybierz osobną pulę, a następnie potwierdź, że trasa pokazuje instancję jako następny skok i właściwy prefiks docelowy:

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

Przekazywanie trzeba włączyć dwa razy

Trasa dostarcza pakiet do instancji. Nie sprawia, że instancja jest skłonna przekazywać coś, co nie jest do niej zaadresowane, a to pozwolenie istnieje na dwóch poziomach.

Strona chmury potrzebuje włączonej zdolności przekazywania instancji; to ustawienie pozwala VM odbierać ruch dla adresów, których nie posiada, i przekazywać go dalej. Strona gościa potrzebuje własnego przekazywania IPv6, ponieważ jądro podejmuje osobną decyzję po dotarciu pakietu. Oba muszą być włączone, zanim jedna odpowiedź przekroczy tunel.

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

Następnie reguły zapory muszą dopuszczać wewnętrzny zakres źródłowy w obu kierunkach. Google Cloud ocenia pakiet po dekapsulacji, więc reguła obejmująca tylko podsieć VPC odrzuca ruch puli po tym, jak tunel już się powiódł. Dodaj pulę jako zakres źródłowy w regule wejściowej i sprawdź, czy żadna niestandardowa polityka wyjściowa nie blokuje odpowiedzi. Domyślna reguła zezwalająca obejmuje przypadek standardowy, ręcznie napisana reguła wyjściowa już nie.

Powiedz OpenVPN, kto co posiada

OpenVPN przekazuje do klienta, gdy wie, że ten klient posiada cel. Adresy klientów z puli obsługuje dyrektywa serwera, która definiuje pulę, ale podsieć za klientem to inny układ i wymaga jawnego wpisu własności dla tego klienta.

Mylenie tych dwóch daje tunel, w którym pingi do serwera działają, a nic za nim. Zdecyduj, który przypadek budujesz, a potem napisz odpowiedni wpis, zamiast dodawać drugą linię push i mieć nadzieję.

Trzymaj wyjście do internetu poza tym projektem

Dostęp prywatny i dostęp do internetu to osobne plany. Pula ULA może dotrzeć do obciążeń VPC przez tunel, gdy routing i przekazywanie się zgadzają, a ta sama pula nie ma drogi do publicznego internetu przez VPC, ponieważ brama chmurowa nie przyjmie dowolnego źródła tunelu jako własnego.

Jeśli klienci potrzebują też wyjścia do internetu, zaplanuj dla niego obsługiwany projekt adresowania i routingu, trzymaj go niezależnie od puli prywatnej i testuj obie ścieżki osobno. Jedna działająca ścieżka nic nie mówi o drugiej, a projekt, który je miesza, zawodzi w sposób wyglądający jak zepsuty tunel.