मौजूदा 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 से लागू करें, पुष्टि करें कि अतिथि फ़ॉरवर्ड करता है, फिर क्लाइंट से परीक्षण करें।