Terraform मा GCP Classic VPN: टनेललाई मार्ग-आधारित बनाउनुहोस्

योजना सफा रूपमा लागू हुन्छ, टनेल माथि आउँछ, र कन्सोलले यसलाई नीति-आधारित भन्छ। ट्राफिक अझै जाँदैन, र 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 सन्दर्भमा।