Web Proxy between TAS and Test Server
To support Containerized Test Servers we have added the ability to have a Web proxy between TAS the Test Server (TS).
When using this feature, (See Configuration steps below)
- The TAS must be in the DHCP/Discovery mode for Test Servers (TAS Setting: dhcp_test_servers=ON). When setting dhcp_test_server=ON for the first time, you must then reboot the TAS.
- The Web Proxy on the TAS must be turned on via ipcfg CLI script.
- The TS must be reachable by SSH (you need to enable SSH port forwarding if TS is behind a NAT).
The Web Proxy is just for the TAS-TS UDP communications. When connecting to the TS for Configuration, Logs, Debug/Trace, SSH/Connect, or File Uploads/Downloads, it will use the Real Address to connect via SSH. If using a container you will probably have to use a custom SSH port as well. This is already configurable from TS-Admin.
NOTE: Following does not describe or replace SSH communication between TAS and TS. SSH can use forwarded port via NAT 
TAS ports (without VPN or Proxy):
TAS (UDP 8889) ------------------------------------- TS1 (UDP 8890-8897, one per process)
------------------------------------- TS2 (UDP 8890-8897, one per process)
------------------------------------- TS3 (UDP 8890-8897, one per process)
After VPN:
TAS (UDP 1194) ------------------------------------- TS1 (UDP 1194)
------------------------------------- TS2 (UDP 1194)
------------------------------------- TS3 (UDP 1194)
Proxy:
TAS (TCP default 9998, configurable) ------------------------------------- TS1 (TCP-)
------------------------------------- TS2 (TCP-)
------------------------------------- TS3 (TCP-)
You do not need to open any port on TS as TCP is connection oriented and uplink connection is reused to send downlink data.
A combination of Original and Proxy communication is possible but not with VPN enabled.
TAS (UDP 8889, TCP default 9998) ------------------------------------- TS1 (UDP 8890-8897, one per process)
------------------------------------- TS2 (TCP)
------------------------------------ TS3 (TCP)
Proxy works this way:
There is only one instance of ProxyServer per TAS but for illustration purpose , it is shown in different rows and one ProxyClient Per TS :
{ TAS(127.0.0.1 : UDP 8889, internal only) -- (127.1.1.1: UDP 8890-8897, one per process) ProxyServer (TCP 9998, external) } - { (TCP random external) Proxy Client (127.0.0.1 : UDP 8890, internal only ) - (127.0.0.1 : UDP 8890-8897, one per process) TS1}
-- (127.1.1.2: UDP 8890-8897, one per process) ProxyServer (TCP 9998, external) } - { (TCP random external) Proxy Client (127.0.0.1 : UDP 8890, internal only ) - (127.0.0.1 : UDP 8890-8897, one per process) TS2}
-- (127.1.1.3: UDP 8890-8897, one per process) ProxyServer (TCP 9998, external) } - { (TCP random external) Proxy Client (127.0.0.1 : UDP 8890, internal only ) - (127.0.0.1 : UDP 8890-8897, one per process) TS3}
That’s how only 9998 Port for TAS needs to be exposed. To enable this Proxy You cannot have VPN or REMOTE-TS Proxy enabled.
To enable this Web proxy on TAS:
First enable the Web Proxy on the TAS via the ipcfg script:
|
##> ipcfg … … Modify VPN Service status (yes/no)? [no]: Enable WebProxy (yes/no)? [no]: yes Specify TCP port that TAS will listen (1-65535), (Prefered:9998) ? [9998]: … … |
To enable this on TS:
(TAS must be in DHCP mode and Proxy must be enabled b4 proceeding)
Method 1:
Same as TAS
First enable the Web Proxy on the TAS via the ipcfg script:
|
##> ipcfg … … Modify VPN Service status (yes/no)? [no]: Enable WebProxy (yes/no)? [no]: yes Specify TCP port that TAS will listen (1-65535), (Prefered:9998) ? [9998]: … … |
Method 2:
Add a new TS, using the TS’s hostname as the name and the REAL IP Address (External IP / IP used for connecting VIA SSH) as the Management IP, and setting the SSH Port to the reachable port.
--> 
Login via TS-Config, and point the TS to use the TCP port configured in TAS’s ipcfg:
Click Apply and Close the TS Configuration window.
Then on TS Admin window clear the TS IP Address from the Management IP field and click Apply, this will enable it to be discovered when the TS registers via the Proxy.
When the TS registers, it will correlate the hostname with the TS-Name and it will lock in with its unique fingerprint/ID and show the Proxied Real Address.
In the RT logs you can see when it registers the first time and associated with fingerprint like standard DHCP mode:
For any TS in DHCP/discovery mode, remember that until the TS is “discovered” by the TAS (i.e. registers with the TAS), you will be unable to Configure (TS Config) the TS. Both the Management IP (regular discovery mode) and the “Real Address” (proxied) are not persistent in DHCP/discovery mode. They are only learned upon registration and only stored in memory. If you restart your TAS or delete/re-add the TS this address is unknown. If you run into this situation and must configure the TS, you just have to enter the Real Address by hand into the Management IP Address to use TS-Config to correct any issues, then once configuration is applied, you can clear the TS Management IP address so the TAS is back into discovery mode.
When you recycle the TS and the TS is not running (ssesh not running), the command will timeout, and the TAS will ask user if they want to restart the TS over SSH: Recycling a Test Server
Terms:
- reboot: will fully restart the system, OS down and up.
- Recycle the TS is when we send a UDP command to the ssesh to restart itself.
- Stop/start/Restart the TS or TAS is stopping, starting, or restarting the TS (ssesh) or TAS (java) services running on the OS.