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 में बदलाव के बाद और परिणाम पढ़ने से पहले सुरक्षा साहचर्य साफ़ करें। ASA मौजूदा SA ख़त्म होने तक पुरानी नीति देना जारी रख सकता है, इसलिए सही कॉन्फ़िगरेशन पुराने जीवनकाल भर टूटा दिखता है और निरीक्षक निष्कर्ष निकालता है कि पुनर्निर्माण विफल रहा, जबकि वह शुरू ही नहीं हुआ था:

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 पर स्थिर रहने वाले काउंटर आमतौर पर बताते हैं कि जवाब किसी दूसरे इंटरफ़ेस से निकलता है, या सिलेक्टर वापसी प्रीफ़िक्स को नहीं ढकता। एल्गोरिदम, जीवनकाल, सिलेक्टर और टनल का नया नाम दर्ज करें, क्योंकि अगला प्रस्ताव परिवर्तन इसी पुनर्निर्माण को दोहराता है और वे मान इसे छोटा काम बना देते हैं।