GCP HA VPN FortiGate को अस्वीकार करता है: स्थानीय ID का प्रकार मेल नहीं खाता
Google सिर्फ़ प्री-शेयर्ड कुंजी नहीं, बल्कि FortiGate जिस पहचान का दावा करता है उसकी भी तुलना करता है। FQDN स्थानीय ID उस जाँच में विफल हो जाती है, जबकि लॉग अब भी प्रमाणीकरण कहता है।
Google Cloud HA VPN से आने वाला AUTHENTICATION_FAILED आमतौर पर लोगों को प्री-शेयर्ड कुंजी पर वापस भेजता है, और कुंजी सामान्यतः सही होती है। सुरंग 1 चरण पर अटक जाती है क्योंकि Google कुछ और भी तुलना करता है: वही पहचान जो साथी IKE आदान-प्रदान के दौरान दावा करता है। FortiGate पर वह पहचान बिना किसी के पता बदले प्रकार बदल सकती है। कुंजी दो बार फिर से दर्ज होने के बाद लॉग को पहचान की बेमेल के रूप में पढ़ें।
एक विफलता, दो जाँच
IKE किसी साथी को दो अलग चरणों में सत्यापित करता है। प्री-शेयर्ड कुंजी सिद्ध करती है कि दोनों सिरों के पास एक ही रहस्य है, और दावा की गई पहचान उत्तरदाता को बताती है कि साथी स्वयं को कौन कहता है। Google उस पहचान की तुलना उस साथी से करता है जिसके साथ उसे कॉन्फ़िगर किया गया था। अकेला छोड़ दिए जाने पर FortiGate अपने आउटगोइंग इंटरफ़ेस से निकली पता-आधारित पहचान भेजता है, और तुलना किसी के ध्यान में आए बिना पार हो जाती है।
दोनों चरण लॉग में एक ही टोकरी में गिरते हैं, जो उस परिचित चक्र को समझाता है: पहचान का पेलोड कोई पढ़े, उससे पहले कुंजी को चार बार फिर से टाइप करना।
FortiGate पहचान के पेलोड में क्या रखता है
मुश्किल तब शुरू होती है जब कोई स्थानीय ID सेट करता है ताकि दोनों पक्ष सहमत हों। हाल के FortiOS बिल्ड उस पहचान को पूर्णतः योग्य डोमेन नाम के रूप में चिह्नित करते हैं, भले ही दर्ज किया गया मान बिंदुओं वाला पता हो। इसलिए Google पते की अपेक्षा करते हुए FQDN पहचान प्राप्त करता है, और सत्र अस्वीकार कर देता है। संदेश में कहीं नहीं लिखा होता कि कौन-सा आधा विफल हुआ, इसलिए रिपोर्ट प्रमाणीकरण विफलता के रूप में पढ़ी जाती है।
IKE डिबगिंग चालू करके इसे एक बार दोहराएँ और वह पहचान पेलोड पढ़ें जो फ़ायरवॉल वास्तव में भेजता है।
उसी दौर में तीन सस्ते तथ्यों की पुष्टि करें: दोनों सिरों का IKE संस्करण, अदृश्य अंतिम वर्णों सहित सटीक कुंजी, और वह साथी-पता जिसकी Google अपेक्षा करता है। ये अलग-अलग प्रश्नों के उत्तर देते हैं, और मेल खाती कुंजी पहचान के बारे में कुछ नहीं कहती।
विकल्प, और हर एक की लागत
हर निकास अलग परत ठीक करता है, और इनमें से कोई भी हर परिनियोजन के लिए उपलब्ध नहीं है।
| Option | When it works | What it costs |
|---|---|---|
| Set an address identity on the firewall | Your firmware lets you choose the type | Behaviour you must retest per release |
| Put a public address on the negotiating interface | The firewall can hold a routable address | Not possible behind NAT |
| Terminate on a peer that accepts your identity | Another endpoint validates what you produce | A topology change |
फ़ायरवॉल पर पहचान सुधारना सबसे साफ़ उत्तर है जहाँ फ़र्मवेयर प्रकार चुनने और मान बनाए रखने देता है। यह फ़ील्ड कुछ बिल्ड में है और दूसरों में प्रकार ग़लत भरता है, इसलिए रिलीज़ नोट्स पर भरोसा करने के बजाय अपना संस्करण परखें।
बातचीत करने वाले इंटरफ़ेस पर रूट करने योग्य सार्वजनिक पता एक प्रलेखित उपाय है, क्योंकि तब डिफ़ॉल्ट पहचान वही होती है जिसकी Google अपेक्षा करता है और कोई ओवरराइड आवश्यक नहीं होता। अधिकांश परिनियोजन यहीं पहुँचते हैं, बशर्ते फ़ायरवॉल ऐसा पता रख ही सके।
आप जो बनाते हैं उसका सत्यापन करने वाले साथी पर समाप्त करना टोपोलॉजी परिवर्तन है। इसे अधिक मधुर वर्णन वाले उपाय के बजाय डिज़ाइन निर्णय मानें।
जब NAT एक विकल्प हटा देता है
NAT के पीछे सार्वजनिक-पता निकास गायब हो जाता है, और जो बचता है वह उस फ़र्मवेयर व्यवहार पर निर्भर करता है जो आपके नियंत्रण में नहीं है। यही वह बिंदु है जहाँ अपग्रेड, साथी को स्थानांतरित करने या दूसरा क्लाउड एंडपॉइंट स्वीकार करने के बीच जानबूझकर चुनना चाहिए। ये तीन अलग बजट हैं, और संयोग से एक चुन लेना ही अस्थायी उपाय को आर्किटेक्चर बना देता है। चुनाव और उसका कारण सुरंग के पास लिखें।
इनमें से कुछ भी व्याख्यायित करने से पहले Google की ओर सुरंग की स्थिति और यह पुष्टि करें कि IKE रास्ते में सिर्फ़ गिराया नहीं जा रहा है। गिराया गया पैकेट समय-समाप्त हो जाता है; वह अस्वीकृति उत्पन्न नहीं करता।
जब तक यह चलता है क्या दर्ज करें
पहचान का प्रकार, उसका मान, फ़र्मवेयर संस्करण और साथी-पता दर्ज करें जो सुरंग के अंतिम बार ऊपर आने के समय लागू थे। फ़र्मवेयर अपडेट डिफ़ॉल्ट को फिर बदल सकता है, और अगली विफलता बिल्कुल कुंजी की बेमेल जैसी दिखेगी। पहचान कुंजी और साथी-पते के पास सुरक्षित होने पर अगला व्यक्ति सस्ती जाँचों से शुरू करता है।
यह रिकॉर्ड ही यह जानने का एकमात्र तरीका है कि अगले अपग्रेड के बाद भी उपाय की आवश्यकता है या नहीं।