Junos dual-WAN IPsec VPN: bronpad aan de juiste gateway koppelen
Een Junos SRX-walkthrough voor dual-WAN IPsec: koppel elke lokale bron aan zijn gateway-kandidaten en bewijs daarna welke associatie het verkeer werkelijk heeft gedragen.
Twee WAN-links per locatie lijken redundantie, tot je wilt bewijzen welk adrespaar een bepaalde flow echt heeft gebruikt. Op een SRX draagt één IKE-gateway één externe interface en één lokaal adres; een lijst met externe kandidaten maakt geen tweede lokale bron. Daarom begint deze walkthrough bij de parenmatrix en niet bij de configuratie, want Junos commit zonder morren een ontwerp dat maar de helft van je bedoelde combinaties dekt. Ik liep hier tegenaan bij twee SRX345s: de back-uptunnel kwam netjes omhoog en trok de sessie bij het terugschakelen alsnog omlaag.
Werk de stappen op volgorde af: benoem de paren die je moet ondersteunen, bouw één gateway per lokale bron, bevestig welke associatie het verkeer heeft gedragen en beslis pas daarna wat elk soort storing mag veranderen.
Breng de paren in kaart voordat je de CLI aanraakt
Als locatie A kan sourcen vanaf A1 of A2 en locatie B kan ontvangen op B1 of B2, heb je vier buitenste adresparen. De meeste ontwerpen hebben er twee continu nodig en behandelen de andere twee als optioneel. Schrijf de matrix op en markeer elke rij, want elke rij die je belooft kost je later een gateway, een tunnelinterface en een routingbeslissing.
| 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 |
Elk vereist paar heeft drie dingen tegelijk nodig: een bereikbaar underlay tussen precies die adressen, wederzijdse acceptatie van peer-identiteit en bronadres aan beide kanten, en een beschermd retourpad. Een paar dat maar één kant op werkt, laat nog steeds een tunnel zien, en de fout komt later naar boven als eenrichtingsverkeer van de applicatie.
Eén gateway per lokale bron, niet per externe locatie
De lijst met externe adressen hoort bij een gateway, en de lokale bron ook. De IKE-gateway-referentie houdt externe adressen, externe interface, lokaal adres en dead-peer-detectie als aparte instellingen, en dat is precies het punt: twee lokale bronnen betekent twee gateways over twee st0-units. De IKE-policy tussen beide delen is prima; één gateway houden en hopen dat die zelf een andere bron kiest, niet.
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-onlyKoppel daarna de tunnels en geef het verre prefix twee next hops, één per tunnel:
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 20Of één gateway twee instructies van het type address mag houden, hangt af van de release en van welk IKE-proces de box draait. Oudere, op kmd gebaseerde Junos neemt één extern adres per gateway; nieuwere builds verwerken meerdere kandidaten maar voegen eigen beperkingen toe, en high-availabilityclusters zijn een veelvoorkomende plek waar die ondersteuning smaller wordt. Controleer de release notes voor jouw exacte build voordat je dit van een ouder chassis kopieert.
Bevestig welke associatie het pakket heeft gedragen
Twee SAs en twee tunnels vertellen niet welke daarvan de sessie heeft doorgestuurd. Vraag het de box direct en vergelijk de velden met het paar dat je bedoelde:
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 packetsDe detailuitvoer noemt per associatie het lokale en externe gateway, wat de snelste manier is om een tunnel te vinden die zich vanaf een onverwachte bron heeft onderhandeld. Kijk daarna naar de pakkettellers per unit op st0.1 en st0.2 terwijl je verkeer doorstuurt; een tunnel die niets draagt, houdt zijn SA en ziet er in een overzicht gezond uit.
Geef elke soort storing zijn eigen detector
Peer-liveness, verlies van de lokale uplink, intrekken van de beschermde route en uitval van de applicatie zijn vier verschillende gebeurtenissen. DPD beantwoordt alleen de eerste, dus configureer het met een interval en drempel die je kunt verdedigen in plaats van de standaard te laten staan en aan te nemen dat die de rest dekt:
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.1Tunnelmonitoring die een bestemming binnen het verre subnet pingt, dekt het geval dat DPD niet ziet: IKE leeft, de gateway antwoordt en het beschermde prefix is toch onbereikbaar. Kies welke van de twee de voorkeur mag trekken, want als beide tegelijk afgaan ontstaat een storm van wijzigingen in plaats van een schone failover.
Vergeet de andere kant niet. Een voorkeursroute die op de externe locatie blijft staan, blijft wijzen naar een tunnel die je al hebt verlaten, en geen enkele lokale timer lost dat op. Publiceer dezelfde voorkeurslogica op beide peers en leg vast of een herstelde link het verkeer automatisch terug mag nemen of handmatig moet worden omgeschakeld.
Eén link opnieuw adresseren zonder de andere aan te raken
Als een ISP je een nieuw blok geeft, wijzig dan één relatie per keer. Werk address of local-address bij op beide peers voor dat paar, commit, en wis alleen de getroffen associaties op index in plaats van elke SA op de box te wissen. Een globale wisactie haalt ook de gezonde tunnel weg en maakt van een onderhoudsvenster een storing.
Bewaar één mislukte flow met zijn sessiedetail als bewijs voordat je iets opruimt, en voer daarna de controles hierboven opnieuw uit tegen het nieuwe adrespaar. Een link herstellen is een routingbeslissing, dus behandel de terugkeer als een eigen geteste stap in plaats van aan te nemen dat de oude voorkeur vanzelf terugkomt.
Sluit de wijziging af met een korte checklist
Een dual-WAN-tunnelontwerp is klaar wanneer je bij elke sessie het paar kunt noemen, niet wanneer beide SAs omhoog staan. Loop de lijst hieronder door op de box die je echt hebt gewijzigd:
- Elk beloofd paar heeft een gateway, een st0-unit en een route-entry.
- Elke tunnel is gezien terwijl hij pakketten droeg, niet alleen terwijl hij een SA vasthield.
- Beide kanten zijn het eens over detectie en over welke zijde de voorkeur herstelt.
- Het retourpad voor elk paar staat naast zijn heenpad opgeschreven.
Als een regel faalt, repareer dat paar voordat je het volgende toevoegt; twee half werkende tunnels op elkaar stapelen maakt de tellers betekenisloos en het failovergedrag onvoorspelbaar.