तपाईंले ट्युन गर्न नसक्ने Cloud VPN सीमाहरू: IKE आयु र पियर NAT

रिमोट यन्त्रलाई 24 घण्टाको फेज 1 आयु दिनुहोस् र Google पक्षमा सबै कुरा ठीकसँग कन्फिगर भए पनि Cloud VPN सुरुङ तलै रहन्छ। पियरले प्रतिक्रियाकर्ताले स्वीकार नगर्ने मान प्रस्ताव गरिरहेको छ, त्यसैले वार्ता या त पूर्ण रूपमा असफल हुन्छ या अनन्त रूपमा फेरि सुरु हुन्छ। Cloud VPN ले फेज 1 लाई 36,000 सेकेन्डसम्म, अर्थात् दस घण्टासम्म सीमित गर्छ र यो सीमा तपाईंले बढाउन सक्ने सेटिङ होइन। परिवर्तन रिमोट यन्त्रमै गर्नुपर्छ।

पियर सोध्छ, प्रतिक्रियाकर्ता निर्णय गर्छ

IKE दुई प्रस्ताव-समूहबीचको मिलान अभ्यास हो। प्रतिक्रियाकर्ताले स्वीकार गर्ने सीमाभित्र समूहहरू एकआपसमा काटिने ठाउँमा मात्र सुरुङ बन्छ, त्यसैले सीमाबाहिरको आयुले कुनै आंशिक सुरुङ पनि बनाउँदैन। पियरको कन्फिगरेसनलाई प्रस्ताव नमानी इच्छासूची मान्नु सामान्य गल्ती हो। खाली प्रतिच्छेदनले सुरुङ तलै राख्छ, राउटिङ र सिलेक्टर जतिसुकै सही भए पनि।

केस खोल्नुअघि सुरुङको आफ्नै स्थिति पढ्नुहोस्, किनकि विस्तृत स्थितिले सामान्यतया असफल भएको चरण बताउँछ:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

फर्केर आएको कुरालाई तपाईंको गेटवे प्रकार र IKE संस्करणका लागि समर्थित समूहसँग तुलना गर्नुहोस्, र त्यहाँ हुँदै दुवै ट्राफिक सिलेक्टर रेकर्ड गर्नुहोस्। सिलेक्टरको मिलान नहुनुले एल्गोरिदमको मिलान नहुनुजस्तै सुरुङ-तलको लक्षण दिन्छ, र एल्गोरिदमभन्दा फरक यो तपाईंले नै सुधार्नुपर्छ।

36,000 सेकेन्ड नै अधिकतम सीमा हो

फेज 1 36,000 सेकेन्डमा रोकिन्छ। 86,400 मा सेट गरिएको यन्त्रले प्रतिक्रियाकर्ता कहिल्यै नमान्ने कुरा मागिरहेको छ, र फेरि प्रयास गर्दा उसको मत बदलिँदैन। रिमोट प्रस्तावलाई सीमाभित्र फर्काउनुहोस् र त्यही कन्फिगरेसन स्थापित हुन्छ; यही असमानता नै पूरा पाठ हो, किनकि तपाईं आफ्नो मान घटाउन सक्नुहुन्छ तर Google को बढाउन सक्नुहुन्न।

छानिएको मान डिजाइन नोटमा लेख्नुहोस्। नत्र अर्को इन्जिनियरले 24 घण्टाको प्रयोग दोहोर्याएर त्यही भित्तामा पुग्छ।

समर्थित समूह प्रत्येक गेटवे प्रकार र IKE संस्करण अनुसार यहाँ प्रकाशित हुन्छ: Cloud VPN अवलोकनमा, त्यसैले सामान्य IKE गाइडको सट्टा तपाईंको टोपोलोजीको खण्ड पढ्नुहोस्।

तालिका अनुसार खस्ने सुरुङ

फेज 2 फरक व्यवहार गर्छ: दुवै छेउ सहमत नभए की-नवीकरण छोटो अन्तराल पछ्याउँछ। असमानतालाई घातक मान्ने पियरले सुरुङ तल खसाल्छ, त्यसैले एउटा असमानता दुई असम्बन्धित खराबीजस्तो देखिन सक्छ। की-नवीकरणको लय हेर्नुहोस्, पहिलो जडान मात्र होइन। नियमित तालमा माथि आएर खस्ने सुरुङ राउटिङ त्रुटिभन्दा बढी आयुको असमानता हुन्छ।

केही परिवर्तन गर्नुअघि ती खस्ने समय-छापहरूलाई पियरका आफ्नै लगसँग जोड्नुहोस्, किनकि सिलेक्टर वा मार्ग परिवर्तनले त्यही लयको नक्कल गर्न सक्छ। यदि ताल फेज 2 टाइमरसँग मिल्छ भने कुनै प्रस्तावलाई छोए बिनै कारण भेटियो।

समूहहरू गेटवे प्रकारबाट आउँछन्

सिफर र अखण्डता समूहहरू strongSwan जस्तै सम्पादन गर्ने प्रति-सुरुङ प्रोफाइल होइनन्। तपाईं तिनीहरूलाई गेटवे प्रकार र IKE संस्करण अनुसार छान्नुहुन्छ, र नभएको प्रोफाइल खोज्नु दिउँसो बर्बाद गर्नु हो।

समर्थित समूहभित्र केही पनि नदिने पुरानो यन्त्रले दुई इमानदार बाटो छाड्छ: यन्त्र बदल्नुहोस्, वा तपाईंले नियन्त्रण गर्ने सफ्टवेयर गेटवेमा अन्त्य गरी त्यहाँबाट VPC मा राउट गर्नुहोस्। बाँकी सबै अर्को समीक्षामा असफल हुने जुक्ति हो।

प्रति यन्त्र एक बाह्य ठेगाना

पियरको बाह्य ठेगाना उसको आन्तरिक ठेगानासँग एक-एक मिल्नुपर्छ। अधिभारित PAT पूल काम गर्न सक्दैन, किनकि एउटै सार्वजनिक ठेगानापछाडिका धेरै होस्टहरूले प्रतिक्रियाकर्तालाई तिनीहरू छुट्याउने कुनै उपाय दिँदैनन्। जहाँ धेरै होस्टले ठेगाना साझा गर्नुपर्छ, त्यहाँ सुरुङ तिनीहरूलाई चिन्न सक्ने ठाउँमा अन्त्य हुनुपर्छ।

त्यो बाह्य ठेगाना पनि स्थिर राख्नुहोस्। यन्त्रलाई अर्को NAT पछाडि सार्नुहोस् र प्रत्येक प्रस्ताव अझै मिले पनि सम्बन्ध टुट्छ। कुन मानहरू Google का र कुन तपाईंका हुन् भनी लेख्न लायक छ: आयु, समूह र एक-एक NAT उनीहरूको पक्षमा स्थिर छन्, जबकि प्रस्ताव, सिलेक्टर, राउटिङ र BGP प्राथमिकता तपाईंका हुन्।