Client SOCKS support
The i5/OS operating system supports SOCKS version 4. This enables programs that use the AF_INET address family with the SOCK_STREAM socket type to communicate with server programs running on systems outside a firewall.
A firewall is a very secure host that a network administrator places between a secure internal network and a less secure external network. Typically such a network configuration does not allow communications that originate from the secure host to be routed on the less secure network, and vice versa. Proxy servers that exist on the firewall help manage required access between secure hosts and less secure networks.
- They hide your internal network from outside systems.
- They protect the host from direct access by outside systems.
- They can filter data that comes in from outside if they are properly designed and configured.
A common alternative to running multiple proxy servers on a firewall is to run a more robust proxy server known as a SOCKS server. A SOCKS server can act as a proxy for any TCP client connection that is established through the sockets API. The key advantage of the i5/OS Client SOCKS support is that it enables client applications to access a SOCKS server transparently without changing any client code.
The following figure shows a common firewall arrangement with an HTTP proxy, a telnet proxy, and a SOCKS proxy on the firewall. Notice that the two separate TCP connections used for the secure client that is accessing a server on the internet. One connection leads from the secure host to the SOCKS server, and the other leads from the less secure network to the SOCKS server.
Two actions are required on the secure client host to use a SOCKS server:
- Configure a SOCKS server.
- On the secure client system, define all outbound client
TCP connections that are to be directed to the SOCKS server on the client
system.
To configure client SOCKS support, follow these steps:
- From System i® Navigator, expand .
- Right-click TCP/IP Configuration.
- Click Properties.
- Click the SOCKS tab.
- Enter your connection information about the SOCKS page.
Note: The secure client SOCKS configuration data is saved in the QASOSCFG file in library QUSRSYS on the secure client host system.
When configured, the system automatically directs certain outbound connections to the SOCKS server you specified on the SOCKS page. You do not need to make any changes to the secure client application. When it receives the request, the SOCKS server establishes a separate external TCP/IP connection to the server in the less secure network. The SOCKS server then relays data between the internal and external TCP/IP connections.
Up to this point, outbound TCP connections that originate from the secure client have been addressed. Client SOCKS support also lets you tell the SOCKS server to allow an inbound connection request across a firewall. An Rbind() call from the secure client system allows this communication. For Rbind() to operate, the secure client must have previously issued a connect() call and the call must have resulted in an outbound connection over the SOCKS server. The Rbind() inbound connection must be from the same IP address that was addressed by the outbound connection that the connect() established.
The following figure shows a detailed overview of how sockets APIs interact with a SOCKS server transparent to the application. In the example, the FTP client calls the Rbind() API instead of a bind() API, because the FTP protocol allows the FTP server to establish a data connection when there is a request from the FTP client to send files or data. It makes this call by recompiling the FTP client code with the __Rbind preprocessor #define, which defines bind() to be Rbind(). Alternatively, an application can explicitly code Rbind() in the pertinent source code. If an application does not require inbound connections across a SOCKS server, Rbind() should not be used.
- The FTP client initiates an outbound TCP connection to a less secure network through a SOCKS server. The destination address that the FTP client specifies on the connect() is the IP address and port of the FTP server located on the less secure network. The secure host system is configured through the SOCKS page to direct this connection through the SOCKS server. When configured, the system automatically directs the connection to the SOCKS server that was specified through the SOCKS page.
- A socket is opened and Rbind() is called to establish an inbound TCP connection. When established, this inbound connection is from the same destination-outbound IP address that was specified above. You must pair outbound and inbound connections over the SOCKS server for a particular thread. In other words, all Rbind() inbound connections should immediately follow the outbound connection over the SOCKS server. You cannot attempt to intervene non-SOCKS connections relating to this thread before the Rbind() runs.
- getsockname() returns the SOCKS server address. The socket logically binds to the SOCKS server IP address coupled with a port that is selected through the SOCKS server. In this example, the address is sent through the "control connection" Socket CTLed to the FTP server that is located on the less secure network. This is the address to which the FTP server connects. The FTP server connects to the SOCKS server and not directly to the secure host.
- The SOCKS server establishes a data connection with the FTP client and relays data between the FTP client and the FTP server. Many SOCKS servers allow a fixed length of time for the server to connect to the Secure client. If the server does not connect within this time, errno ECONNABORTED is encountered on the accept().