IPsec printr-o WAN privată: limite de politică SRX de verificat

O WAN privată poate transporta pachetele externe ale unui tunel IPsec, așa că adresele perechii nu trebuie să fie adrese publice de internet. Ceea ce se schimbă este calea pe care o urmează aceste pachete externe și permisiunile de pe interfața care le primește. Pe un SRX, calea de control externă, legarea interfeței de tunel și politica pentru traficul redirecționat sunt trei obiecte separate. Diagnosticarea uneia în timp ce celelalte două sunt greșite este motivul obișnuit pentru care un tunel rămâne jos.

Notați mai întâi calea IKE externă

Scrieți patru valori înainte de a atinge politica: adresa perechii, interfața locală care primește IKE, contextul de rutare care ajunge la pereche și ruta care selectează acea interfață. Pachetele IKE sunt adresate chiar SRX-ului, deci au nevoie de permisiunea host-inbound în zona de recepție, nu de o politică pentru traficul redirecționat. O adresă WAN privată nu elimină această cerință, pentru că pachetul se termină tot pe echipament.

Verificați starea instalată cu show security ike sa și configurația cu show configuration security ike. Prima arată dacă faza 1 există; a doua arată ce crede echipamentul că ar trebui să facă.

Legați interfața de tunel de politica corectă

Un VPN bazat pe rutare leagă o interfață de tunel de un obiect VPN, iar prefixele protejate sunt rutate în acea interfață. Notați ce interfață, ce rută și ce politică permit aplicațiile între zonele relevante. O zonă numită trust este un container de politici, iar numele nu dovedește că pachetele de control sau de date necesare sunt permise.

Citiți legăturile reale în locul unei diagrame vechi: show configuration security ipsec vpn pentru setarea de legare la interfață și show configuration security policies pentru regulile care fac referire la zona tunelului.

Dacă ruta protejată indică în altă parte, tunelul poate fi sus în timp ce traficul nu intră niciodată în el. Aceasta este o problemă de rutare în costum de IPsec.

Țineți ruta perechii pe underlay

Ruta către perechea externă trebuie rezolvată prin underlay, nu recursiv prin tunelul pe care îl stabilește. Dacă ruta perechii indică interfața de tunel, pachetele IKE își urmăresc propriul tunel și faza 1 nu se finalizează niciodată. Calea de răspuns pentru traficul protejat are nevoie de propria rută și politică corecte, iar aceasta este de obicei jumătatea lipsă atunci când o direcție funcționează. Citiți intrarea din tabelul de rutare pentru adresa perechii și confirmați că interfața de ieșire este interfața WAN.

Verificați-o cu show route 198.51.100.10, înlocuind adresa reală a perechii, și confirmați că următorul salt nu este o interfață de tunel.

Verificați controlul și serviciul în ordine

Lucrați în sus: starea fazei 1, starea fazei 2, apoi un flux real de aplicație. show security ipsec sa listează asocierile de securitate, iar show security flow session destination-prefix 10.60.0.0/16 arată dacă sunt create sesiuni redirecționate pentru rețeaua protejată.

O relație de control sănătoasă și o cale de date funcțională sunt două rezultate diferite, iar trecerea fazei 2 nu spune nimic despre dacă politica permite aplicația. Testați un flux permis și unul pe care politica ar trebui să îl respingă, astfel încât diferența să fie vizibilă.

Notați împreună ruta perechii, permisiunea host-inbound, legarea tunelului, ruta internă și politica aplicației. Aceste cinci înregistrări arată ce strat este responsabil pentru o viitoare defecțiune fără a se baza pe eticheta unui port.