Google Cloud HA VPN कडून येणारे AUTHENTICATION_FAILED सहसा लोकांना पूर्व-साझा केलेल्या किल्लीकडे परत पाठवते, आणि किल्ली सहसा बरोबर असते. सुरंग 1 टप्प्यावर थांबते कारण Google आणखी एक गोष्ट तुलना करते: IKE देवाणघेवाणीत साथीदार ज्या ओळखीचा दावा करतो ती. FortiGate वर कोणीही पत्ता न बदलता ती ओळख प्रकार बदलू शकते. किल्ली दोन वेळा पुन्हा टाकल्यावर लॉग ओळखीची विसंगती म्हणून वाचा.

एक अयशस्वीता, दोन तपासण्या

IKE साथीदाराची दोन स्वतंत्र टप्प्यांत पडताळणी करते. पूर्व-साझा केलेली किल्ली दोन्ही टोकांकडे एकाच गुपिताचे पुरावे देते, आणि दावा केलेली ओळख प्रतिसादकर्त्याला सांगते की साथीदार स्वतःला कोण म्हणवतो. Google ती ओळख ज्या साथीदारासोबत ती संरचित केली होती त्याच्याशी तुलना करते. एकटे सोडल्यास FortiGate बाहेर जाणाऱ्या इंटरफेसवरून घेतलेली पत्ता-आधारित ओळख पाठवते, आणि तुलना कोणाच्याही लक्षात न येता पार होते.

दोन्ही टप्पे लॉगमध्ये एकाच डब्यात पडतात, ज्यामुळे ओळखीचा पेलोड कोणी वाचण्यापूर्वी किल्ली चार वेळा पुन्हा टाइप करण्याचे परिचित चक्र स्पष्ट होते.

FortiGate ओळखीच्या पेलोडमध्ये काय ठेवते

अडचण तेव्हा सुरू होते जेव्हा कोणी स्थानिक ID सेट करतो, दोन्ही बाजू जुळाव्यात म्हणून. अलीकडील FortiOS बिल्ड ती ओळख पूर्णपणे पात्र डोमेन नाव म्हणून चिन्हांकित करतात, टाकलेले मूल्य बिंदूंचा पत्ता असला तरीही. त्यामुळे Google पत्त्याची अपेक्षा करत असताना FQDN ओळख मिळवते, आणि सत्र नाकारते. संदेशात कोणता अर्धा भाग अयशस्वी झाला हे सांगितलेले नाही, म्हणून अहवाल प्रमाणीकरण अयशस्वीता म्हणून वाचला जातो.

IKE डीबगिंग सुरू करून ते एकदा पुन्हा तयार करा आणि फायरवॉल प्रत्यक्षात पाठवत असलेला ओळखीचा पेलोड वाचा.

त्याच फेरीत तीन स्वस्त तथ्ये पडताळा: दोन्ही टोकांची IKE आवृत्ती, न दिसणाऱ्या शेवटच्या अक्षरांसह तंतोतंत किल्ली, आणि Google अपेक्षित असलेला साथीदार पत्ता. ही वेगवेगळ्या प्रश्नांची उत्तरे देतात, आणि जुळणारी किल्ली ओळखीबद्दल काहीही सांगत नाही.

पर्याय आणि प्रत्येकाची किंमत

प्रत्येक मार्ग वेगळा स्तर दुरुस्त करतो, आणि एकही प्रत्येक तैनातीसाठी उपलब्ध नाही.

OptionWhen it worksWhat it costs
Set an address identity on the firewallYour firmware lets you choose the typeBehaviour you must retest per release
Put a public address on the negotiating interfaceThe firewall can hold a routable addressNot possible behind NAT
Terminate on a peer that accepts your identityAnother endpoint validates what you produceA topology change

फायरवॉलवर ओळख दुरुस्त करणे हे सर्वात स्वच्छ उत्तर आहे, जिथे फर्मवेअर प्रकार निवडू आणि मूल्य टिकवू देते. क्षेत्र काही बिल्डमध्ये आहे आणि इतरांमध्ये प्रकार चुकीचा भरते, म्हणून प्रकाशन टिपा विश्वासाने न घेता तुमची आवृत्ती तपासा.

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

तुम्ही तयार करता त्याची पडताळणी करणाऱ्या साथीदारावर संपुष्टात आणणे हा टोपोलॉजी बदल आहे. त्याकडे अधिक मृदू वर्णनाचा उपाय म्हणून नव्हे, तर रचना निर्णय म्हणून पाहा.

NAT एक पर्याय काढून टाकते तेव्हा

NAT च्या मागे सार्वजनिक-पत्त्याचा मार्ग नाहीसा होतो, आणि उरलेले तुम्ही नियंत्रित न करणाऱ्या फर्मवेअर वर्तनावर अवलंबून असते. अपग्रेड, साथीदार हलवणे किंवा दुसरे क्लाउड एंडपॉइंट स्वीकारणे यांत जाणीवपूर्वक निवड करण्याचा हा मुद्दा आहे. हे तीन वेगळे अर्थसंकल्प आहेत, आणि एक योगायोगाने निवडणे हेच तात्पुरत्या उपायाला आर्किटेक्चर बनवते. निवड आणि तिचे कारण सुरंगाच्या शेजारी लिहा.

यापैकी काहीही अर्थ लावण्यापूर्वी Google बाजूची सुरंग स्थिती आणि IKE वाटेतच टाकून दिले जात नाही याची खात्री करा. टाकून दिलेला पॅकेट कालबाह्य होऊन थांबतो; तो नकार निर्माण करत नाही.

ते चालू असताना काय नोंदवायचे

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

ती नोंद पुढील अपग्रेडनंतरही उपाय आवश्यक आहे का हे जाणण्याचा एकमेव मार्ग आहे.

संबंधित लेख