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 पत्ता दस्तऐवज वर वापरलेल्या अंतर्गत-विरुद्ध-बाह्य फरकाचा संदर्भ आहे.