JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Cluster Geographic Edition System Administration Guide     Oracle Solaris Cluster 4.0
search filter icon
search icon

Document Information

Preface

1.  Introduction to Administering the Geographic Edition Software

2.  Before You Begin

3.  Administering the Geographic Edition Infrastructure

4.  Administering Access and Security

Geographic Edition Software and RBAC

Setting Up and Using RBAC

RBAC Rights Profiles

Modifying a User's RBAC Properties

Configuring Secure Cluster Communication Using Security Certificates

Configuring Firewalls

Configuring Secure Cluster Communication Using IPsec

How to Configure IPsec for Secure Cluster Communication

5.  Administering Cluster Partnerships

6.  Administering Heartbeats

7.  Administering Protection Groups

8.  Monitoring and Validating the Geographic Edition Software

9.  Customizing Switchover and Takeover Actions

10.  Script-Based Plug-Ins

A.  Standard Geographic Edition Properties

B.  Legal Names and Values of Geographic Edition Entities

C.  Disaster Recovery Administration Example

D.  Takeover Postconditions

E.  Troubleshooting Geographic Edition Software

F.  Error Return Codes for Script-Based Plug-Ins

Index

Configuring Secure Cluster Communication Using IPsec

You can use IP Security Architecture (IPsec) to configure secure communication between partner clusters. IPsec enables you to set policies that permit or require either secure datagram authentication, or actual data encryption, or both, between machines communicating by using IP. Consider using IPsec for the following cluster communications:

Oracle Solaris Cluster software and Geographic Edition software support IPsec by using only manual keys. Keys must be stored manually on the cluster nodes for each combination of server and client IP address. The keys must also be stored manually on each client.

Refer to the Part III, IP Security, in Oracle Solaris Administration: IP Services for a full description of IPsec configuration parameters.

How to Configure IPsec for Secure Cluster Communication

In the Geographic Edition infrastructure, the hostname of a logical host is identical to the cluster name. The logical hostname is a special HA resource. You must set up a number of IP addresses for various Geographic Edition components, depending on your cluster configuration.

On each partner cluster, you must configure encryption and authorization for exchanging inbound and outbound packets from a physical node to the logical-hostname addresses. The values for the IPsec configuration parameters on these addresses must be consistent between partner clusters.

IPsec uses two configuration files:

The following procedure configures a cluster, cluster-paris, for IPsec secure communication with another cluster, cluster-newyork. The procedure assumes that the local logical hostname on cluster-paris is lh-paris-1 and that the remote logical hostname is lh-newyork-1. Inbound messages are sent to lh-paris-1 and outbound messages are sent to lh-newyork-1.

Use the following procedure on each node of cluster-paris.

  1. Log in to the first node of the primary cluster, phys-paris-1, as superuser.

    For a reminder of which node is phys-paris-1, see Example Geographic Edition Cluster Configuration.

  2. Set up an entry for the local address and remote address in the IPsec policy file.

    The policy file is located at /etc/inet/ipsecinit.conf. Permissions on this file should be 644. For more information about this file, see the ipsecconf(1M) man page.

    For information about the names and values that are supported by Geographic Edition software, see Appendix B, Legal Names and Values of Geographic Edition Entities.

    1. Configure the communication policy.

      The default port for the tcp_udp plug-in is 2084. You can specify this value in the etc/cacao/instances/default/modules/com.sun.cluster.geocontrol.xml file.

      The following entry in the /etc/inet/ipsecinit.conf file configures a policy with no preference for authorization or encryption algorithms.

      # {raddr lh-newyork-1 rport 2084} ipsec {auth_algs any encr_algs any \
      sa shared} {laddr lh-paris-1 lport 2084} ipsec {auth_algs any encr_algs \
      any sa shared}

      When you configure the communication policy on the secondary cluster, cluster-newyork, you must reverse the policies.

      # {laddr lh-newyork-1 lport 2084} ipsec {auth_algs any encr_algs \
      any sa shared} {raddr lh-paris-1 rport 2084} ipsec {auth_algs any encr_algs \
      any sa shared}
    2. Add the policy by rebooting the node or by running the following command.
      # ipsecconf -a /etc/inet/ipsecinit.conf
  3. Set up encryption and authentication keys for inbound and outbound communication.

    The communication file is located at /etc/init/secret/ipseckeys. Permissions on the file should be 600.

    Add keys:

    # ipseckey -f /etc/init/secret/ipseckeys

    Key entries have the following general format:

    # inbound to cluster-paris
    add esp spi paris-encr-spi dst lh-paris-1 encr_alg paris-encr-algorithm \
    encrkey paris-encrkey-value
    add ah spi newyork-auth-spi dst lh-paris-1 auth_alg paris-auth-algorithm \
    authkey paris-authkey-value
    
    # outbound to cluster-newyork
    add esp spi newyork-encr-spi dst lh-newyork-1 encr_alg newyork-encr-algorithm \
    encrkey newyork-encrkey-value
    add ah spi newyork-auth-spi dst lh-newyork-1 auth_alg newyork-auth-algorithm \
    authkey newyork-authkey-value

    For more information about the communication files, see the ipsecconf(1M) man page.