GCP VM के लिए Cloud VPN: आंतरिक IP इस्तेमाल करें, NAT IP नहीं
गेटवे एंडपॉइंट, VM का आंतरिक पता और बाहरी एक-से-एक NAT पता तीन अलग-अलग काम करते हैं। देखें कि आपका रूट किसका उपयोग करता है।
जब कोई ऑन-प्रिमाइज़ नेटवर्क Cloud VPN के ज़रिए VPC तक पहुँचता है, तो Compute Engine सेवा के लिए गंतव्य आम तौर पर VM का आंतरिक पता होता है। बाहरी IPv4 पता ऐसा दूसरा पता नहीं है जिसे आप उसी निजी रूट में रख सकें। यहाँ अधिकतर उलझन इससे आती है कि तीन कामों वाले तीन पतों को एक-दूसरे के बदले इस्तेमाल करने योग्य मान लिया जाता है, इसलिए पहले यह नाम दें कि कोई दिया हुआ पैकेट किसका उपयोग कर रहा है।
तीन पते, तीन काम
इनमें से किसी को भी डीबग करने से पहले तीनों के नाम बता दें, क्योंकि जवाब यह बदल देता है कि आगे आप कौन-सी वस्तु देखेंगे।
| Address | Job |
|---|---|
| Cloud VPN endpoint | where the IPsec peers meet |
| Internal IP | the address your route and firewall must name |
| External IPv4 | the platform's inbound mapping, not a guest address |
पहला टनल का है। दूसरा आपके रूट और फ़ायरवॉल डिज़ाइन का है। तीसरा इनबाउंड इंटरनेट एक्सेस का है और वह मैप होता है, जोड़ा नहीं जाता। इनमें से किसी एक के लिए काम करने वाला डिज़ाइन बाकी दो के बारे में कुछ नहीं कहता।
बाहरी पता दूसरा इंटरफ़ेस क्यों नहीं है
Compute Engine पर आंतरिक और बाहरी पहुँच कैसे अलग हैं, इसके लिए एड्रेसिंग गाइड ही प्रामाणिक स्रोत है। Compute Engine का बाहरी IPv4 इंस्टेंस के एकमात्र आंतरिक NIC पर एक-से-एक मैपिंग है, इसलिए गेस्ट को उस NIC पर कभी दूसरा इंटरफ़ेस या दूसरा पता नहीं दिखता। VM अंदर से जो रिपोर्ट करता है वह अब भी एक प्राथमिक आंतरिक पता ही है।
इसीलिए एक निजी क्लाइंट जो टनल से 10.24.1.7 की ओर रूट करता है और एक क्लाइंट जो VM के बाहरी पते को लक्षित करता है, अलग-अलग रास्तों पर हैं। सार्वजनिक पते के लिए फ़ायरवॉल नियम खोलने से उस VPC रूट में कुछ नहीं बदलता जिसे टनल का ट्रैफ़िक ढोना है, और गेस्ट रूट संपादित करने से प्लेटफ़ॉर्म की मैपिंग नहीं हिलती। वह पता चुनें जिसका नाम आपका रूट लेता है, फिर केवल उन्हीं वस्तुओं की जाँच करें जो उसे नियंत्रित करती हैं। यह अनुशासन इस ट्रबलशूटिंग रास्ते से अधिकतर अनुमान हटा देता है।
gcloud के साथ रास्ता चलें
इंस्टेंस से शुरू करें और दोनों पते उसी वस्तु से पढ़ें, ताकि आपको पता हो कि आपका दस्तावेज़ किसके बारे में बात कर रहा है:
gcloud compute instances describe app-1 --zone=europe-west1-b \
--format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"फिर उस रूटिंग और अनुमति की पुष्टि करें जिन पर रास्ता वास्तव में निर्भर है:
gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1टनल के घोषित और सीखे गए रेंज पढ़ें, वर्कलोड सबनेट के लिए VPC रूट, और वह फ़ायरवॉल नियम जो ऑन-प्रिमाइज़ स्रोत को अनुमति देता है। गेस्ट पर मौजूद लिसनर के प्रासंगिक होने से पहले इन तीनों को मेल खाना चाहिए।
फिर गेस्ट जाँचें: क्या सेवा आंतरिक पते पर सुन रही है, और क्या उसका वापसी मार्ग फिर से VPC से होकर जाता है? केवल सार्वजनिक पते से बँधा लिसनर इस परीक्षण में विफल होगा, तब भी जब क्लाउड पक्ष की हर वस्तु सही हो।
सार्वजनिक प्रीफ़िक्स एक अलग सवाल है
ऊपर की कोई बात इसका अर्थ नहीं है कि VPN के अंदर ले जाया गया हर पता RFC1918 होना चाहिए। दूरस्थ नेटवर्क को सार्वजनिक स्पेस से वैध रूप से क्रमांकित किया जा सकता है, बशर्ते प्लेटफ़ॉर्म रूटिंग का समर्थन करे और ऑपरेटर के पास पते का अधिकार हो। यह सामान्य डिज़ाइन विकल्प है।
यह किसी सामान्य बाहरी NAT पते को दूसरे आंतरिक सबनेट पते की तरह मानने के बराबर नहीं है। एक प्रीफ़िक्स है जिसे आप रूट करते हैं; दूसरा मैपिंग है जिसे प्लेटफ़ॉर्म इनबाउंड एक्सेस पर लागू करता है।
बाहरी IPv6 और विशेष रूप से डिज़ाइन की गई पता व्यवस्थाओं की अपनी अर्थ-विचार है। यदि आपकी योजना इनमें से किसी एक पर निर्भर है, तो IPv4 मामले से सामान्यीकरण करने के बजाय उस सुविधा के लिए प्लेटफ़ॉर्म दस्तावेज़ पढ़ें। IPv4 मैपिंग सामान्य मामला है, एकमात्र नहीं, और हर अपवाद के अपने नियम हैं।
ओवरलैपिंग रेंज एक अलग समस्या है
ओवरलैपिंग निजी रेंज वह असली कारण हैं जिनसे लोग सार्वजनिक पते की ओर बढ़ते हैं, और यह गलत लीवर है। गंतव्य को VM के NAT पते में बदलने से ओवरलैप हल नहीं होता; इससे बदलता है कि पैकेट किस पते के लिए होने का दावा करता है, बिना यह परिभाषित किए कि वापसी मार्ग कैसे काम करता है।
ओवरलैप को जानबूझकर हल करें: फिर से क्रमांकन करें, समर्थित अनुवाद डिज़ाइन अपनाएँ, या ऐसे नेटवर्क से रूट करें जहाँ प्रीफ़िक्स टकराते नहीं। इनमें से हर एक मालिक वाला डिज़ाइन है। NAT पता कोई डिज़ाइन नहीं है।
दोनों फ़ील्ड अलग-अलग दस्तावेज़ करें
टनल पीयर और वर्कलोड गंतव्य को दो अलग रनबुक फ़ील्ड के रूप में दर्ज करें, हर एक के साथ वह रूट और फ़ायरवॉल नियम जो उसे सहारा देता है। ऊपर आने वाली IPsec टनल केवल यह बताती है कि दोनों पक्ष सहमत हैं; यह नहीं बताती कि वर्कलोड किस पते पर पहुँच योग्य है, और न ही यह कि उसका निजी रूट पूरा है या नहीं।
दूसरी तरफ़ एक वास्तविक क्लाइंट से सत्यापित करें: नाम रिज़ॉल्व करें, पुष्टि करें कि वह आंतरिक पता लौटाता है, कनेक्ट करें और वापसी ट्रैफ़िक जाँचें। Compute Engine IP पता दस्तावेज़ ऊपर इस्तेमाल किए गए आंतरिक-बनाम-बाहरी अंतर का संदर्भ है।