अवस्थित 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 सँग लागू गर्नुहोस्, अतिथिले फर्वार्ड गर्छ भनी पुष्टि गर्नुहोस्, त्यसपछि क्लाइन्टबाट परीक्षण गर्नुहोस्।