IPsec oer in privee WAN: SRX-beliedsgrinzen om te kontrolearjen

In privee WAN kin de bûtenste pakketten fan in IPsec-tunnel drage, sadat de peer-adressen gjin iepenbiere ynternetadressen hoegen te wêzen. Wat feroaret is it paad dat dy bûtenste pakketten nimme en de tastimmingen op 'e interface dy't se ûntfangt. Op in SRX binne it bûtenste kontrôlepaad, de tunnelinterfacebining en it belied foar trochstjoerd ferkear trije aparte objekten. Ien ûntfange wylst de oare twa ferkeard binne is de gewoane reden dat in tunnel del bliuwt.

Skriuw earst it bûtenste IKE-paad op

Skriuw fjouwer wearden op foardat jo it belied oanreitsje: it peer-adres, de lokale interface dy't IKE ûntfangt, de routingkontekst dy't it peer berikt en de route dy't dy interface kiest. IKE-pakketten binne adressearre oan 'e SRX sels, sadat se host-inbound-tastimming nedich hawwe yn 'e ûntfangende sône, net in belied foar trochstjoerd ferkear. In privee WAN-adres hellet dy eask net fuort, want it pakket einiget noch altyd op it apparaat.

Kontrolearje de ynstallearre tastân mei show security ike sa en de konfiguraasje mei show configuration security ike. De earste seit oft faze 1 bestiet; de twadde seit wat it apparaat tinkt dat it dwaan moat.

Bin de tunnelinterface oan it rjochte belied

In route-basearre VPN bint in tunnelinterface oan in VPN-objekt, en beskerme prefixen wurde yn dy interface rûte. Skriuw op hokker interface, hokker route en hokker belied de applikaasjes tusken de oanbelangjende sônes tastean. In sône mei de namme trust is in beliedskontener, en de namme bewiist net dat de nedige kontrôle- of datapakketten tastien binne.

Lês de werklike biningen ynstee fan in âld diagram: show configuration security ipsec vpn foar de ynstelling fan bining oan interface en show configuration security policies foar de regels dy't nei de tunnelsône ferwize.

As de beskerme route earne oars hinne wiist, kin de tunnel omheech wêze wylst ferkear der nea yn komt. Dat is in routingprobleem yn in IPsec-kostúm.

Hâld de peer-route op 'e underlay

De route nei it eksterne peer moat troch de underlay oplost wurde, net rekursyf troch de tunnel dy't it oanmakket. As de peer-route nei de tunnelinterface wiist, jage IKE-pakketten har eigen tunnel efternei en foltôget faze 1 nea. It antwurdpaad foar beskerme ferkear hat syn eigen korrekte route en belied nedich, en dat is meastentiids de ûntbrekkende helte as ien rjochting wurket. Lês de routetabel-yngong foar it peer-adres en befêstigje dat de útgeande interface de WAN-interface is.

Kontrolearje it mei show route 198.51.100.10, mei it echte peer-adres ferfongen, en befêstigje dat de folgjende hop gjin tunnelinterface is.

Ferifiearje kontrôle en tsjinst yn folchoarder

Wurkje omheech: tastân fan faze 1, tastân fan faze 2, dan in echte applikaasjefleat. show security ipsec sa listet de feilichheidsassosjaasjes op, en show security flow session destination-prefix 10.60.0.0/16 lit sjen oft trochstjoerde sesjes foar it beskerme netwurk makke wurde.

In sûne kontrôlerelaasje en in wurkjend datapaad binne twa ferskillende resultaten, en in slagge faze 2 seit neat oer oft it belied de applikaasje tastiet. Test ien tastien fleat en ien dy't it belied wegere moatte soe, sadat it ferskil sichtber is.

Skriuw de peer-route, de host-inbound-tastimming, de tunnelbining, de ynderlike route en it applikaasjebelied byinoar op. Dy fiif records litte sjen hokker laach in takomstige flater besit sûnder op in poartelabel te fertrouwen.