विद्यमान GCE VPN गेटवेवर IP फॉरवर्डिंग सक्षम करा

VM IP फॉरवर्डिंगशिवाय तयार केले होते, ते आधीच VPN सॉफ्टवेअर चालवत आहे, आणि ध्वज सेट करून ते टेम्पलेटवरून पुन्हा तयार करण्याची सहज प्रवृत्ती होते. ते पुनर्निर्माण अनावश्यक आहे. Compute Engine canIpForward ला अद्ययावत करण्यायोग्य गुणधर्म म्हणून उघड करते, आणि दस्तऐवजीकृत अद्ययावत मार्ग तो रीस्टार्टऐवजी refresh सह लागू करतो. ध्वज प्रत्यक्षात जे नियंत्रित करतो ते अरुंद आहे: त्याशिवाय प्लॅटफॉर्म अशी पॅकेट्स टाकून देतो जी इन्स्टन्सवर पोहोचतात पण इन्स्टन्सच्या स्वतःच्या पत्त्यावर पाठवलेली नसतात. इतर मशीनची रहदारी फॉरवर्ड करणारा गेटवे नेमके तेच करतो, म्हणून ध्वज चालू असणे आवश्यक आहे. त्यानंतरचे सर्व काही अतिथी कॉन्फिगरेशन आणि राउटिंग आहे, ज्यांना ध्वज स्पर्श करत नाही.

ध्वज काय परवानगी देतो, आणि काय नाही

फॉरवर्डिंग बंद असताना प्लॅटफॉर्म इन्स्टन्सला अंतिम बिंदू म्हणून वागवतो. ज्यांचे गंतव्य इन्स्टन्सचे स्वतःचे पत्ता आहे अशी पॅकेट्स दिली जातात; इन्स्टन्सने दुसऱ्याच्या वतीने पुढे पाठवायची पॅकेट्स दिली जात नाहीत.

फॉरवर्डिंग चालू असताना इन्स्टन्स VPC मार्गासाठी पुढील हॉप म्हणून कार्य करू शकतो, आणि हीच VPN उपकरणाला आवश्यक भूमिका आहे. ध्वज फायरवॉल, अतिथी राउटिंग, बोगदा कॉन्फिगरेशन किंवा परतीच्या मार्गांबद्दल काहीही सांगत नाही, आणि तुटलेल्या गेटवेवर true मूल्य अजूनही तुटलेला गेटवे आहे.

सध्याचा गुणधर्म वाचा

काहीही बदलण्यापूर्वी सेटिंग तपासा, इच्छित इन्स्टन्स, प्रकल्प आणि झोनविरुद्ध फक्त-वाचन describe वापरून:

gcloud compute instances describe VM_NAME --project PROJECT_ID --zone ZONE --format='value(canIpForward)'

false मूल्य फक्त तेव्हाच महत्त्वाचे आहे जेव्हा हे VM पुढील हॉप असावे. असे असल्यास, मार्गाचा उर्वरित भाग अजूनही स्वतंत्रपणे तपासावा लागेल, कारण गुणधर्म लांब साखळीतील एक ओळ आहे.

विद्यमान इन्स्टन्स अद्ययावत करा

Google ची इन्स्टन्स-गुणधर्म अद्ययावत प्रक्रिया सध्याचे संसाधन निर्यात करते, गुणधर्म बदलते आणि निकाल सबमिट करते. हा तयारीच्या वेळच्या --can-ip-forward ध्वजापेक्षा वेगळा कार्यप्रवाह आहे, आणि चालू असलेल्या VM वर कार्य करणारा हाच आहे.

प्रथम व्याख्या स्थानिक फाइलमध्ये निर्यात करा, आणि तुलनेसाठी अपरिवर्तित प्रत ठेवा:

gcloud compute instances export VM_NAME --project PROJECT_ID --zone ZONE --destination=instance.yaml

त्या निर्यात केलेल्या फाइलमध्ये गुणधर्म सेट करा आणि दुसरे काहीही बदलू नका:

canIpForward: true

संपूर्ण संसाधन, त्याच्या बोटांची खूणसह, ठेवा. फाइल एका ओळीच्या YAML दस्तऐवजाने बदलणे, किंवा असंबंधित मशीन-प्रकार, डिस्क किंवा इंटरफेस संपादने एकाच सबमिशनमध्ये एकत्र करणे, हा गुणधर्म बदल अडथळा होण्याचा मार्ग आहे.

