Junos Dual-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 процес изпълнява устройството. По-старият 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 и в обобщен изглед изглежда здрав.

Дайте на всеки вид отказ собствен детектор

Живостта на партньора, загубата на локалния uplink, оттеглянето на защитения маршрут и отказът на приложението са четири различни събития. 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 на устройството. Глобалното изчистване отнема и здравия тунел и превръща сервизния прозорец в прекъсване.

Запазете един неуспешен поток и детайлите на сесията му като доказателство, преди да почистите каквото и да е, след което пуснете отново проверките по-горе върху новата двойка адреси. Възстановяването на връзка е решение за маршрутизация, затова третирайте връщането като отделна тествана стъпка, вместо да предполагате, че старата предпочитание се връща сама.

Затворете промяната с кратък контролен списък

Дизайнът на dual-WAN тунел е готов, когато можете да назовете двойката зад всяка сесия, а не когато двете SA са вдигнати. Минете списъка по-долу на устройството, което действително сте променили:

• Всяка обещана двойка има шлюз, единица st0 и запис в маршрута.
• Всеки тунел е виждан да носи пакети, не само да държи SA.
• Двата края са съгласни за откриването и за това коя страна възстановява предпочитанието.
• Обратният път за всяка двойка е записан до пътя ѝ напред.

Ако някой ред се провали, поправете тази двойка, преди да добавите следващата; подреждането на два полуработещи тунела прави броячите безсмислени, а поведението при failover непредвидимо.