Linux-UNIX: Configure a public and private address for an S-TAP
For an S-TAP deployed in a private network, Guardium® can refer to the S-TAP with a public IP address that is not visible from the database server on which S-TAP is installed, while the database uses a private address for the S-TAP.
About this task
- Cloud deployment with internal and external IPs.
- S-TAP clients are using private IPs, for example when running OpenStack and creating VMs.
- S-TAP Control page, Details section: Force server IP
- page.
- S-TAP configuration file guard_tap.ini: force_server_ip.
For example, you create a database system in the cloud. Internal to that system (if you're logged in), the server identifies with the IP address 1.1.1.1. But from the outside world (from any other machine), it responds to the IP 2.2.2.2. This makes it difficult to identify servers in report. If you set the tap_ip to 2.2.2.2, and set the private_tap_ip to 127.0.0.1 (default if it is a local IP), everything works smoothly, but there are inconsistencies between reports. To resolve this, set force_server_ip=1, then the server only identifies with the external, public IP (TAP IP), and all reports from this database use the IP 2.2.2.2 (one single consistent IP address).
Procedure
- Specify tap_ip in the guard_tap.ini, or STAP_TAP_IP in the Set up by Client page to the external, public IP address (virtual IP). This is the IP reported as the S-TAP host in the S-TAP Control page. If tap_ip is set to a name, it has to be resolvable by getserverbyname().
- Specify private_tap_ip in the guard_tap.ini, or STAP_PRIVATE_TAP_IP in the Set up by Client page, to an IP address that the database host can recognize (physical IP).
- Optional: If you want the collector to record the server IP address to be the address specified in tap_ip, set force_server_ip=1 in the guard_tap.ini, or STAP_FORCE_SERVER_IP in the Set up by Client page or from the S-TAP Control page, Details section.