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 वर्तन अंदाज करण्यायोग्य राहत नाही।