Junos dual-WAN IPsec VPN: Kobl kildevejen til den rigtige gateway
En Junos SRX-gennemgang af dual-WAN IPsec: kobl hver lokal kilde til dens gateway-kandidater, og bevis derefter hvilken associering der faktisk bar trafikken.
To WAN-links per site ser ud som redundans, indtil man prøver at bevise, hvilket adressepar en given flow faktisk brugte. På en SRX bærer én IKE-gateway én ekstern grænseflade og én lokal adresse; en liste over eksterne kandidater skaber ikke en ekstra lokal kilde. Derfor starter denne gennemgang med parmatrixen i stedet for konfigurationen, fordi Junos uden videre committer et design, der kun dækker halvdelen af de kombinerede tilfælde, du havde tænkt dig. Jeg stødte på det med to SRX345s, hvor backup-tunnelen kom rent op og alligevel trak sessionen ned ved tilbageskift.
Gå trinnene igennem i rækkefølge: opregn de par, du skal understøtte, byg én gateway per lokal kilde, bekræft hvilken associering der bar trafikken, og beslut først derefter, hvad hver type fejl må ændre.
Kortlæg parene, før du rører CLI'en
Hvis site A kan source fra A1 eller A2, og site B kan modtage på B1 eller B2, har du fire ydre adressepar. De fleste designs har løbende brug for to af dem og behandler de to andre som valgfrie. Skriv matrixen ned, og markér hver række, for hver række du lover, koster dig senere en gateway, en tunnelgrænseflade og en routingbeslutning.
| 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 |
Hvert krævet par har brug for tre ting på én gang: et nåbart underlay mellem præcis disse adresser, gensidig accept af peer-identitet og kildeadresse i begge ender samt en beskyttet returvej. Et par, der kun virker i én retning, viser stadig en tunnel, og fejlen dukker senere op som envejs applikationstrafik.
Én gateway per lokal kilde, ikke per fjerndestination
Listen over fjernadresser hører til en gateway, og det gør den lokale kilde også. IKE-gateway-reference holder fjernadresser, ekstern grænseflade, lokal adresse og dead-peer-detektion som separate indstillinger, og det er netop pointen: to lokale kilder betyder to gateways over to st0-enheder. At dele IKE-policyen mellem dem er fint; at beholde én gateway og håbe på, at den selv vælger en anden kilde, er ikke.
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-onlyTilslut derefter tunnelerne, og giv det fjerne præfiks to 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 20Om én gateway må holde to erklæringer af typen address, afhænger af release og af, hvilken IKE-proces boksen kører. Ældre kmd-baserede Junos tager én enkelt fjernadresse per gateway; nyere builds håndterer flere kandidater, men tilføjer deres egne begrænsninger, og high-availability-klynger er et typisk sted, hvor den understøttelse bliver smallere. Tjek release notes for din præcise build, før du kopierer dette fra et ældre chassis.
Bekræft, hvilken associering der bar pakken
To SAs og to tunneler fortæller ikke, hvilken af dem der videresendte sessionen. Spørg boksen direkte, og sammenlign felterne med det par, du havde tænkt dig:
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 packetsDetailoutputtet angiver den lokale og den eksterne gateway for hver associering, hvilket er den hurtigste måde at finde en tunnel, der forhandlede fra en kilde, du ikke havde regnet med. Se derefter på pakketællerne per enhed på st0.1 og st0.2, mens du sender trafik igennem; en tunnel, der ikke bærer noget, beholder sin SA og ser sund ud i en oversigt.
Giv hver fejltype sin egen detektor
Peer-liveness, tab af den lokale uplink, tilbagetrækning af den beskyttede rute og applikationsnedbrud er fire forskellige hændelser. DPD besvarer kun den første, så konfigurér den med et interval og en tærskel, du kan forsvare, i stedet for at lade standarden stå og antage, at den dækker resten:
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.1Tunnelovervågning, der tester en destination inde i det fjerne subnet, dækker det tilfælde, DPD ikke kan se: IKE er i live, gatewayen svarer, og det beskyttede præfiks er alligevel uopnåeligt. Vælg, hvilken af de to der skal trække præference, for hvis begge udløser samtidig, giver det en ændringsstorm i stedet for et rent failover.
Glem ikke den anden ende. En foretrukken rute, der bliver siddende på den fjerne site, peger stadig ind i en tunnel, du allerede har forladt, og ingen lokal timer retter det. Udgiv den samme præferencelogik på begge peers, og notér, om et genoprettet link må tage trafikken tilbage automatisk eller skal skiftes manuelt.
Genadressér ét link uden at røre det andet
Når en ISP giver dig et nyt blok, så ændr én relation ad gangen. Opdatér address eller local-address på begge peers for det par, commit, og ryd kun de berørte associeringer efter indeks i stedet for at rydde alle SAs på boksen. En global rydning tager også den sunde tunnel med og gør et vedligeholdelsesvindue til et nedbrud.
Behold én fejlet flow med dens sessionsdetalje som bevis, før du rydder op, og kør derefter kontrollerne ovenfor igen mod det nye adressepar. At genoprette et link er en routingbeslutning, så behandl tilbageførslen som et selvstændigt testet trin i stedet for at antage, at den gamle præference vender tilbage af sig selv.
Afslut ændringen med en kort tjekliste
Et dual-WAN-tunneldesign er færdigt, når du kan navngive parret bag hver session, ikke når begge SAs er oppe. Gå listen nedenfor igennem på den boks, du faktisk ændrede:
- Hvert lovet par har en gateway, en st0-enhed og en ruteindgang.
- Hver tunnel er blevet set bære pakker, ikke blot holde en SA.
- Begge ender er enige om detektion og om, hvilken side der genopretter præferencen.
- Returvejen for hvert par er skrevet ned ved siden af dets fremvej.
Hvis en linje fejler, så ret det par, før du tilføjer det næste; to halvt fungerende tunneler oven på hinanden gør tællerne meningsløse og failover-adfærden umulig at forudsige.