GCP Classic VPN v Terraforme: urobte tunel smerovaný

V Classic VPN popis nerozhoduje o správaní. Smerovaný znamená lokálny selektor 0.0.0.0/0, zodpovedajúce vzdialené selektory a explicitnú trasu.

Plán sa aplikuje čisto, tunel naskočí a konzola ho nazýva založený na pravidlách. Premávka stále neprechádza a hľadanie prepínača smerovaného režimu v zdroji Terraform nikam nevedie, pretože také pole neexistuje. V Classic VPN nie je smerované správanie režim, ktorý si vyberiete. Je to to, čo dostanete, keď je lokálny selektor premávky 0.0.0.0/0, vzdialené selektory vypisujú siete, ktoré naozaj chcete, a trasa ukazuje na tunel. Tri veci a popis nasleduje.

Mýtus: pole režimu tunela

Popis v konzole odráža to, čo API vidí v selektoroch. Nič v zdroji nehovorí smerovaný, takže niet čo nastaviť na pravda.

Hľadanie toho poľa spotrebuje prvú hodinu problému, zatiaľ čo čítanie hodnôt selektorov zaberie posledných päť minút.

Čo tu smerovaný znamená

Google dokumentuje smerované tunely Classic VPN ako tunely založené na pravidlách, ktorých lokálny selektor je 0.0.0.0/0. Uvádzajú sa len vzdialené rozsahy a lokálna strana sa považuje za ľubovoľnú adresu. Preto je značka vo vašej konfigurácii hodnota, a nie režim. Napíšte oba selektory explicitne a prečítajte ich vo výstupe plánu:

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

Prefix partnera v tomto úryvku je ilustratívny; dôležitý je tvar.

Trasa je samostatný objekt

Objekt tunela neinštaluje trasu. Pakety môžu zodpovedať pravidlám tunela a napriek tomu nemajú kam ísť, pretože ďalší skok určuje smerovacia tabuľka VPC. Trasa potrebuje cieľový rozsah, sieť, tunel ako ďalší skok a prioritu, ktorá preváži čokoľvek širšie. Keď na to zabudnete, vznikne tunel, ktorý hlási nadviazané spojenie, a ping, ktorý nikdy neopustí 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
}

Vytvorte trasu v tom istom module ako tunel, aby sa obe pri revízii nerozišli.

Zrkadlite selektory na partnerovi

Vzdialené zariadenie musí byť nakonfigurované zrkadlovo: jeho lokálny rozsah je váš vzdialený selektor a jeho vzdialený rozsah musí pokrývať podsiete GCP, ktoré hodláte používať. Keď sa ktorákoľvek strana zúži, fáza 2 zlyhá, aj keď fáza 1 uspeje. To je najčastejšia podoba konfigurácie, ktorá v konzole vyzerá správne a neprenáša premávku.

Vytlačte selektory oboch strán vedľa seba pri revízii zmeny.

Rozdeľte statickú adresu do dvoch aplikácií

Vytvorenie rezervovanej adresy a tunela, ktorý na ňu odkazuje, v jednej aplikácii je známym zdrojom nestability, pretože adresa musí existovať skôr, než ju pravidlo presmerovania môže použiť. Najprv aplikujte len zdroj adresy, potom pridajte bránu, pravidlá presmerovania a tunel a aplikujte znova. Terraform prečíta existujúcu adresu zo stavu pri druhom behu a znova ju použije. Keď to preskočíte, tunel môže pri každej aplikácii dostať novú verejnú adresu, čo zakaždým pokazí konfiguráciu partnera.

Dve aplikácie teraz sú lacnejšie než zmena partnera pri každom vydaní.

Overujte vyjednávanie, nie popis

Po aplikácii skontrolujte tri oddelené fakty: tunel hlási nadviazané spojenie, trasa existuje so zamýšľaným ďalším skokom a partner hlási, že fáza 1 aj fáza 2 sú hore.

Tunel je hore, ale fáza 2 dole, čo znamená, že obe strany sa nezhodujú na selektoroch:

  • Jedna strana uvádza podsieť, ktorú druhá neuvádza.
  • Jedna strana používa agregát, ktorý druhá zúžila.
  • Trasa existuje, ale ukazuje na iný tunel.

Classic VPN je jediný tunel s nižším SLA než HA VPN a HA VPN používa dve rozhrania, dva tunely a BGP s inými typmi zdrojov. Kopírovanie klasického príkladu do konfigurácie HA a očakávanie, že sa polia selektorov budú správať rovnako, je samostatná chyba, ktorej sa oplatí vyhnúť. Samotné polia tunela sú zdokumentované v referencii google_compute_vpn_tunnel.

Súvisiace články