Włącz przekazywanie IP na istniejącej bramie GCE VPN

VM została utworzona bez przekazywania IP, już uruchamia oprogramowanie VPN, a odruch każe odbudować ją z szablonu z ustawioną flagą. Ta przebudowa jest niepotrzebna. Compute Engine udostępnia canIpForward jako aktualizowalną właściwość, a udokumentowana ścieżka aktualizacji stosuje ją z refresh zamiast restartu. To, czym flaga faktycznie steruje, jest wąskie: bez niej platforma odrzuca pakiety, które docierają do instancji, ale nie są adresowane na własny adres instancji. Brama przekazująca ruch innych maszyn robi dokładnie to, więc flaga musi być włączona. Wszystko po tym to konfiguracja gościa i routing, których flaga nie dotyka.

Co flaga dopuszcza, a czego nie

Przy wyłączonym przekazywaniu platforma traktuje instancję jako punkt końcowy. Pakiety, których celem jest własny adres instancji, są dostarczane; pakiety, które instancja ma przekazać dalej w czyimś imieniu, nie są.

Przy włączonym przekazywaniu instancja może działać jako następny skok dla trasy VPC, i to jest rola potrzebna urządzeniu VPN. Flaga nie mówi nic o zaporach ogniowych, routingu gościa, konfiguracji tunelu ani ścieżkach powrotnych, i wartość true na zepsutej bramie to nadal zepsuta brama.

Odczytaj bieżącą właściwość

Sprawdź ustawienie, zanim cokolwiek zmienisz, używając tylko do odczytu describe wobec zamierzonej instancji, projektu i strefy:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

Wartość false ma znaczenie tylko wtedy, gdy ta VM ma być następnym skokiem. Jeśli tak, resztę ścieżki i tak trzeba sprawdzić osobno, ponieważ właściwość to jedna linia w dłuższym łańcuchu.

Zaktualizuj istniejącą instancję

Procedura Google aktualizacji właściwości instancji eksportuje bieżący zasób, modyfikuje właściwość i przesyła wynik. To inny tok pracy niż flaga --can-ip-forward w chwili tworzenia, i to ten działa na uruchomionej VM.

Najpierw wyeksportuj definicję do pliku lokalnego i zachowaj niezmienioną kopię do porównania:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

W tym wyeksportowanym pliku ustaw właściwość i nie zmieniaj niczego innego:

canIpForward: true

Zachowaj cały zasób, wraz z jego odciskiem. Zastąpienie pliku jednolinijkowym dokumentem YAML albo połączenie niepowiązanych zmian typu maszyny, dysku lub interfejsu w jednym przesłaniu to droga, na której zmiana właściwości staje się awarią.

Poproś mechanizm aktualizacji o zwalidowanie pliku i zgłoszenie, czego by wymagał, zanim zostanie dozwolona jakakolwiek faktyczna zmiana:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

To uruchomienie walidacji nie włącza przekazywania. Przeczytaj odpowiedź pod kątem nieprawidłowych właściwości i akcji, która według niej jest potrzebna. Dla tej izolowanej zmiany udokumentowaną akcją jest REFRESH. Jeśli wynik prosi o restart, plik zawiera więcej niż właściwość, którą chciałeś zmienić, więc obejrzyj go zamiast zatwierdzać restart.

Zastosuj przejrzany plik z limitem refresh:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

Sprawdź, czy operacja się zakończyła, i ponownie uruchom polecenie describe. Jeśli odcisk już się nie zgadza, ktoś inny zmienił instancję podczas twojej edycji, więc wyeksportuj świeżą kopię i jeszcze raz przejrzyj zmianę, zamiast przepychać swój nieaktualny plik.

Gość nadal musi kierować pakiet

Uprawnienie w chmurze nie czyni urządzenia routerem. Potwierdź, że trasa VPC wybiera tę VM jako następny skok dla prefiksu docelowego, oraz że gość kieruje pakiety między tunelem a właściwym interfejsem z włączoną własną polityką przekazywania.

Polityka zapory musi zezwalać na przepływ wewnętrzny oraz na odbiornik zewnętrzny. Otwarcie tylko portu VPN opisuje zaszyfrowany transport i nic nie mówi o wymianie aplikacji w jego wnętrzu.

Na koniec cel potrzebuje ścieżki powrotnej do puli klientów albo projekt musi świadomie tłumaczyć źródła. Jeśli cel widzi przetłumaczony ruch, sprawdź przetłumaczone źródło; jeśli projekt zachowuje pulę, sprawdź tę pulę w trasie powrotnej i regułach dostępu. Dodanie NAT, zanim zdecydujesz, którego projektu chcesz, ukrywa brakującą trasę i zmienia politykę widzianą przez cel.

Na bramie Linux przekazywanie w jądrze jest częścią konfiguracji gościa. Urządzenie pfSense ma swój odpowiednik, a kopiowanie do niego polecenia sysctl z Linuksa nie jest właściwym krokiem.

Zweryfikuj z klienta, który potrzebuje dostępu

Testuj z klienta VPN do jednej usługi docelowej, nie z samej bramy. Połączenie rozpoczęte na bramie używa innego źródła i nigdy nie przechodzi przez reguły przekazywania, które właśnie włączyłeś.

Zapisz właściwość w tym, co zarządza urządzeniem. Ręcznie poprawiona VM działa do następnego odtworzenia, które po cichu przywraca pierwotne ustawienie, a ta awaria będzie wyglądać jak regresja w oprogramowaniu VPN.

Kolejność pracy: odczytaj właściwość, wyeksportuj i edytuj jedną linię, zwaliduj z NO_EFFECT, zastosuj z REFRESH, potwierdź, że gość przekazuje, a potem testuj z klienta.