ప్లాన్ శుభ్రంగా వర్తిస్తుంది, టన్నెల్ పైకి వస్తుంది, మరియు కన్సోల్ దాన్ని విధాన ఆధారితం అని పిలుస్తుంది. ట్రాఫిక్ ఇప్పటికీ దాటదు, మరియు Terraform వనరులో మార్గ ఆధారిత టోగుల్ వెతకడం ఎక్కడికీ చేరదు ఎందుకంటే అలాంటి ఫీల్డ్ లేదు. Classic VPN లో మార్గ ఆధారిత ప్రవర్తన మీరు ఎంచుకునే మోడ్ కాదు. ఇది స్థానిక ట్రాఫిక్ ఎంపికి 0.0.0.0/0 అయినప్పుడు, దూర ఎంపికలు మీరు నిజంగా కోరుకునే నెట్‌వర్క్‌లను జాబితా చేసినప్పుడు, మరియు ఒక మార్గం టన్నెల్ వైపు చూపినప్పుడు లభిస్తుంది. మూడు విషయాలు, మరియు లేబుల్ వాటిని అనుసరిస్తుంది.

అపోహ: టన్నెల్ మోడ్ ఫీల్డ్

కన్సోల్ లేబుల్ API ఎంపికల్లో ఏమి చూస్తుందో ప్రతిబింబిస్తుంది. వనరులో ఏదీ మార్గ ఆధారితం అని చెప్పదు, కాబట్టి నిజ మూల్యానికి సెట్ చేయడానికి ఏమీ లేదు.

ఆ ఫీల్డ్‌ను వెతకడం సమస్య మొదటి గంటను తినేస్తుంది, ఎంపికల విలువలను చదవడం చివరి ఐదు నిమిషాలు తీసుకుంటుంది.

ఇక్కడ మార్గ ఆధారితం అంటే ఏమిటి

Google Classic VPN యొక్క మార్గ ఆధారిత టన్నెల్‌లను విధాన ఆధారిత టన్నెల్‌లుగా నమోదు చేస్తుంది, వాటి స్థానిక ఎంపికి 0.0.0.0/0 ఉంటుంది. దూర పరిధులు మాత్రమే పేరు పొందుతాయి, స్థానిక వైపు ఏదైనా చిరునామాగా పరిగణించబడుతుంది. అందుకే మీ కాన్ఫిగరేషన్‌లోని గుర్తు మోడ్ కాదు, విలువ. రెండు ఎంపికలను స్పష్టంగా రాయండి మరియు ప్లాన్ అవుట్‌పుట్‌లో చదవండి:

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

ఆ స్నిప్పెట్‌లో పీర్ ప్రిఫిక్స్ ఉదాహరణ మాత్రమే; ఆకారమే ముఖ్యమైన భాగం.

మార్గం ఒక ప్రత్యేక వస్తువు

టన్నెల్ వస్తువు మార్గాన్ని ఇన్‌స్టాల్ చేయదు. ప్యాకెట్లు టన్నెల్ విధానానికి సరిపోయినా వెళ్లడానికి స్థలం ఉండకపోవచ్చు, ఎందుకంటే తదుపరి హాప్‌ను VPC రూటింగ్ పట్టిక నిర్ణయిస్తుంది. మార్గానికి గమ్య పరిధి, నెట్‌వర్క్, తదుపరి హాప్‌గా టన్నెల్ మరియు ఏదైనా విస్తృతమైనదాన్ని ఓడించే ప్రాధాన్యత అవసరం. దీన్ని మరచిపోతే, కనెక్షన్ స్థాపించబడిందని నివేదించే టన్నెల్ మరియు 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
}

టన్నెల్ ఉన్న అదే మాడ్యూల్‌లో మార్గాన్ని సృష్టించండి, సమీక్షలో రెండూ దూరం కాకుండా.

పీర్‌లో ఎంపికలను ప్రతిబింబించండి

