Junos डुअल-WAN IPsec VPN: स्रोत पथ को सही गेटवे से मिलाना

हर साइट पर दो WAN लिंक अतिरेक जैसे लगते हैं, जब तक आप यह सिद्ध न करना चाहें कि किसी दिए गए फ़्लो ने वास्तव में कौन-सा पता जोड़ा इस्तेमाल किया। SRX पर एक IKE गेटवे एक बाहरी इंटरफ़ेस और एक स्थानीय पता उठाता है; दूरस्थ उम्मीदवारों की सूची दूसरा स्थानीय स्रोत नहीं बनाती। इसीलिए यह वॉकथ्रू कॉन्फ़िगरेशन से नहीं, जोड़ों के मैट्रिक्स से शुरू होता है, क्योंकि Junos आसानी से ऐसा डिज़ाइन commit कर लेता है जो आपके इच्छित संयोजनों का केवल आधा हिस्सा कवर करता है। मुझे यह दो SRX345s पर मिला: बैकअप टनल साफ़ ऊपर आया और फिर भी फ़ेलबैक पर सत्र को गिरा दिया।

चरणों को क्रम से पूरा करें: जिन जोड़ों को समर्थन देना है उनकी सूची बनाएँ, हर स्थानीय स्रोत के लिए एक गेटवे बनाएँ, पुष्टि करें कि किस असोसिएशन ने ट्रैफ़िक उठाया, और उसके बाद ही तय करें कि हर तरह की विफलता क्या बदल सकती है।

CLI छूने से पहले जोड़ों का नक्शा बनाएँ

अगर साइट A, A1 या A2 से स्रोत ले सकती है और साइट B, B1 या B2 पर प्राप्त कर सकती है, तो आपके पास चार बाहरी पता जोड़े हैं। ज़्यादातर डिज़ाइनों को इनमें से दो लगातार चाहिए और बाकी दो को वैकल्पिक मानते हैं। मैट्रिक्स लिखें और हर पंक्ति को चिह्नित करें, क्योंकि हर वादा की गई पंक्ति बाद में आपको एक गेटवे, एक टनल इंटरफ़ेस और एक रूटिंग निर्णय का खर्च देती है।

हर आवश्यक जोड़े को एक साथ तीन चीज़ें चाहिए: ठीक उन्हीं पतों के बीच पहुँचने योग्य underlay, दोनों सिरों पर साथी की पहचान और स्रोत पते की आपसी स्वीकृति, और एक संरक्षित वापसी पथ। केवल एक दिशा में काम करने वाला जोड़ा फिर भी टनल दिखाता है, और विफलता बाद में एप्लिकेशन के एकतरफ़ा ट्रैफ़िक के रूप में सामने आती है।

हर स्थानीय स्रोत के लिए एक गेटवे, दूरस्थ साइट के लिए नहीं

दूरस्थ पतों की सूची एक गेटवे की है, और स्थानीय स्रोत भी। IKE गेटवे संदर्भ दूरस्थ पते, बाहरी इंटरफ़ेस, स्थानीय पता और मृत साथी का पता लगाना अलग-अलग सेटिंग्स के रूप में रखता है, और बात यही है: दो स्थानीय स्रोत मतलब दो st0 इकाइयों पर दो गेटवे। उनके बीच IKE नीति साझा करना ठीक है; एक ही गेटवे रखकर यह आशा करना कि वह अपने आप दूसरा स्रोत चुन लेगा, ठीक नहीं।

set security ike policy IKE-P1 mode main
set security ike gateway GW-A1 ike-policy IKE-P1
set security ike gateway GW-A1 address 198.51.100.20
set security ike gateway GW-A1 address 198.51.100.21
set security ike gateway GW-A1 external-interface ge-0/0/0
set security ike gateway GW-A1 local-address 203.0.113.10
set security ike gateway GW-A1 version v2-only
set security ike gateway GW-A2 ike-policy IKE-P1
set security ike gateway GW-A2 address 198.51.100.20
set security ike gateway GW-A2 external-interface ge-0/0/3
set security ike gateway GW-A2 local-address 192.0.2.10
set security ike gateway GW-A2 version v2-only

फिर टनल जोड़ें और दूरस्थ प्रीफ़िक्स को दो next hop दें, हर टनल के लिए एक:

set interfaces st0 unit 1 family inet
set interfaces st0 unit 2 family inet
set security ipsec policy IPSEC-P1 perfect-forward-secrecy keys group14
set security ipsec vpn VPN-A1 bind-interface st0.1
set security ipsec vpn VPN-A1 ike gateway GW-A1 ipsec-policy IPSEC-P1
set security ipsec vpn VPN-A2 bind-interface st0.2
set security ipsec vpn VPN-A2 ike gateway GW-A2 ipsec-policy IPSEC-P1
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.1 preference 10
set routing-options static route 10.20.0.0/16 qualified-next-hop st0.2 preference 20

क्या एक गेटवे address प्रकार के दो निर्देश रख सकता है, यह रिलीज़ पर और इस पर निर्भर करता है कि डिवाइस कौन-सी IKE प्रक्रिया चला रहा है। kmd आधारित पुराना Junos प्रति गेटवे एक ही दूरस्थ पता लेता है; नए बिल्ड कई उम्मीदवार संभालते हैं पर अपनी सीमाएँ जोड़ते हैं, और उच्च उपलब्धता क्लस्टर आम जगह हैं जहाँ यह समर्थन सिकुड़ जाता है। इसे पुराने चेसिस से कॉपी करने से पहले अपने सटीक बिल्ड के रिलीज़ नोट देखें।

