तुम्ही ट्यून करू शकत नाही अशा 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 प्राधान्ये तुमची आहेत.