Cloud VPN बाट Cisco ASA: प्रस्ताव नमिलेपछि पुनर्निर्माण

अन्तिम छेउमा Cisco ASA भएको Cloud VPN टनेलमा NEGOTIATION_FAILURE प्रायः सधैं प्रस्ताव वा सेलेक्टरको नमिल्दोपन हो, र पहिलो उपयोगी तथ्य यो हो कि कुनै पनि सम्पादनले यसलाई सुधार्दैन। Cloud VPN ले टनेल वस्तु बनाउँदा IKE प्रस्ताव निश्चित गर्छ। एल्गोरिदम त्यहीँ बदल्ने कुनै फाँट छैन, त्यसैले मर्मत भनेको मेटाएर लेखिएको सुरुवात बिन्दुसहित फेरि बनाउनु हो। यसलाई पुनर्निर्माण मान्नुहोस्, अनि काम अनुमानले भरिएको दिउँसो नभई जाँचसूची बन्छ।

केही मेट्नुअघि असफलता पढ्नुहोस्

वार्ताको असफलता चरणको समस्या हो, र पियर लगले प्रायः चरण बताउँछ। चरण 1 असफल हुनु भनेको दुवै छेउ प्रस्तावमा सहमत हुन सकेनन् वा एकअर्कालाई प्रमाणित गर्न सकेनन्। चरण 2 असफल हुनु भनेको टनेल उठ्यो तर सुरक्षित सेलेक्टर मिलेनन्। यी फरक मर्मत हुन्, र कसैले कन्फिगरेसन छुनुअघि लगको लाइन निकाल्नु उचित हुन्छ।

यो असफलताले केही कुरा बाहिर पनि पार्छ। यो VPC मार्ग होइन, टनेल इन्टरफेसमा फायरवाल नियम होइन, र सञ्जालभित्रको नाम-समाधान त्रुटि होइन। तिनीहरूको पछि दौडिँदा नतिजा बदल्न नसक्ने आत्मविश्वासी परिवर्तन हुन्छन्, र अन्तिम सुधार कसलाई जश दिने भन्ने कठिन बनाउँछ।

दुवै कन्फिगरेसन अझै अस्तित्वमा हुँदै लेख्नुहोस्

टनेल मेट्न आधा मिनेट लाग्छ र तपाईंसँग भएको एउटै प्रमाण नष्ट हुन्छ। त्यसअघि स्थानीय र टाढाका सेलेक्टर, पियर ठेगाना, साझा गोप्य कसको हो, र ASA को crypto map वा IKEv2 प्रोफाइल लेख्नुहोस्। ASA दुई अलग प्रश्नको जवाफ दिन्छ: के कन्फिगर छ र अहिले के माथि छ:

show running-config crypto ikev2
show crypto ikev2 sa
show crypto ipsec sa | include local ident|remote ident|status

Google तर्फ कन्सोल सारांश नभई टनेल वस्तु पढ्नुहोस्, किनकि पियर ठेगाना र सेलेक्टर फाँट नै तपाईंले ठ्याक्कै पुनरुत्पादन गर्नुपर्ने मान हुन्:

gcloud compute vpn-tunnels describe tunnel-to-asa --region europe-west1 \
  --format="yaml(peerIp,localTrafficSelector,remoteTrafficSelector,ikeVersion,sharedSecret)"

ती मानहरू पहिलो मेट्नुअघि टिकटमा राख्नुहोस्। तलको पुनर्निर्माण एउटै वस्तु एक जानाजानी फरकसहित फेरि बनाउन सकिने भएकाले मात्र चल्छ।

एक पक्षले वार्ता गर्न अस्वीकार गर्ने एल्गोरिदम

