IPsec over et privat WAN: SRX-politikgrænser, der skal kontrolleres

Et privat WAN kan bære de ydre pakker i en IPsec-tunnel, så peer-adresserne behøver ikke være offentlige internetadresser. Det, der ændrer sig, er den vej, disse ydre pakker tager, og tilladelserne på det interface, der modtager dem. På en SRX er den ydre kontrolvej, tunneinterfacebindingen og politikken for videresendt trafik tre separate objekter. Fejlfinding på ét, mens de to andre er forkerte, er den sædvanlige grund til, at en tunnel bliver nede.

Noter den ydre IKE-vej først

Skriv fire værdier ned, før du rører politikken: peer-adressen, det lokale interface der modtager IKE, den routingkontekst der når peer, og den rute der vælger det interface. IKE-pakker er adresseret til SRX'en selv, så de kræver host-inbound-tilladelse i den modtagende zone, ikke en politik for videresendt trafik. En privat WAN-adresse fjerner ikke dette krav, fordi pakken stadig termineres på enheden.

Kontrollér den installerede tilstand med show security ike sa og konfigurationen med show configuration security ike. Den første viser, om fase 1 findes; den anden viser, hvad enheden mener, den bør gøre.

Bind tunneinterfacet til den rette politik

En rutebaseret VPN binder et tunneinterface til et VPN-objekt, og beskyttede præfikser routes ind i det interface. Noter hvilket interface, hvilken rute og hvilken politik der tillader applikationerne mellem de relevante zoner. En zone med navnet trust er en politikbeholder, og navnet beviser ikke, at de nødvendige kontrol- eller datapakker er tilladte.

Læs de faktiske bindinger i stedet for et gammelt diagram: show configuration security ipsec vpn for indstillingen bind-to-interface og show configuration security policies for de regler, der refererer til tunnelzonen.

Hvis den beskyttede rute peger et andet sted hen, kan tunnelen være oppe, mens trafikken aldrig kommer ind i den. Det er et routingproblem i IPsec-kostume.

Hold peer-ruten på underlayet

Ruten til den eksterne peer skal opløses gennem underlayet, ikke rekursivt gennem den tunnel, den etablerer. Hvis peer-ruten peger på tunneinterfacet, jager IKE-pakkerne deres egen tunnel, og fase 1 bliver aldrig færdig. Svarvejen for beskyttet trafik har brug for sin egen korrekte rute og politik, og det er normalt den manglende halvdel, når én retning virker. Læs rutetabelposten for peer-adressen, og bekræft at det udgående interface er WAN-interfacet.

Kontrollér det med show route 198.51.100.10, indsæt den rigtige peer-adresse, og bekræft at næste hop ikke er et tunneinterface.

Verificér kontrol og tjeneste i rækkefølge

Arbejd opad: fase 1-tilstand, fase 2-tilstand og derefter et rigtigt applikationsflow. show security ipsec sa viser sikkerhedsassociationerne, og show security flow session destination-prefix 10.60.0.0/16 viser, om der oprettes videresendte sessioner for det beskyttede netværk.

Et sundt kontrolforhold og en fungerende datavej er to forskellige resultater, og en bestået fase 2 siger intet om, hvorvidt politikken tillader applikationen. Test ét tilladt flow og ét, som politikken bør afvise, så forskellen er synlig.

Noter peer-ruten, host-inbound-tilladelsen, tunnebindingen, den indre rute og applikationspolitikken sammen. Disse fem poster viser, hvilket lag der ejer en fremtidig fejl, uden at man stoler på en portetiket.