Terraform मध्ये GCP Classic VPN: टनेल मार्ग-आधारित करा

Classic VPN मध्ये लेबल वर्तन ठरवत नाही. मार्ग-आधारित म्हणजे 0.0.0.0/0 स्थानिक निवडक, जुळणारे दूरस्थ निवडक आणि स्पष्ट मार्ग.

योजना स्वच्छपणे लागू होते, टनेल वर येते, आणि कन्सोल तिला धोरण-आधारित म्हणते. रहदारी तरीही जात नाही, आणि 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 संदर्भात।

संबंधित लेख