Junos Dual-WAN IPsec VPN: супастаўленне зыходнага шляху з патрэбным шлюзам
Разбор SRX у Junos для IPsec з двума WAN: супастаўце кожную лакальную крыніцу з яе шлюзамі-кандыдатамі, а затым дакажыце, якая асацыяцыя насамрэч несла трафік.
Дзве лініі WAN на пляцоўку выглядаюць як рэзерваванне, пакуль не паспрабуеш даказаць, якую пару адрасоў рэальна выкарыстаў канкрэтны паток. На SRX адзін шлюз IKE нясе адзін знешні інтэрфейс і адзін лакальны адрас; спіс выдаленых кандыдатаў не стварае другой лакальнай крыніцы. Таму разбор пачынаецца з матрыцы пар, а не з канфігурацыі: Junos спакойна зафіксуе праект, які пакрывае толькі палову задуманых камбінацый. Я сутыкнуўся з гэтым на двух 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 выконваецца на прыладзе. Больш стары Junos на базе kmd прымае адзін выдалены адрас на шлюз; новыя зборкі трымаюць некалькі кандыдатаў, але дадаюць свае абмежаванні, а кластары высокай дасягальнасці — частае месца, дзе гэтая падтрымка звужаецца. Праверце заўвагі да выпуску для вашай дакладнай зборкі, перш чым капіраваць гэта са старога шасі.
Пацвердзіце, якая асацыяцыя пранесла пакет
Дзве 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 жывы, шлюз адказвае, а абаронены прэфікс усё роўна недасягальны. Выберыце, які з двух мае цягнуць перавагу, бо калі абодва спрацуюць адначасова, атрымаецца бура змен замест чыстага пераключэння.
Не забудзьце пра далёкі канец. Пераважны маршрут, які застаўся на выдаленай пляцоўцы, далей паказвае ў тунель, які вы ўжо пакінулі, і ніякі лакальны таймер гэта не выправіць. Апублікуйце тую ж логіку перавагі на абодвух партнёрах і зафіксуйце, ці можа адноўленая лінія сама вярнуць трафік, ці яе трэба перамыкаць уручную.
Пераадрасуйце адну лінію, не кранаючы другую
Калі правайдар выдае новы блок, змяняйце адну сувязь за раз. Абнавіце address або local-address на абодвух партнёрах для гэтай пары, зрабіце commit і ачышчайце толькі закранутыя асацыяцыі па індэксе, а не ўсе SA на прыладзе. Глабальнае ачышчэнне знясе і здаровы тунель і ператворыць акно абслугоўвання ў прастой.
Захавайце адзін няўдалы паток і дэталі яго сесіі як доказ, перш чым нешта чысціць, а потым паўтарыце праверкі вышэй на новай пары адрасоў. Вяртанне лініі — гэта рашэнне пра маршрутызацыю, таму стаўцеся да вяртання як да асобнага праверанага кроку, а не мяркуйце, што старая перавага вернецца сама.
Закрыйце змену кароткім чэк-лістом
Праект тунелю з двума WAN гатовы, калі вы можаце назваць пару за кожнай сесіяй, а не калі абедзве SA паднятыя. Прайдзіце спіс ніжэй на той прыладзе, якую вы сапраўды змянялі:
- Кожная абяцаная пара мае шлюз, прыладу st0 і запіс маршруту.
- Кожны тунель бачылі нясучым пакеты, а не проста трымаючым SA.
- Абодва канцы згодныя наконт выяўлення і таго, які бок аднаўляе перавагу.
- Зваротны шлях кожнай пары запісаны побач з яе прамым шляхам.
Калі нейкі радок не сыходзіцца, выпраўце гэтую пару, перш чым дадаваць наступную; два паўпрацоўныя тунелі адзін паверх аднаго робяць лічыльнікі бессэнсоўнымі, а паводзіны failover непрадказальнымі.