Cloud VPN ते Cisco ASA: प्रस्तावातील फरकानंतर पुनर्बांधणी

Cloud VPN प्रस्ताव टनेल ऑब्जेक्टमध्ये बसवते, त्यामुळे ASA शी फरक म्हणजे ते पुन्हा बांधणे. सिलेक्टर नोंदवा, दोन्ही टप्पे जुळवा, जुने SA पुसा.

दुसऱ्या टोकाला 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 वर सपाट राहणारे मोजणी सहसा असे सांगतात की उत्तर दुसऱ्या इंटरफेसने बाहेर पडते, किंवा सिलेक्टर परताव्याचा प्रीफिक्स व्यापत नाही. अल्गोरिदम, आयुष्य, सिलेक्टर आणि नवीन टनेलचे नाव नोंदवा, कारण पुढील प्रस्ताव बदल ही पुनर्बांधणी पुन्हा करतो आणि ती मूल्ये त्याला छोटे काम करतात.

संबंधित लेख