GCP Classic VPN en Terraform: faru la tunelon survoja
En Classic VPN la etikedo ne decidas la konduton. Survoja signifas lokan selektilon 0.0.0.0/0, kongruajn malproksimajn selektilojn kaj eksplicitan itineron.
La plano aplikiĝas pure, la tunelo ekfunkcias, kaj la konzolo nomas ĝin politiko-bazita. La trafiko ankoraŭ ne pasas, kaj la serĉado de survoja ŝaltilo en la Terraform-rimedo kondukas nenie, ĉar tia kampo ne ekzistas. En Classic VPN, survoja konduto ne estas reĝimo, kiun vi elektas. Ĝi estas tio, kion vi ricevas, kiam la loka trafika selektilo estas 0.0.0.0/0, la malproksimaj selektiloj listigas la retojn, kiujn vi vere volas, kaj itinero montras al la tunelo. Tri aferoj, kaj la etikedo sekvas.
La mito: kampo por tunela reĝimo
La etikedo de la konzolo spegulas tion, kion la API vidas en la selektiloj. Nenio en la rimedo diras survoja, do estas nenio por agordi al vera.
Serĉi tiun kampon konsumas la unuan horon de la problemo, dum legi la selektilajn valorojn prenas la lastajn kvin minutojn.
Kion survoja signifas ĉi tie
Google dokumentas la survojajn tunelojn de Classic VPN kiel politiko-bazitajn tunelojn, kies loka selektilo estas 0.0.0.0/0. Nur la malproksimaj intervaloj estas nomataj, kaj la loka flanko traktiĝas kiel ajna adreso. Tial la markilo en via agordo estas valoro, ne reĝimo. Skribu ambaŭ selektilojn eksplice kaj legu ilin en la eligon de la plano:
local_traffic_selector = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]
La samtavolana prefikso en tiu fragmento estas ilustra; la formo estas la grava parto.
La itinero estas aparta objekto
Tunela objekto ne instalas itineron. Paketoj povas kongrui kun la politiko de la tunelo kaj tamen havi nenien por iri, ĉar la VPC-enkursiga tabelo decidas la sekvan salteton. La itinero bezonas la celan intervalon, la reton, la tunelon kiel sekvan salteton kaj prioritaton, kiu venkas ĉion pli vastan. Se vi forgesos tion, vi ricevos tunelon, kiu raportas establon, kaj kontrolon, kiu neniam forlasas la 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
}
Kreu la itineron en la sama modulo kiel la tunelo, por ke la du ne disiĝu dum revizio.
Spegulu la selektilojn ĉe la samtavolano
La malproksima aparato devas esti agordita spegule: ĝia loka intervalo estas via malproksima selektilo, kaj ĝia malproksima intervalo devas kovri la GCP-subretojn, kiujn vi intencas uzi. Se iu ajn flanko mallarĝiĝas, fazo 2 malsukcesas eĉ se fazo 1 sukcesas. Tio estas la plej ofta formo de agordo, kiu aspektas ĝusta en la konzolo kaj transportas nenian trafikon.
Presu la selektilojn de ambaŭ flankoj unu apud la alia dum la ŝanĝa revizio.
Dividu la statikan adreson en du aplikojn
Krei la rezervitan adreson kaj la tunelon, kiu referencas ĝin, en unu apliko estas konata fonto de malstabileco, ĉar la adreso devas ekzisti antaŭ ol la plusenda regulo povas uzi ĝin. Apliku unue nur la adresan rimedon, poste aldonu la enirejon, la plusendajn regulojn kaj la tunelon, kaj apliku denove. Terraform legas la ekzistantan adreson el la stato dum la dua rulo kaj reuzas ĝin. Se vi tion preterlasos, la tunelo povas ricevi novan publikan adreson ĉe ĉiu apliko, kio rompas la agordon de la samtavolano ĉiufoje.
Du aplikoj nun estas pli malmultekostaj ol ŝanĝo de samtavolano ĉe ĉiu eldono.
Kontrolu la intertraktadon, ne la etikedon
Post la apliko, kontrolu tri apartajn faktojn: la tunelo raportas establon, la itinero ekzistas kun la intencita sekva salteto, kaj la samtavolano raportas, ke kaj fazo 1 kaj fazo 2 funkcias.
Tunelo, kiu funkcias dum fazo 2 estas mallevita, signifas, ke la du flankoj malkonsentas pri la selektiloj:
- Unu flanko listigas subreton, kiun la alia ne listigas.
- Unu flanko uzas agregaton, kiun la alia mallarĝigis.
- La itinero ekzistas sed montras al alia tunelo.
Classic VPN estas unu tunelo kun pli malalta SLA ol HA VPN, kaj HA VPN uzas du interfacojn, du tunelojn kaj BGP kun malsamaj rimedaj tipoj. Kopii klasikan ekzemplon en HA-agordon kaj atendi, ke la selektilaj kampoj kondutu same, estas aparta eraro, kiun indas eviti. La tunelaj kampoj mem estas dokumentitaj en la referenco de google_compute_vpn_tunnel.