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 बाटोमै फ्याँकिँदैन भन्ने पुष्टि गर्नुहोस्। फ्याँकिएको प्याकेट समय सकिएर रोकिन्छ; यसले अस्वीकृति उत्पन्न गर्दैन।
यो चल्दा के लेख्ने
सुरुङ अन्तिम पटक माथि आउँदा लागू भएको पहिचान प्रकार, त्यसको मान, फर्मवेयर संस्करण र साथी-ठेगाना लेख्नुहोस्। फर्मवेयर अपडेटले पूर्वनिर्धारित फेरि बदल्न सक्छ, र अर्को असफलता ठ्याक्कै कुञ्जीको अमिलजस्तै देखिनेछ। पहिचान कुञ्जी र साथी-ठेगानाको छेउमा राखिएको खण्डमा अर्को व्यक्ति सस्ता जाँचबाट सुरु गर्छ।
त्यो अभिलेख अर्को अपग्रेडपछि पनि उपाय आवश्यक छ कि छैन भन्ने थाहा पाउने एक मात्र तरिका हो।