GCP Cloud VPN: गेटवे, टनेल आणि फायरवॉल क्रमाने तपासा

तुमचा कन्सोल हिरवा टनेल दाखवतो, ऑन-प्रिमाइस देखरेख अजूनही एकाही इन्स्टन्सपर्यंत पोहोचू शकत नाही, आणि टनेल पुन्हा बांधणे हाच स्पष्ट उपाय वाटतो. पण असे क्वचितच असते. स्थापित टनेल फक्त एवढेच सिद्ध करते की दोन गेटवेने IKE देवघेव पूर्ण केली. पॅकेटला तुमच्या VPC मध्ये कधी प्रवेश मिळाला होता का, याबद्दल ते काहीच सांगत नाही.

त्या हिरव्या चिन्हापासून प्रत्युत्तरापर्यंत चार निर्णय आहेत आणि ते अंदाजे क्रमाने अपयशी होतात. सर्वात स्वस्तापासून सुरुवात करा.

तीन ऑब्जेक्ट, आणि त्यातील फक्त एक एन्क्रिप्ट करते

VPN गेटवे त्या बाह्य पत्त्याचा मालक आहे ज्यावर तुमचा पीअर एन्क्रिप्ट करतो. कन्सोलमध्ये तुम्ही ते कधीही हाताने तयार करत नाही: कनेक्शन फॉर्ममध्ये पत्ता निवडा किंवा राखून ठेवा आणि गेटवे त्यासोबत दिसते. HA गेटवे दोन इंटरफेसवर दोन पत्ते घेते, ज्याचे महत्त्व नंतर कोटा तपासणीत आहे.

टनेल म्हणजे त्या गेटवे आणि पीअरमधील जोडी. ते सामायिक गुप्त आणि संरक्षित करण्याचे वचन दिलेले ट्रॅफिक सिलेक्टर वाहते. बहुतेक शांत अपयश याच सिलेक्टरपासून सुरू होतात. ज्या टनेलचा स्थानिक सिलेक्टर 10.0.0.0/24 व्यापतो ते स्थिती कितीही निरोगी दिसली तरी 10.0.1.0/24 पोहोचवणार नाही.

दूरची बाजू स्वतःची यादी ठेवते, जिला सहसा एन्क्रिप्शन डोमेन म्हणतात, आणि टर्मिनेटिंग हार्डवेअर तिची तुमच्याशी तुलना करते. कोणतीही बाजू अशा सिलेक्टरवर वाटाघाटी करत नाही जो तिला कधीच दिला गेला नाही.

राउटिंग प्रकार ठरवतो की राउट टेबलपर्यंत काय पोहोचते

Cloud VPN तीन राउटिंग आकार देते आणि ते स्वच्छपणे मिसळत नाहीत. धोरण-आधारित राउटिंग स्थिर सिलेक्टर जोड्या ठेवते, मार्ग-आधारित राउटिंग तुम्ही स्वतः स्थिर मार्ग जोडाल अशी अपेक्षा करते, आणि गतिशील राउटिंग BGP वर Cloud Router मार्फत उपसर्ग जाहीर करते. जाणीवपूर्वक एक निवडा.

शेजारी हाताने लिहिलेले स्थिर मार्ग असलेले गतिशील टनेल असे राउट टेबल तयार करते जे BGP सत्र डगमगले की रिकामे होते.

गतिशील हाच एकमेव आकार आहे जो टनेल पुन्हा न बांधता संरक्षित उपसर्ग बदलू देतो, आणि तो Cloud Router ला तुम्हाला पडताळायच्या ऑब्जेक्टच्या संचात ओढतो. पीअर BGP बोलू न शकणारा हार्डवेअर फायरवॉल असेल तेव्हा स्थिर सिलेक्टर वापरण्यायोग्य राहतात. तेव्हा दोन्ही टोकांना तेच श्रेणी लागतात, आणि अधिक विशिष्ट नोंदीने दोन्हीकडे जिंकले पाहिजे. एका सबनेटने वेगळी असलेली जोडी स्थापित होते आणि नंतर तुमचा अर्धा रहदारी वाहते.

निहित नकार टनेलच्या मागे बसतो

आवक रहदारीचे मूल्यमापन सर्वात कमी प्राधान्यावरील निहित नकाराशी केले जाते, आणि त्या नियमाला पॅकेट एन्क्रिप्ट होऊन आले याची पर्वा नाही. फायरवॉल नियमाने ऑन-प्रिमाइस श्रेणी आणि वापरातील पोर्टचे नाव घेईपर्यंत पॅकेट डिक्रिप्ट होते, तपासले जाते आणि टाकून दिले जाते. VPN लॉग संपूर्ण वेळ स्वच्छ राहतो, कारण टनेलने वचन दिलेलेच केले.

त्याऐवजी टनेल सुरू असताना आणि प्रोबची वेळ संपल्यावर फायरवॉल नकार लॉग वाचा, नंतर नियम स्रोत श्रेणी आणि आवश्यक पोर्टपर्यंत मर्यादित करा:

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

एकच दिशा चालणे हा फायरवॉलचा सुगावा आहे

बाहेर जाणारी रहदारी वेगळी वागते, कारण निहित परवानगी नियम इन्स्टन्सना कुठेही पाठवू देतो. VM पर्यंत पोहोचू न शकणारे डेटा सेंटर बऱ्याचदा दुसऱ्या दिशेने पूर्णपणे कार्यरत बाहेर जाणाऱ्या मार्गाच्या मागे असते. ही विषमता फायरवॉलची चूक आणि राउटिंग बिघाड वेगळे करते, कारण राउटिंग बिघाड दोन्ही दिशा एकाच वेळी तोडतो. अजून एक नियम संपादित करण्यापूर्वी उलटी दिशा तपासा.

पत्ता तयार करणेही कोटा क्रिया आहे. वापरातील बाह्य पत्त्यांच्या मर्यादेजवळ असलेला प्रकल्प परवानगी अपयशासारखा वाचला जाणारा त्रुटीने कनेक्शन नाकारतो.

सिलेक्टर, कोटा, मग चार तपासण्या

कन्सोलमध्ये तयार केलेले टनेल कधीकधी gcloud compute vpn-tunnels describe मधून रिकामा दूरस्थ ट्रॅफिक सिलेक्टर परत देतात, तर तयार झालेले मार्ग रहदारी योग्यरीत्या वाहतात. टनेल चुकीचे आहे असे ठरवण्यापूर्वी API जे नोंदवते त्याची तुम्ही प्रत्यक्ष संरक्षित करत असलेल्या श्रेणीशी तुलना करा. API किंवा SDK मार्फत तयार केल्यास सिलेक्टर स्पष्ट राहतो.

कोटा हा दुसरा सोपा चुकलेला मुद्दा आहे. देखभाल विंडोच्या आधी वाढ मागा, तिच्यादरम्यान नाही, आणि गेटवे असलेल्या त्याच प्रकल्पात पत्त्यांची संख्या तपासा.

बाहेरून आत काम करा: पीअर स्थिती, दोन्ही सिलेक्टर याद्या, प्रत्येक बाजूसाठी मार्ग, स्रोत श्रेणी आणि पोर्टसाठी आवक नियम, मग पॅकेट कॅप्चर. टनेल नवीन असतानाच गेटवे पत्ता, दोन्ही सिलेक्टर याद्या आणि राउटिंग प्रकार बदल तिकिटात लिहा, कारण सबनेट जोडणाऱ्या पुढील अभियंत्याला तिन्ही लागतील.