Xem mẫu

&KDSWHU3XEOLF.H\&U\SWRJUDSK\ &KHFNLQJIRU5HYRFDWLRQ8VLQJ2&63 6SHFLI\LQJ(LWKHU&5/RU2&63IRU5HYRFDWLRQ&KHFNLQJ To specify the revocation check method (CRL, OCSP, both, or none) for a certificate of a particular CA, use the following CLI syntax: ns-> set pki authority id_num cert-status revoc { CRL | OCSP | all | none } where id_num is the identification number for the certificate. The following example specifies OCSP revocation checking. ns-> set pki authority 3 cert-status revocation-check ocsp The ID number 3 identifies the certificate of the CA. `LVSOD\LQJ&HUWLILFDWH5HYRFDWLRQ6WDWXV$WWULEXWHV To display the revocation check attributes for a particular CA, use the following CLI syntax: ns-> get pki authority id_num cert-status where id_num is the identification number for the certificate issued by the CA. To display the revocation status attributes for the CA that issued certificate 7: ns-> get pki authority 7 cert-status 6SHFLI\LQJWKH85/RIDQ2&635HVSRQGHUIRUD&HUWLILFDWH To specify the URL string of an OCSP responder for a particular certificate, use the following CLI syntax: ns-> set pki authority id_num cert-status ocsp url url_str To specify the URL string of an OCSP responder (http:\\192.168.10.10) for the CA with certificate at index 5, use the following CLI syntax: ns-> set pki authority 5 cert-status ocsp url http:\\192.168.10.10 To remove the URL (http:\\192.168.2.1) of a CRL server for a certificate 5: ns-> unset pki authority 5 cert-status ocsp url http:\\192.168.2.1 1HW6FUHHQ&RQFHSWV ([DPSOHV²9ROXPH931V &KDSWHU3XEOLF.H\&U\SWRJUDSK\ &KHFNLQJIRU5HYRFDWLRQ8VLQJ2&63 5HPRYLQJ&HUWLILFDWH5HYRFDWLRQ&KHFN$WWULEXWHV To remove all attributes related to a certificate revocation check for a CA that issued a particular certificate, use the following syntax: ns-> unset pki authority id_num cert-status To remove all revocation attributes related to certificate 1: ns-> unset pki authority 1 cert-status 1HW6FUHHQ&RQFHSWV ([DPSOHV²9ROXPH931V &KDSWHU3XEOLF.H\&U\SWRJUDSK 1HW6FUHHQ&RQFHSWV ([DPSOHV²9ROXPH931V &KHFNLQJIRU5HYRFDWLRQ8VLQJ2&63 5RXWLQJ%DVHG931V The configuration of a NetScreen device for virtual private network (VPN) support is particularly flexible. In ScreenOS releases prior to 3.1.0, VPN tunnels are treated as objects (or building blocks) that together with source, destination, service, and action, comprise a policy that permits VPN traffic. (Actually, the VPN policy action is tunnel, but the action permit is implied, if unstated). In ScreenOS 3.1.0, the concept of a VPN tunnel shifted. In addition1 to the previous notion of a tunnel as an object used to build policies—see Chapter 4, “Policy-Based VPNs” on page 123—a tunnel can also be viewed as a network resource used to transport traffic. Thus, you can consider a tunnel as a means for delivering traffic between points A and B, and a policy as a method for either permitting or denying the delivery of that traffic. Simply put, ScreenOS allows you the freedom to decouple the regulation of traffic from the means of its delivery. This chapter presents an overview and offers examples of the following routing-based VPN concepts: • “Tunnel Interfaces” on page 48 – “Example: Tunnel Bound to Tunnel Interface” on page 49 – “Example: Deleting a Tunnel Interface” on page 57 • “LAN-to-LAN VPNs” on page 58 – “Example: Routing-Based LAN-to-LAN VPN, Manual Key” on page 59 – “Example: Routing-Based LAN-to-LAN VPN, AutoKey IKE” on page 70 – “Example: Routing-Based LAN-to-LAN VPN, Dynamic Peer” on page 76 • “Dialup-to-LAN VPN, Dynamic Peer” on page 92 – “Example: Routing-Based Dialup-to-LAN VPN, Dynamic Peer” on page 93 • “Hub-and-Spoke VPNs” on page 103 – “Example: Hub-and-Spoke VPNs” on page 104 • “Back-to-Back VPNs” on page 111 – “Example: Back-to-Back VPNs” on page 112 1. ScreenOS releases after 3.1.0 continues to support pre-ScreenOS 3.1.0 VPN configuration concepts and methods. 1HW6FUHHQ&RQFHSWV ([DPSOHV²9ROXPH931V &KDSWHU5RXWLQJ%DVHG931V 7XQQHO,QWHUIDFHV 7811(/,17(5)$&(6 When you configure the remote gateway for a VPN tunnel, you must also specify a security zone interface as the local gateway2. Beyond the VPN tunnel termination points (the local and remote gateways), you can also configure tunnel interfaces in either a security zone or in a tunnel zone through which the NetScreen device directs traffic to and from the VPN tunnel3. You can bind a VPN tunnel to a specific numbered (with IP address/netmask) or unnumbered (without IP address/netmask) tunnel interface in a security zone. If the tunnel interface is unnumbered, it borrows the IP address from the interface of the security zone in which you created it. Now you have a VPN tunnel that is bound both to a tunnel interface and to a local security zone interface. Conceptually, you can view VPN tunnels as pipes that you have laid. They extend from the local device to remote gateways, and the tunnel interfaces are the openings to these pipes. The pipes are always there, available for use whenever the routing engine directs traffic to one of their interfaces. Tunnel Interfaces Security Zone Interfaces Numbered Numbered or Unnumbered Numbered Tunnel Zone Security Zone Security Zone VPN Tunnel VPN Tunnel VPN Tunnel When a numbered tunnel interface is in a tunnel zone, you cannot bind a VPN tunnel to the tunnel interface. You can only bind a tunnel to the tunnel zone. This allows multiple tunnel interfaces to link to a single tunnel, or multiple tunnels to link to a single tunnel interface. In such cases, you must create a policy-based VPN configuration. When a tunnel interface is in a security zone, you must bind a VPN tunnel to the tunnel interface. Doing so allows you to create a routing-based VPN configuration. The tunnel interface can be numbered or unnumbered. If it is unnumbered, the tunnel interface borrows the IP address from the security zone interface. Note: Only a numbered tunnel interface (that is, an interface with an IP address and netmask) can support policy-based NAT. When a numbered tunnel interface is in a securityzone and is the only interface in that zone, you do not need to create a security zone interface. In this case, the security zone supports VPN traffic via the tunnel interface, but no other kind of traffic. 2. Your IKE peer uses the IP address of your local gateway interface (or outgoing-interface) when configuring the remote gateway on his NetScreen device. 3. If you do not specify a tunnel interface, the tunnel uses the default interface for the security zone. 1HW6FUHHQ&RQFHSWV ([DPSOHV²9ROXPH931V ... - tailieumienphi.vn
nguon tai.lieu . vn