GCP VM मा Cloud VPN: NAT IP होइन, आन्तरिक 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 ठेगाना कागजात माथि प्रयोग गरिएको आन्तरिक-विरुद्ध-बाह्य भिन्नताको सन्दर्भ हो।