IPsec tra privata WAN: SRX-politikaj limoj kontrolendaj

Privata WAN povas porti la eksterajn paketojn de IPsec-tunelo, do la peer-adresoj ne devas esti publikaj interretaj adresoj. Tio, kio ŝanĝiĝas, estas la vojo, kiun tiuj eksteraj paketoj sekvas, kaj la permesoj sur la interfaco, kiu ilin ricevas. Sur SRX, la ekstera rega vojo, la ligo de la tunela interfaco kaj la politiko por plusendata trafiko estas tri apartaj objektoj. Solvi problemon en unu dum la aliaj du estas malĝustaj estas la kutima kialo, ke tunelo restas malsupre.

Unue notu la eksteran IKE-vojon

Notu kvar valorojn antaŭ ol tuŝi la politikon: la peer-adreson, la lokan interfacon, kiu ricevas IKE, la enkursigan kuntekston, kiu atingas la peer, kaj la vojon, kiu elektas tiun interfacon. IKE-paketoj estas adresitaj al la SRX mem, do ili bezonas host-inbound-permeson en la riceva zono, ne politikon por plusendata trafiko. Privata WAN-adreso ne forigas tiun postulon, ĉar la paketo ankoraŭ finiĝas sur la aparato.

Kontrolu la instalitan staton per show security ike sa kaj la agordon per show configuration security ike. La unua montras, ĉu fazo 1 ekzistas; la dua montras, kion la aparato opinias, ke ĝi devus fari.

Ligu la tunelan interfacon al la ĝusta politiko

Enkursiga VPN ligas tunelan interfacon al VPN-objekto, kaj protektitaj prefiksoj estas enkursigataj en tiun interfacon. Notu, kiu interfaco, kiu vojo kaj kiu politiko permesas la aplikaĵojn inter la koncernaj zonoj. Zono nomata trust estas politika ujo, kaj la nomo ne pruvas, ke la necesaj regaj aŭ datumaj paketoj estas permesitaj.

Legu la efektivajn ligojn anstataŭ malnova diagramo: show configuration security ipsec vpn por la agordo bind-to-interface kaj show configuration security policies por la reguloj, kiuj referencas la tunelan zonon.

Se la protektita vojo montras aliloken, la tunelo povas esti supre dum trafiko neniam eniras ĝin. Tio estas enkursiga problemo en IPsec-kostumo.

Tenu la peer-vojon sur la suba tavolo

La vojo al la ekstera peer devas solviĝi tra la suba tavolo, ne rekursie tra la tunelo, kiun ĝi starigas. Se la peer-vojo montras al la tunela interfaco, IKE-paketoj ĉasas sian propran tunelon kaj fazo 1 neniam kompletiĝas. La responda vojo por protektita trafiko bezonas sian propran ĝustan vojon kaj politikon, kaj ĝi kutime estas la mankanta duono, kiam unu direkto funkcias. Legu la enkursigan tabelan eron por la peer-adreso kaj konfirmu, ke la elira interfaco estas la WAN-interfaco.

Kontrolu ĝin per show route 198.51.100.10, anstataŭigante la realan peer-adreson, kaj konfirmu, ke la sekva saltado ne estas tunela interfaco.

Kontrolu regadon kaj servon laŭ ordo

Laboru supren: stato de fazo 1, stato de fazo 2, poste reala aplikaĵa fluo. show security ipsec sa listigas la sekurecajn asociojn, kaj show security flow session destination-prefix 10.60.0.0/16 montras, ĉu plusendataj sesioj estas kreataj por la protektita reto.

Sana rega rilato kaj funkcianta datenvojo estas du malsamaj rezultoj, kaj sukcesa fazo 2 diras nenion pri tio, ĉu la politiko permesas la aplikaĵon. Testu unu permesitan fluon kaj unu, kiun la politiko devus malakcepti, por ke la diferenco estu videbla.

Notu kune la peer-vojon, la host-inbound-permeson, la tunelan ligon, la internan vojon kaj la aplikan politikon. Tiuj kvin rikordoj montras, kiu tavolo posedas estontan fiaskon sen dependi de porda etikedo.