कोणताही प्रभावी बदल मंजूर होण्यापूर्वी अद्ययावत यंत्रणेला फाइल पडताळण्यास आणि काय आवश्यक असेल ते कळवण्यास सांगा:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=NO_EFFECT

ते पडताळणी धाव फॉरवर्डिंग सक्षम करत नाही. प्रतिसादात अवैध गुणधर्म आणि आवश्यक असे सांगितलेली क्रिया वाचा. या एकल बदलासाठी दस्तऐवजीकृत क्रिया REFRESH आहे. निकाल रीस्टार्ट मागत असल्यास, फाइलमध्ये तुम्हाला बदलायच्या गुणधर्मापेक्षा अधिक आहे, म्हणून रीस्टार्ट देण्याऐवजी ती तपासा.

पुनरावलोकित फाइल refresh मर्यादेसह लागू करा:

gcloud compute instances update-from-file VM_NAME --project PROJECT_ID --zone ZONE --source=instance.yaml --most-disruptive-allowed-action=REFRESH

कार्य पूर्ण झाले आहे का ते तपासा आणि describe आदेश पुन्हा चालवा. बोटांची खूण आता जुळत नसल्यास, तुम्ही संपादन करत असताना दुसऱ्याने इन्स्टन्स बदलले आहे, म्हणून तुमची जुनी फाइल जबरदस्तीने पुढे घालण्याऐवजी नवीन प्रत निर्यात करा आणि बदल पुन्हा पुनरावलोकित करा.

अतिथीला अजूनही पॅकेट राउट करावे लागेल

क्लाउड परवानगी उपकरणाला राउटर करत नाही. VPC मार्ग गंतव्य उपसर्गासाठी हे VM पुढील हॉप म्हणून निवडतो, आणि अतिथी स्वतःचे फॉरवर्डिंग धोरण सक्षम ठेवून बोगदा आणि योग्य इंटरफेस दरम्यान राउट करतो याची खात्री करा.

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

शेवटी, गंतव्याला क्लायंट पूलकडे परतीचा मार्ग आवश्यक आहे, किंवा रचनेने स्रोत जाणीवपूर्वक भाषांतरित केले पाहिजेत. गंतव्याला भाषांतरित रहदारी दिसत असल्यास, भाषांतरित स्रोत तपासा; रचना पूल राखत असल्यास, परतीच्या मार्गात आणि प्रवेश नियमांमध्ये तो पूल तपासा. कोणती रचना हवी हे ठरवण्यापूर्वी NAT जोडणे गहाळ मार्ग लपवते आणि गंतव्याला दिसणारे धोरण बदलते.

Linux गेटवेवर, कर्नल फॉरवर्डिंग अतिथी कॉन्फिगरेशनचा भाग आहे. pfSense उपकरणाला स्वतःचे समतुल्य आहे, आणि त्यात Linux sysctl आदेश कॉपी करणे हे जुळणारे पाऊल नाही.

प्रवेश आवश्यक असलेल्या क्लायंटकडून पडताळणी करा

गेटवेवरूनच नाही, तर VPN क्लायंटकडून एका लक्ष्य सेवेकडे चाचणी करा. गेटवेवर सुरू केलेले कनेक्शन वेगळा स्रोत वापरते आणि तुम्ही नुकतेच सक्षम केलेले फॉरवर्डिंग नियम कधीही वापरत नाही.

उपकरण व्यवस्थापित करणाऱ्या कोणत्याही गोष्टीत गुणधर्म नोंदवा. हाताने दुरुस्त केलेले VM पुढील बदली मूळ सेटिंग शांतपणे परत आणेपर्यंत कार्य करते, आणि ते अपयश VPN सॉफ्टवेअरमधील रिग्रेशनसारखे दिसेल.

कामाचा क्रम: गुणधर्म वाचा, एक ओळ निर्यात करून संपादित करा, NO_EFFECT ने पडताळणी करा, REFRESH ने लागू करा, अतिथी फॉरवर्ड करत आहे याची खात्री करा, नंतर क्लायंटकडून चाचणी करा.