దూర పరికరం అద్దం ప్రతిబింబంతో కాన్ఫిగర్ చేయాలి: దాని స్థానిక పరిధి మీ దూర ఎంపికి, దాని దూర పరిధి మీరు ఉపయోగించాలని భావించే GCP సబ్‌నెట్‌లను కవర్ చేయాలి. ఏ వైపు సన్నబడినా, దశ 1 విజయవంతమైనా దశ 2 విఫలమవుతుంది. కన్సోల్‌లో సరిగ్గా కనిపించి ట్రాఫిక్ మోయని కాన్ఫిగరేషన్ యొక్క అత్యంత సాధారణ రూపం ఇదే.

మార్పు సమీక్షలో రెండు వైపుల ఎంపికలను పక్కపక్కనే ముద్రించండి.

స్థిర చిరునామాను రెండు అప్లైలుగా విభజించండి

రిజర్వ్ చేసిన చిరునామా మరియు దాన్ని సూచించే టన్నెల్‌ను ఒకే అప్లైలో సృష్టించడం అస్థిరత యొక్క తెలిసిన మూలం, ఎందుకంటే ఫార్వార్డింగ్ నియమం దాన్ని ఉపయోగించే ముందు చిరునామా ఉండాలి. మొదట చిరునామా వనరును మాత్రమే అప్లై చేయండి, తర్వాత గేట్‌వే, ఫార్వార్డింగ్ నియమాలు మరియు టన్నెల్‌ను జోడించి మళ్లీ అప్లై చేయండి. Terraform రెండవ రన్‌లో స్థితి నుండి ఉన్న చిరునామాను చదివి తిరిగి ఉపయోగిస్తుంది. దీన్ని దాటవేస్తే, ప్రతి అప్లైలో టన్నెల్‌కు కొత్త పబ్లిక్ చిరునామా రావచ్చు, ఇది ప్రతిసారీ పీర్ కాన్ఫిగరేషన్‌ను బద్దలు కొడుతుంది.

ఇప్పుడు రెండు అప్లైలు ప్రతి విడుదలలో పీర్ మార్పు కంటే చౌక.

లేబుల్ కాదు, చర్చలను ధృవీకరించండి

అప్లై చేసిన తర్వాత మూడు ప్రత్యేక వాస్తవాలను తనిఖీ చేయండి: టన్నెల్ కనెక్షన్ స్థాపించబడిందని నివేదిస్తుంది, మార్గం ఉద్దేశించిన తదుపరి హాప్‌తో ఉంది, మరియు పీర్ దశ 1 మరియు దశ 2 రెండూ పైన ఉన్నాయని నివేదిస్తుంది.

టన్నెల్ పైన ఉండి దశ 2 కింద ఉంటే రెండు వైపులూ ఎంపికలపై ఏకీభవించలేదని అర్థం:

  • ఒక వైపు మరొక వైపు జాబితా చేయని సబ్‌నెట్‌ను జాబితా చేస్తుంది.
  • ఒక వైపు మరొక వైపు సన్నగా చేసిన సమూహాన్ని ఉపయోగిస్తుంది.
  • మార్గం ఉంది కానీ మరొక టన్నెల్ వైపు చూపుతుంది.

Classic VPN అనేది HA VPN కంటే తక్కువ SLA ఉన్న ఒకే టన్నెల్, మరియు HA VPN రెండు ఇంటర్‌ఫేస్‌లు, రెండు టన్నెల్‌లు మరియు వేరే వనరు రకాల BGP ఉపయోగిస్తుంది. క్లాసిక్ ఉదాహరణను HA కాన్ఫిగరేషన్‌లోకి కాపీ చేసి ఎంపిక ఫీల్డ్‌లు అదే విధంగా ప్రవర్తిస్తాయని ఆశించడం తప్పించుకోవాల్సిన ప్రత్యేక తప్పు. టన్నెల్ ఫీల్డ్‌లు తామే google_compute_vpn_tunnel సూచనలో.

సంబంధిత వ్యాసాలు