GCP Classic VPN w Terraformie: zrób tunel oparty na trasach

Plan stosuje się czysto, tunel wstaje, a konsola nazywa go opartym na politykach. Ruch nadal nie przechodzi, a szukanie przełącznika opartego na trasach w zasobie Terraform donikąd nie prowadzi, bo takiego pola nie ma. W Classic VPN zachowanie oparte na trasach nie jest trybem, który się wybiera. Dostaje się to, gdy lokalny selektor ruchu ma wartość 0.0.0.0/0, a selektory zdalne wymieniają sieci, których naprawdę chcemy, i trasa wskazuje tunel. Trzy rzeczy, i etykieta podąża za nimi.

Mit: pole trybu tunelu

Etykieta w konsoli odzwierciedla to, co API widzi w selektorach. Nic w zasobie nie mówi oparty na trasach, więc nie ma czego ustawić na prawdę.

Szukanie tego pola zjada pierwszą godzinę problemu, a odczyt wartości selektorów zajmuje ostatnie pięć minut.

Co tu znaczy oparty na trasach

Google dokumentuje tunele oparte na trasach w Classic VPN jako tunele oparte na politykach, których lokalny selektor to 0.0.0.0/0. Nazywane są tylko zakresy zdalne, a strona lokalna jest traktowana jak dowolny adres. Dlatego znacznik w konfiguracji jest wartością, a nie trybem. Zapisz oba selektory jawnie i odczytaj je w wyniku planu:

local_traffic_selector  = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]

Prefiks peera w tym fragmencie jest ilustracyjny; liczy się kształt.

Trasa to osobny obiekt

Obiekt tunelu nie instaluje trasy. Pakiety mogą pasować do polityki tunelu i nadal nie mieć gdzie iść, bo następny skok ustala tabela routingu VPC. Trasa potrzebuje zakresu docelowego, sieci, tunelu jako następnego skoku i priorytetu, który wygrywa z czymkolwiek szerszym. Zapomnienie o tym daje tunel zgłaszający stan nawiązany i ping, który nigdy nie opuszcza VPC.

resource "google_compute_route" "office" {
  name                = "office-via-vpn"
  dest_range          = "10.20.0.0/16"
  network             = google_compute_network.vpc.name
  next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
  priority            = 1000
}

Twórz trasę w tym samym module co tunel, żeby oba nie rozjechały się w przeglądzie.

Odbij selektory po stronie peera

Zdalne urządzenie trzeba skonfigurować lustrzanie: jego zakres lokalny to twój selektor zdalny, a jego zakres zdalny musi obejmować podsieci GCP, których zamierzasz używać. Jeśli którakolwiek strona się zwęzi, faza 2 zawodzi, nawet gdy faza 1 się udaje. To najczęstsza postać konfiguracji, która w konsoli wygląda dobrze i nie przenosi ruchu.

Wydrukuj selektory obu stron obok siebie podczas przeglądu zmiany.

Podziel statyczny adres na dwa zastosowania

Tworzenie zarezerwowanego adresu i tunelu, który się do niego odwołuje, w jednym zastosowaniu to znane źródło niestabilności, bo adres musi istnieć, zanim reguła przekazywania będzie mogła go użyć. Najpierw zastosuj sam zasób adresu, potem dodaj bramę, reguły przekazywania i tunel i zastosuj ponownie. Terraform odczytuje istniejący adres ze stanu przy drugim uruchomieniu i używa go ponownie. Jeśli to pominiesz, tunel może dostać nowy publiczny adres przy każdym zastosowaniu, co za każdym razem psuje konfigurację peera.

Dwa zastosowania teraz są tańsze niż zmiana peera przy każdym wydaniu.

Sprawdzaj negocjację, nie etykietę

Po zastosowaniu sprawdź trzy osobne fakty: tunel zgłasza stan nawiązany, trasa istnieje z zamierzonym następnym skokiem, a peer zgłasza, że faza 1 i faza 2 są aktywne.

Tunel działa, ale faza 2 leży, co znaczy, że obie strony nie zgadzają się co do selektorów:

• Jedna strona wymienia podsieć, której druga nie wymienia.
• Jedna strona używa agregatu, który druga zwęziła.
• Trasa istnieje, ale wskazuje inny tunel.

Classic VPN to jeden tunel z niższym SLA niż HA VPN, a HA VPN używa dwóch interfejsów, dwóch tuneli i BGP z innymi typami zasobów. Kopiowanie klasycznego przykładu do konfiguracji HA i oczekiwanie, że pola selektorów będą zachowywać się tak samo, to osobny błąd, którego warto unikać. Same pola tunelu są udokumentowane w dokumentacji google_compute_vpn_tunnel.