IPsec over et privat WAN: SRX-policygrenser som må kontrolleres

Et privat WAN kan bære de ytre pakkene i en IPsec-tunnel, så peer-adressene trenger ikke være offentlige internettadresser. Det som endres, er veien disse ytre pakkene tar, og tillatelsene på grensesnittet som mottar dem. På en SRX er den ytre kontrollveien, tunnegrensesnittbindingen og policyen for videresendt trafikk tre separate objekter. Feilsøking på én mens de to andre er feil, er den vanlige grunnen til at en tunnel blir nede.

Noter den ytre IKE-veien først

Skriv ned fire verdier før du rører policyen: peer-adressen, det lokale grensesnittet som mottar IKE, rutekonteksten som når peer, og ruten som velger det grensesnittet. IKE-pakker er adressert til SRX-en selv, så de trenger host-inbound-tillatelse i mottakssonen, ikke en policy for videresendt trafikk. En privat WAN-adresse fjerner ikke dette kravet, fordi pakken fortsatt termineres på enheten.

Kontroller den installerte tilstanden med show security ike sa og konfigurasjonen med show configuration security ike. Den første viser om fase 1 finnes; den andre viser hva enheten mener den bør gjøre.

Bind tunnegrensesnittet til riktig policy

En rutebasert VPN binder et tunnegrensesnitt til et VPN-objekt, og beskyttede prefikser rutes inn i det grensesnittet. Noter hvilket grensesnitt, hvilken rute og hvilken policy som tillater applikasjonene mellom de relevante sonene. En sone kalt trust er en policybeholder, og navnet beviser ikke at de nødvendige kontroll- eller datapakkene er tillatt.

Les de faktiske bindingene i stedet for et gammelt diagram: show configuration security ipsec vpn for innstillingen bind-to-interface og show configuration security policies for reglene som refererer til tunnelsonen.

Hvis den beskyttede ruten peker et annet sted, kan tunnelen være oppe mens trafikken aldri kommer inn i den. Det er et ruteproblem i IPsec-kostyme.

Hold peer-ruten på underlaget

Ruten til den eksterne peeren må løses gjennom underlaget, ikke rekursivt gjennom tunnelen den etablerer. Hvis peer-ruten peker på tunnegrensesnittet, jager IKE-pakkene sin egen tunnel, og fase 1 fullføres aldri. Svarveien for beskyttet trafikk trenger sin egen korrekte rute og policy, og det er vanligvis den manglende halvdelen når én retning virker. Les rutetabelloppføringen for peer-adressen og bekreft at det utgående grensesnittet er WAN-grensesnittet.

Kontroller det med show route 198.51.100.10, sett inn den ekte peer-adressen, og bekreft at neste hopp ikke er et tunnegrensesnitt.

Verifiser kontroll og tjeneste i rekkefølge

Arbeid deg oppover: fase 1-tilstand, fase 2-tilstand, deretter en ekte applikasjonsflyt. show security ipsec sa viser sikkerhetstilknytningene, og show security flow session destination-prefix 10.60.0.0/16 viser om videresendte økter opprettes for det beskyttede nettverket.

Et sunt kontrollforhold og en fungerende datavei er to forskjellige resultater, og bestått fase 2 sier ingenting om hvorvidt policyen tillater applikasjonen. Test én tillatt flyt og én som policyen bør avvise, slik at forskjellen er synlig.

Noter peer-ruten, host-inbound-tillatelsen, tunnebindingen, den indre ruten og applikasjonspolicyen sammen. Disse fem oppføringene viser hvilket lag som eier en fremtidig feil uten å stole på en portetikett.