rweb - Manage the reverse Web mode (reverse proxy)
[1] rweb [site [raz | add <site-name> [(http | https <tls-id>[:<ca-id>]) [<public-ip> [<qos>]]] | del <site-name> [(http | https) [<ip>]]]]
[2] rweb [host [<site-name> [raz | (add <ip> [<port> [<balance-weight> [<qos>]]] | del <ip> [<port>])]]]
[3] rweb [balancer [<site-name> [(robin | traffic | pending) [nosticky | sticky [(insert | use) [<cookie-name>]]]]]]
[4] rweb [via [<site-name> <public-ip> [raz | (add | del) <gateway-ip> (master backup) [<priority>]]]]
[5] rweb [standby [<site-name> [off | on <url>]]]
This command is used to configure the reverse proxy module. Websites cloaked behind the reverse proxy are called reverse websites. The first usage form allows you to add, delete or erase websites. To add a website use the keyword add followed by the website name, the Web protocol (http or https), a TLS server identifier (only for HTTPS) and the public IP address (accessed by Web clients) for the defined website. An optional final argument may be used to customise the QoS (Quality of Service) for the given reverse website. For HTTPS websites, you have the possibility to specify a TLS server identifier and optionally an intermediate CA certificate identifier separated by the colon (:) character.
To delete a website use the keyword del followed by the site name, the protocol and the associated public IP address. If no protocol and IP address are given, it is assumed that the used protocol is HTTP and the IP address is the external IP address of the appliance. To erase all defined websites, use the keyword raz.
The public IP address can be the external IP address (or external VRRP IP addresses) or an IP address belonging to the external network. When the defined public IP address is other than the external IP address, it is added to the external network interface device as an alias IP address. Distinct websites can be configured with the same public IP address but please note that if the same public IP address is used for multiple HTTPS websites, only Web browsers (clients) that support TLS SNI (Server Name Indication) can be used at the client side. In case where the WAF mode is deactivated, wildcard or SAN certificates can be used to support multiple domain names associated to the same IP address. If the same website is configured to support both HTTP and HTTPS, all traffic destined to the HTTP version are redirected to the HTTPS version. If no protocol or IP address are given, it is assumed that the used protocol is HTTP and the IP address is the external IP address of the appliance.
The <qos> value in this usage form represents the percentage of the total bandwidth defined for reverse Web traffic allocated by the command qos (with the usage form qos shape rweb external). It should be an integer between 1 and 100. If no <qos> is given, the value of 100% is used by default. Please note that the QoS configured here is based on the given public IP address and protocol only (and not the given website name). So if two reverse websites have the same public IP address and protocol, the applied QoS will be the QoS configured first. To configure different QoS for distinct websites that have the same IP address and protocol, you have the possibility to associate them to distinct back end Web servers and configure different QoS to access those back end servers (see the second usage form below).
The second usage form allows you to associate real hosts (backend Web servers) to cloaked websites. To associate a real host to a website give the website name followed by the keyword add, the IP address of the host and optionally the port number on which the backend Web server is listening. If more than one backend host is associated to the same website, the website load is distributed over those backend hosts. In this case the optional balance weight allows you to balance the load more or less on a backend Web server. The balance weight should be an integer between 1 and 100. By default this value is set to 50. Finally the optional <qos> parameter allows you to customize the QoS (Quality of Service) for the defined real host.
The <qos> value in this usage form represents the percentage of the total bandwidth defined for reverse Web traffic allocated by the command qos (with the usage form qos shape rweb internal). If the same Web server represented by an IP address and port number running on a real backend host is used for more than one reverse website name, the effective Qos will be the highest defined QoS.
To delete a host use the keyword del followed by the IP address of that host and optionally the port number on which the host to delete is listening on. If no port number is given, the value of 80 is used by default. To erase all hosts associated to a website use the keyword raz.
The third usage form allows you to configure the load balancing policy over backend Web servers. To configure the load balancing policy for a given website you should specify a load balancing method and the stickiness of connections.
Three load balancing methods are available:
* robin: load balance backend Web servers in a round-robin fashion based on the number of requests.
* traffic:load balance backend Web servers according to the generated traffic. With this method, backend Web servers generating less traffic are requested more.
* pending: load balance backend Web servers according to the number of pending requests. With this method, backend Web servers having more pending requests are requested less.
The stickiness allows the same Web client to always be redirected to the same backend Web server. This ensures that the application context running on a backend Web server is preserved for a given Web client. Sticky connections are based on HTTP session cookies. Session cookies are either generated by the Web application running on backend Web servers or are inserted by the appliance into the Web traffic. By default the session cookie is inserted by the appliance.
Please note that if your backend Web servers use a deterministic algorithm to redirect the traffic in turn to other servers, you probably don’t need to activate the stickiness here.
To activate the stickiness based on an inserted cookie use the keyword sticky followed by the keyword insert and the cookie name prefix. The default prefix for an inserted cookie name is WGICPATHID. The inserted cookie name for a given website will be the concatenation of the cookie prefix and the range number of that website.
To activate the stickiness based on a cookie generated by the Web application running on backend Web servers use the keyword sticky followed by the keyword use and the cookie name. The default cookie name is JSESSIONID.
To completely deactivate the stickiness use the keyword nosticky.
The default load balancing method is "robin nosticky". Please note that changing the default load balancing policy for a website may have significant impact on your appliance performances.
In a load balancing configuration an automatic health checking is performed on real Web servers. If one Web server fails, it is removed from the load balancing pool and will be automatically restored to the load balancing pool when the failure is fixed. Real Web servers must be accessible on their listening IP address and port 80.
When the appliance is behind more than one external gateway (connected to the external interface) that source NAT the traffic with their own (distinct) IP addresses, you should explicitly specify the gateways from which external users can access a reverse website. The fourth usage form allows you to specify (via) gateways to use for a given website. Via gateways can have two roles: the master role and the backup role. When all gateways are available, a master gateway with the highest priority is elected to route Web traffic for a given website (identified by its <site-name> and <public-ip>). The elected gateway is then activated for that website. Please note that at a given point, one and only one gateway is considered as active for a given website. In case of a failure on the active gateway, a backup gateway (with the highest priority) is then elected to be activated. In case where a faulty gateway becomes operational again, the process of electing and activating via gateways is performed again.
To add a master via gateway to a given website, use the keyword via followed by the name and public IP address of that website (<site-name> <public-ip>), the keyword add, the gateway IP address to use, the keyword master and optionally the priority associated to the specified gateway. To add a backup gateway, use the keyword backup instead of the master keyword. To delete a gateway, use the keyword del instead of add. To erase the list of all via gateways for a given website, use the keywords raz. The priority is a numeric value between 0 and 255. If no priority is specified, the priority is set to 110 for a master gateway and to 100 for a backup gateway.
The fifth usage form allows you to put a reverse website temporarily in standby mode. When a reverse website is in standby mode all requests to it are redirected to an information page provided by the appliance or to a given URL. The standby mode may be useful during maintenance period. If a URL is given it should be in the form: (http|https|ftp)://<domain-name>[/<URI>] where an URI may contain an alphanumeric or any of the following characters: -._~:/?#[]@!$&()*+,;=. Any other character needs to be encoded with the percent-encoding. A percent-encoding is in the form %(a-fA-F0-9)(a-fA-F0-9) (use %27 for the quote character).
The "X-Forwarded-Proto" and "X-Forwarded-For" headers are added to HTTP requests sent to real backend servers in order to indicate the initial protocol and source IP address used by the end-user.
The QoS defined here for a HTTP website is based on the IP address associated to that website. To define distinct QoS for two HTTP websites, distinct IP addresses must be configured for those HTTP websites.
The TLS SNI for reverse websites is supported only if the WAF mode is activated or if at least one reverse website is configured with sticky load balancing on more than one backend Web server.
access (1) apply (1) mode (1) qos (1) system (1) tls (1) waf (1)
CacheGuard Technologies Ltd <www.cacheguard.com>
Send bug reports or comments to the above author.
Copyright (C) 2009-2023 CacheGuard - All rights reserved