Custom Proxy Configuration and Fallback Mechanism

Introduction

This guide provides a comprehensive overview of configuring the GYTPOL Sensors's connectivity for both SaaS and OVA deployments. It covers essential topics such as proxy configuration, connection fallback mechanisms, log analysis, and retry strategies to ensure a seamless and reliable connection.

Minimum Sensor Version

Windows: 2.37.15
Linux: 2.8.3.X
Mac: 2.2.2.X

Custom Proxy Configuration

To configure a custom proxy, use the following command:

For Linux/Mac:

sudo /opt/gytpol/(gytlnx/gytmac) -set-proxy http(s)://<proxy-address>:port

For Windows:
"C:\Program Files\WindowsPowerShell\Modules\gytpol\Client\bin\client.exe" set-proxy http(s)://<proxy-address>:port

Open

Show Custom Proxy Configuration

To display the current proxy settings, use the following command:

For Linux/Mac:
sudo /opt/gytpol/(gytlnx/gytmac) --status | grep "Custom Proxy Addresses"

Open

For Windows:
C:\Program Files\WindowsPowerShell\Modules\gytpol\Config\proxy-config.json

Open

Clear Custom Proxy Configuration

To remove the custom proxy settings, use the following command:

For Linux/Mac:

sudo /opt/gytpol/(gytlnx/gytmac) -clear-proxy

For Windows:

"C:\Program Files\WindowsPowerShell\Modules\gytpol\Client\bin\client.exe" set-proxy clear

Open

Fallback Mechanism for Requests to SaaS/OVA

The sensor follows a priority-based fallback mechanism to determine the optimal proxy for sending requests to SaaS/OVA services. The fallback priority is as follows:

1. System Proxy (Highest Priority)

• The sensor first checks for a system-configured proxy.

• This is typically set via environment variables or network settings on the operating system.

• If a system proxy is available and functional, the sensor routes all traffic through it.

2. Custom Proxy

• If no system proxy is configured or available, the sensor falls back to a custom proxy.

• This proxy is manually set using the -set-proxy flag.

• The custom proxy allows users to override system settings and define a specific proxy server for the sensor's requests.

3. Direct Connection

• If both the system and custom proxies are unavailable or non-functional, the sensor attempts a direct connection to the SaaS/OVA service, bypassing any proxy.

4. GYTPOL Proxy (Last Resort)

• If all previous methods fail (i.e., system proxy, custom proxy, and direct connection), the sensor attempts to route requests through the GYTPOL Proxy as a final fallback.

How to Check the Sensor's Connection Method (Linux)

To determine which connection method the sensor is using, you can inspect the logs for specific request types.

1. Check "Get Tasks" Request

Use the following command to view logs related to task requests sent to the SaaS server:

2. Check "Upload Report" Request

Use the following command to view logs related to report uploads to the SaaS server:

These commands will display the relevant log entries along with 10 additional lines for context.

Retry and Backoff Mechanism

All connection attempts include a built-in retry and backoff mechanism to handle temporary failures.

• REST Requests:

  • Retries: Up to 5 attempts

  • Maximum Backoff: 32 seconds

• Upload Reports:

  • Retries: Up to 10 attempts

  • Maximum Backoff: 20 seconds

This ensures resilience by progressively increasing the delay between retries if failures persist.