Plaan rakendub puhtalt, tunnel tõuseb ja konsool nimetab seda poliitikapõhiseks. Liiklus ei lähe ikkagi läbi, ja marsruudipõhise lüliti otsimine Terraformi ressursis ei vii kuhugi, sest sellist välja ei ole olemas. Classic VPN-is ei ole marsruudipõhine käitumine režiim, mille te valite. See on see, mille te saate, kui kohalik liiklusselektor on 0.0.0.0/0, kaugselektorid loetlevad võrgud, mida te tegelikult soovite, ja marsruut osutab tunnelile. Kolm asja ja silt järgneb.

Müüt: tunneli režiimi väli

Konsooli silt peegeldab seda, mida API selektorites näeb. Miski ressursis ei ütle marsruudipõhine, seega pole midagi tõeseks seada.

Selle välja otsimine kulutab probleemi esimese tunni, samas kui selektorite väärtuste lugemine võtab viimased viis minutit.

Mida marsruudipõhine siin tähendab

Google dokumenteerib Classic VPN-i marsruudipõhised tunnelid poliitikapõhiste tunnelitena, mille kohalik selektor on 0.0.0.0/0. Nimetatakse ainult kaugvahemikke ja kohalikku poolt käsitletakse kui mis tahes aadressi. Seetõttu on teie konfiguratsiooni marker väärtus, mitte režiim. Kirjutage mõlemad selektorid selgesõnaliselt ja lugege neid plaani väljundis:

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

Selle katkendi partneri prefiks on illustratiivne; oluline on vorm.

Marsruut on eraldi objekt

Tunneli objekt ei paigalda marsruuti. Paketid võivad vastata tunneli poliitikale ja ikkagi mitte kuhugi jõuda, sest järgmise hüppe otsustab VPC marsruutimistabel. Marsruut vajab sihtvahemikku, võrku, tunnelit järgmise hüppena ja prioriteeti, mis võidab kõike laiemat. Kui selle unustate, saate tunneli, mis teatab ühenduse loomisest, ja kontrolli, mis ei lahku VPC-st kunagi.

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
}

Looge marsruut samas moodulis kui tunnel, et need kaks ülevaatuse käigus lahku ei läheks.

Peegeldage selektorid partneril

Kaugseade tuleb seadistada peegelpildina: selle kohalik vahemik on teie kaugselektor ja selle kaugvahemik peab katma GCP alamvõrgud, mida kavatsete kasutada. Kui kumbki pool kitseneb, ebaõnnestub faas 2, kuigi faas 1 õnnestub. See on kõige tavalisem konfiguratsioon, mis konsoolis õige välja näeb ja liiklust ei kanna.

Printige mõlema poole selektorid muudatuse ülevaatuse ajal kõrvuti.

Jagage staatiline aadress kaheks rakenduseks

Reserveeritud aadressi ja sellele viitava tunneli loomine ühes rakenduses on teadaolev ebastabiilsuse allikas, sest aadress peab olemas olema enne, kui edastusreegel seda kasutada saab. Rakendage kõigepealt ainult aadressi ressurssi, seejärel lisage lüüs, edastusreeglid ja tunnel ning rakendage uuesti. Terraform loeb olemasoleva aadressi olekust teisel käivitamisel ja kasutab seda uuesti. Kui selle vahele jätate, võib tunnel saada igal rakendusel uue avaliku aadressi, mis rikub partneri konfiguratsiooni iga kord.

Kaks rakendust praegu on odavamad kui partneri muudatus igal väljaandel.

Kontrollige läbirääkimist, mitte silti

Pärast rakendamist kontrollige kolme eraldi fakti: tunnel teatab ühenduse loomisest, marsruut on olemas kavandatud järgmise hüppega ja partner teatab, et nii faas 1 kui ka faas 2 on üleval.

Tunnel, mis on üleval, aga faas 2 on maas, tähendab, et kaks poolt ei ole selektorite osas ühel meelel:

  • Üks pool loetleb alamvõrgu, mida teine ei loetle.
  • Üks pool kasutab agregaati, mida teine on kitsendanud.
  • Marsruut on olemas, kuid osutab teisele tunnelile.

Classic VPN on üks tunnel, mille SLA on madalam kui HA VPN-il, ja HA VPN kasutab kahte liidest, kahte tunnelit ja BGP-d erinevate ressursitüüpidega. Klassikalise näite kopeerimine HA konfiguratsiooni ja ootus, et selektoriväljad käituvad samamoodi, on eraldi viga, mida tasub vältida. Tunneli väljad ise on dokumenteeritud google_compute_vpn_tunnel viites.

Seotud artiklid