IPsec over eit privat WAN: SRX-policygrenser som må kontrollerast

Eit privat WAN kan bera dei ytre pakkane i ein IPsec-tunnel, så peer-adressene treng ikkje vera offentlege internettadresser. Det som endrar seg, er vegen desse ytre pakkane tek, og tillatingane på grensesnittet som tek imot dei. På ein SRX er den ytre kontrollvegen, tunnegrensesnittbindinga og policyen for vidaresend trafikk tre separate objekt. Feilsøking på éin medan dei to andre er feil, er den vanlege grunnen til at ein tunnel blir nede.

Noter den ytre IKE-vegen først

Skriv ned fire verdiar før du rører policyen: peer-adressa, det lokale grensesnittet som tek imot IKE, rutekonteksten som når peer, og ruta som vel det grensesnittet. IKE-pakkar er adresserte til SRX-en sjølv, så dei treng host-inbound-tillating i mottakssona, ikkje ein policy for vidaresend trafikk. Ei privat WAN-adresse fjernar ikkje dette kravet, fordi pakken vert framleis terminert på eininga.

Kontroller den installerte tilstanden med show security ike sa og konfigurasjonen med show configuration security ike. Den første viser om fase 1 finst; den andre viser kva eininga meiner ho bør gjera.

Bind tunnegrensesnittet til rett policy

Ein rutebasert VPN bind eit tunnegrensesnitt til eit VPN-objekt, og verna prefiks vert ruta inn i det grensesnittet. Noter kva grensesnitt, kva rute og kva policy som tillèt applikasjonane mellom dei relevante sonene. Ei sone kalla trust er ein policybehaldar, og namnet bevisar ikkje at dei naudsynte kontroll- eller datapakkane er tillatne.

Les dei faktiske bindingane i staden for eit gammalt diagram: show configuration security ipsec vpn for innstillinga bind-to-interface og show configuration security policies for reglane som viser til tunnelsonen.

Viss den verna ruta peikar ein annan stad, kan tunnelen vera oppe medan trafikken aldri kjem inn i han. Det er eit ruteproblem i IPsec-kostyme.

Hald peer-ruta på underlaget

Ruta til den eksterne peeren må løysast gjennom underlaget, ikkje rekursivt gjennom tunnelen han etablerer. Viss peer-ruta peikar på tunnegrensesnittet, jagar IKE-pakkane sin eigen tunnel, og fase 1 vert aldri fullført. Svarvegen for verna trafikk treng si eiga korrekte rute og policy, og det er vanlegvis den manglande halvdelen når éin retning verkar. Les rutetabelloppføringa for peer-adressa og stadfest at det utgåande grensesnittet er WAN-grensesnittet.

Kontroller det med show route 198.51.100.10, set inn den ekte peer-adressa, og stadfest at neste hopp ikkje er eit tunnegrensesnitt.

Verifiser kontroll og teneste i rekkjefølgje

Arbeid deg oppover: fase 1-tilstand, fase 2-tilstand, deretter ein ekte applikasjonsflyt. show security ipsec sa viser sikkerheitstilknytingane, og show security flow session destination-prefix 10.60.0.0/16 viser om vidaresende økter vert oppretta for det verna nettverket.

Eit sunt kontrollforhold og ein fungerande dataveg er to ulike resultat, og bestått fase 2 seier ingenting om korvidt policyen tillèt applikasjonen. Test éin tillaten flyt og éin som policyen bør avvise, slik at skilnaden er synleg.

Noter peer-ruta, host-inbound-tillatinga, tunnebindinga, den indre ruta og applikasjonspolicyen saman. Desse fem oppføringane viser kva lag som eig ein framtidig feil utan å stole på ein portetikett.