Junos डुअल-WAN IPsec VPN: स्रोत मार्गलाई सही गेटवेसँग जोड्ने
डुअल-WAN IPsec का लागि Junos SRX मार्गदर्शन: प्रत्येक स्थानीय स्रोतलाई यसका उम्मेदवार गेटवेसँग जोड्नुहोस्, त्यसपछि कुन एसोसिएसनले वास्तवमा ट्राफिक बोकेको थियो प्रमाणित गर्नुहोस्।
प्रत्येक साइटमा दुई WAN लिङ्क अनावश्यकता जस्तो देखिन्छ, जबसम्म कुनै दिइएको प्रवाहले वास्तवमा कुन ठेगाना जोडी प्रयोग गर्यो भनी प्रमाणित गर्न खोज्दैन। SRX मा एउटा IKE गेटवेले एउटा बाह्य इन्टरफेस र एउटा स्थानीय ठेगाना बोक्छ; टाढाका उम्मेदवारहरूको सूचीले दोस्रो स्थानीय स्रोत बनाउँदैन। त्यसैले यो मार्गदर्शन कन्फिगरेसनबाट होइन, जोडीहरूको म्याट्रिक्सबाट सुरु हुन्छ, किनकि Junos तपाईंको इरादाका आधा मात्र संयोजन ढाक्ने डिजाइन पनि सजिलै commit गर्छ। मैले यो दुई SRX345s मा भेटें: ब्याकअप टनेल सफा रूपमा माथि आयो र फिर्ता हुँदा पनि सत्र तल झार्यो।
चरणहरू क्रमैसँग पूरा गर्नुहोस्: समर्थन गर्नुपर्ने जोडीहरूको सूची बनाउनुहोस्, प्रत्येक स्थानीय स्रोतका लागि एउटा गेटवे बनाउनुहोस्, कुन एसोसिएसनले ट्राफिक बोक्यो भनी पुष्टि गर्नुहोस्, र त्यसपछि मात्र प्रत्येक किसिमको विफलताले के बदल्न सक्छ भनी निर्णय गर्नुहोस्।
CLI छुनु अघि जोडीहरूको नक्सा बनाउनुहोस्
यदि साइट A ले A1 वा A2 बाट स्रोत लिन सक्छ र साइट B ले B1 वा B2 मा प्राप्त गर्न सक्छ भने तपाईंसँग चार बाह्य ठेगाना जोडी छन्। धेरैजसो डिजाइनलाई तीमध्ये दुई निरन्तर चाहिन्छ र बाँकी दुईलाई वैकल्पिक मानिन्छ। म्याट्रिक्स लेख्नुहोस् र प्रत्येक पङ्क्ति चिन्ह लगाउनुहोस्, किनकि प्रत्येक वाचा गरिएको पङ्क्तिले तपाईंलाई पछि एउटा गेटवे, एउटा टनेल इन्टरफेस र एउटा राउटिङ निर्णयको लागत लाग्छ।
| Local source | Remote candidate | Required? |
|---|---|---|
| A1, ISP1 address | B1 | steady state |
| A1, ISP1 address | B2 | decide explicitly |
| A2, ISP2 address | B1 | decide explicitly |
| A2, ISP2 address | B2 | backup path |
प्रत्येक आवश्यक जोडीलाई एकैचोटि तीन चीज चाहिन्छ: ठ्याक्कै ती ठेगानाबीच पुग्न सकिने 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 व्यवहार अनुमान गर्न नसकिने हुन्छ।