Cloud VPN ले परम्परागत पियरजस्तै IKEv1 एल्गोरिदमको दायराबाट छनोट गर्दैन। यसले अपेक्षा गर्ने पियर सेटिङ स्थिर छन्: इन्क्रिप्सनका लागि aes-cbc-128, अखण्डता र PRF दुवैका लागि sha1-96, Diffie-Hellman समूह 2, चरण 1 का लागि 36,600 सेकेन्ड र चरण 2 का लागि 10,800 सेकेन्ड। ASA नीतिले ठ्याक्कै त्यही समूह दिनुपर्छ। ASA मा दोस्रो प्रस्ताव हुँदा हानि हुँदैन, मिल्ने प्रस्ताव पनि सूचीमा भएसम्म।

IKEv2 ले दुवै पक्षलाई बढी ठाउँ दिन्छ, तर नियमहरू उही आकार कायम राख्छन्: PFS खोल्नुहोस्, टनेलले समर्थन गर्ने DH समूह छान्नुहोस्, र नमिल्दोपन स्पष्ट हुने गरी प्रस्तावको सूची छोटो राख्नुहोस्। Cloud VPN मा ASA पियर भन्नाले स्थिर रुटिङ पनि हो, त्यसैले सुरक्षित प्रिफिक्सहरू BGP लाई छोड्नुभन्दा योजना बनाएर सूचीबद्ध गर्नुपर्छ।

अर्को विक्रेताको टेम्प्लेटबाट प्रतिलिपि गरिएको आयु यहाँको सामान्य गलत मोड हो। Google ले यी मानहरू अनिवार्य पियर सेटिङका रूपमा प्रकाशित गर्छ, त्यसैले तिनीहरू सेट गर्नुहोस्; छोटो मान ASA ले चाहेको हदसम्म माथि वार्ता गरिँदैन।

मेटाउनुहोस्, फेरि बनाउनुहोस् र पुरानो अवस्था सफा गर्नुहोस्

गेटवे होइन, टनेल मेटाउनुहोस्, र Cloud VPN ले प्रतिस्थापनलाई दिने नाम लेख्नुहोस्, किनकि नामहरू तोकिन्छन्, फेरि प्रयोग गरिँदैन। लेखिएका मान र त्यही पियर ठेगानासहित यसलाई फेरि बनाउनुहोस्, त्यसपछि मिल्ने प्रस्ताव ASA नीति सूचीमा थप्नुहोस्।

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

clear crypto ikev2 sa
clear crypto ipsec sa

चरण 2 हेर्नुअघि चरण 1 उठेको पुष्टि गर्नुहोस्। चरण 1 तल हुँदा प्रस्ताव वा पूर्व-साझा कुञ्जी गलत हुन्छ, र सेलेक्टरको कामले त्यो बदल्दैन।

सेलेक्टर ऐनाजस्तै मिल्छन्, त्यसपछि गणकले निर्णय गर्छन्

चरण 2 तब मात्र चल्छ जब दुवै छेउ सुरक्षित ठेगानामा सहमत हुन्छन्, र त्यो सहमति साझा होइन, ऐनाजस्तो हुन्छ। Google को स्थानीय सेलेक्टर ASA ले टाढा भन्ने सेलेक्टरसँग मिल्नुपर्छ, र Google को टाढाको सेलेक्टर ASA ले स्थानीय भन्नेसँग मिल्नुपर्छ। एकातिर 0.0.0.0/0 र अर्कोतिर एउटै सबनेट भएको टनेल चरण 1 पार गर्छ र त्यसपछि त्यही मुख्य त्रुटिले चरण 2 मा असफल हुन्छ। कुनै पक्षले अर्कोको सूची फराकिलो बनाउन सक्दैन।

नीति-आधारित सेलेक्टरका लागि हरेक प्रिफिक्स जोडी सूचीबद्ध गर्नुहोस् र सूची टिकटमा राख्नुहोस्। पछि परिसरमा थपिएको सबनेटले दुवै छेउमा सम्पादन चाहन्छ, किनकि ASA मा नयाँ मार्गले सेलेक्टर फराकिलो बनाउँदैन, र नतिजा यस्तो टनेल हुन्छ जो माथि छ तर पहिलो दिन अस्तित्वमा रहेका प्रिफिक्सका लागि मात्र यातायात पार गर्छ।

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