पुष्टि करें कि किस असोसिएशन ने पैकेट उठाया

दो SA और दो टनल यह नहीं बताते कि सत्र किसने आगे भेजा। डिवाइस से सीधे पूछें और फ़ील्ड की तुलना उस जोड़े से करें जो आपका इरादा था:

show security ike sa detail
show security ipsec sa detail
show security flow session destination-prefix 10.20.1.0/24
show interfaces st0.1 | match packets

विस्तृत आउटपुट हर असोसिएशन के लिए स्थानीय और दूरस्थ गेटवे बताता है, जो अप्रत्याशित स्रोत से तय हुई टनल पहचानने का सबसे तेज़ तरीका है। फिर ट्रैफ़िक गुज़ारते समय st0.1 और st0.2 पर प्रति इकाई पैकेट काउंटर देखें; जो टनल कुछ नहीं उठाती वह अपना SA रखती है और सारांश में स्वस्थ दिखती है।

हर विफलता को उसका अपना डिटेक्टर दें

साथी की जीवितता, स्थानीय अपलिंक का नुकसान, संरक्षित रूट की वापसी और एप्लिकेशन का टूटना चार अलग घटनाएँ हैं। DPD केवल पहली का उत्तर देता है, इसलिए इसे ऐसे अंतराल और सीमा के साथ कॉन्फ़िगर करें जिसे आप उचित ठहरा सकें, बजाय डिफ़ॉल्ट छोड़कर यह मान लेने के कि वह बाकी सब कवर करता है:

set security ike gateway GW-A1 dead-peer-detection interval 10
set security ike gateway GW-A1 dead-peer-detection threshold 3
set security ipsec vpn VPN-A1 vpn-monitor source-interface st0.1
set security ipsec vpn VPN-A1 vpn-monitor destination-ip 10.20.0.1

टनल मॉनिटरिंग जो दूरस्थ सबनेट के भीतर किसी गंतव्य को जाँचती है, वह स्थिति कवर करती है जो DPD नहीं देख सकता: IKE जीवित है, गेटवे उत्तर देता है, और संरक्षित प्रीफ़िक्स फिर भी अगम्य है। तय करें कि दोनों में से किसे प्राथमिकता खींचनी चाहिए, क्योंकि अगर दोनों एक साथ सक्रिय हों तो साफ़ फ़ेलओवर की जगह बदलावों का तूफ़ान आता है।

दूरस्थ सिरे को न भूलें। दूरस्थ साइट पर लगा प्राथमिक रूट उसी टनल की ओर इशारा करता रहता है जिसे आप पहले ही छोड़ चुके हैं, और कोई स्थानीय टाइमर इसे ठीक नहीं करता। वही प्राथमिकता तर्क दोनों साथियों पर प्रकाशित करें, और दर्ज करें कि बहाल लिंक ट्रैफ़िक अपने आप वापस ले सकता है या हाथ से बदलना होगा।

एक लिंक को दूसरे को छुए बिना दोबारा पता दें

जब ISP आपको नया ब्लॉक दे, हर बार एक संबंध बदलें। उस जोड़े के लिए दोनों साथियों पर address या local-address अपडेट करें, commit करें, और डिवाइस पर सभी SA साफ़ करने के बजाय केवल प्रभावित असोसिएशन को इंडेक्स से साफ़ करें। वैश्विक सफ़ाई स्वस्थ टनल को भी ले जाती है और रखरखाव विंडो को आउटेज में बदल देती है।

कुछ भी साफ़ करने से पहले एक असफल फ़्लो और उसके सत्र विवरण को साक्ष्य के रूप में रखें, फिर ऊपर की जाँच नए पता जोड़े पर दोबारा चलाएँ। लिंक बहाल करना एक रूटिंग निर्णय है, इसलिए वापसी को अलग परखा गया चरण मानें, बजाय यह मानने के कि पुरानी प्राथमिकता अपने आप लौट आएगी।

बदलाव को छोटी चेकलिस्ट से बंद करें

डुअल-WAN टनल डिज़ाइन तब पूरा होता है जब आप हर सत्र के पीछे का जोड़ा नाम ले सकें, तब नहीं जब दोनों SA ऊपर हों। नीचे की सूची उस डिवाइस पर देखें जिसे आपने वास्तव में बदला:

• हर वादा किए गए जोड़े के पास एक गेटवे, एक st0 इकाई और एक रूट प्रविष्टि है।
• हर टनल को पैकेट उठाते देखा गया, केवल SA रखते नहीं।
• दोनों सिरे पहचान और इस पर सहमत हैं कि कौन-सा पक्ष प्राथमिकता बहाल करता है।
• हर जोड़े का वापसी पथ उसके जाने वाले पथ के बगल में लिखा है।

अगर कोई पंक्ति विफल हो, तो अगली जोड़ने से पहले उस जोड़े को ठीक करें; दो आधी चलने वाली टनलों को एक के ऊपर एक रखना काउंटरों को अर्थहीन और failover व्यवहार को अप्रत्याशनीय बना देता है।