GCP Cloud VPN: sprawdź bramę, tunel i firewall po kolei

Tunel, który zgłasza stan nawiązany, gdy każde sondowanie kończy się przekroczeniem czasu, zwykle nie ma reguły firewalla VPC. Sprawdź bramę, selektory i typ routingu w tej kolejności.

Konsola pokazuje zielony tunel, monitorowanie lokalne nadal nie dociera do żadnej instancji, a odbudowa tunelu wygląda na oczywiste rozwiązanie. Rzadko nim jest. Nawiązany tunel dowodzi tylko, że dwie bramy zakończyły wymianę IKE. Nie mówi nic o tym, czy pakiet kiedykolwiek został wpuszczony do Twojej VPC.

Między tą zieloną ikoną a odpowiedzią stoją cztery decyzje i zawodzą w przewidywalnej kolejności. Zacznij od najtańszej.

Trzy obiekty, a tylko jeden z nich szyfruje

Brama VPN posiada adres zewnętrzny, do którego szyfruje Twój peer. W konsoli nigdy nie tworzysz jej ręcznie: wybierz lub zarezerwuj adres w formularzu połączenia, a brama pojawi się razem z nim. Brama HA zajmuje dwa adresy na dwóch interfejsach, co ma znaczenie przy kontroli limitów później.

Tunel to sparowanie tej bramy z peerem. Przenosi współdzielony sekret i selektory ruchu, które obiecuje chronić. Właśnie w tych selektorach zaczyna się większość cichych awarii. Tunel, którego lokalny selektor obejmuje 10.0.0.0/24, nie dostarczy 10.0.1.0/24, niezależnie od tego, jak zdrowy wygląda status.

Dalsza strona trzyma własną listę, zwykle nazywaną domeną szyfrowania, a sprzęt kończący porównuje ją z Twoją. Żadna strona nie negocjuje selektora, którego nigdy nie otrzymała.

Typ routingu decyduje, co trafia do tablicy routingu

Cloud VPN oferuje trzy kształty routingu i nie mieszają się one czysto. Routing oparty na politykach zachowuje statyczne pary selektorów, routing oparty na trasach oczekuje, że sam dodasz trasy statyczne, a routing dynamiczny ogłasza prefiksy przez Cloud Router po BGP. Wybierz jeden świadomie.

Dynamiczny tunel z ręcznie zapisanymi trasami statycznymi obok daje tablicę routingu, która pustoszeje za każdym razem, gdy sesja BGP się zachwieje.

Dynamiczny to jedyny kształt, który pozwala chronionym prefiksom zmieniać się bez odbudowy tunelu, i wciąga Cloud Router do zbioru obiektów, które musisz zweryfikować. Statyczne selektory pozostają użyteczne, gdy peer jest sprzętowym firewallem, który nie potrafi mówić po BGP. Wtedy oba końce potrzebują tych samych zakresów, a bardziej szczegółowy wpis musi wygrać po obu stronach. Para, która różni się o jedną podsieć, nawiązuje połączenie, a potem niesie połowę Twojego ruchu.

Domniemane odrzucenie siedzi za tunelem

Ruch przychodzący jest oceniany wobec domniemanego odrzucenia o najniższym priorytecie, a ta reguła nie dba o to, że pakiet przyszedł zaszyfrowany. Dopóki reguła firewalla nie wskaże zakresu lokalnego i używanego portu, pakiet jest odszyfrowywany, sprawdzany i odrzucany. Dziennik VPN pozostaje przez cały czas czysty, bo tunel zrobił dokładnie to, co obiecał.

Zamiast tego przeczytaj dziennik odrzuceń firewalla, gdy tunel działa, a sondowanie przekracza czas, a następnie ogranicz regułę do zakresu źródłowego i potrzebnych portów:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

Działanie tylko w jedną stronę to wskazówka o firewallu

Ruch wychodzący zachowuje się inaczej, bo domniemana reguła zezwolenia pozwala instancjom wysyłać gdziekolwiek. Centrum danych, które nie dociera do VM, często stoi za doskonale działającą ścieżką wyjściową w drugą stronę. Ta asymetria oddziela przeoczenie firewalla od awarii routingu, bo awaria routingu psuje oba kierunki naraz. Przetestuj kierunek odwrotny, zanim edytujesz jeszcze jedną regułę.

Tworzenie adresów to także operacja limitowa. Projekt blisko limitu używanych adresów zewnętrznych odrzuca połączenie błędem, który brzmi jak brak uprawnień.

Selektory, limity, potem cztery kontrole

Tunele tworzone w konsoli czasami zwracają pusty zdalny selektor ruchu z gcloud compute vpn-tunnels describe, podczas gdy wygenerowane trasy poprawnie przenoszą ruch. Porównaj to, co rejestruje API, z zakresami, które naprawdę chronisz, zanim uznasz tunel za błędny. Utworzenie go przez API lub SDK utrzymuje selektor jawnym.

Limity to kolejne łatwe przeoczenie. Poproś o zwiększenie przed oknem serwisowym, a nie w jego trakcie, i sprawdź liczbę adresów w tym samym projekcie co brama.

Pracuj od zewnątrz do wewnątrz: status peera, obie listy selektorów, trasa dla każdej strony, reguła wejściowa dla zakresu źródłowego i portu, a potem przechwycenie pakietów. Zapisz adres bramy, obie listy selektorów i typ routingu w zgłoszeniu zmian, dopóki tunel jest nowy, bo następny inżynier, który doda podsieć, będzie potrzebował wszystkich trzech.

Powiązane artykuły