Common Notation
TCPrelay
Example: two proxies on TCP with similar function
UDPrelay
Example: two proxies on UDP with similar function
Example: a gateway between UDP and TCP
A pair of gateways like above can be used to convey UDP packets over TCP connections, but such relaying (tunneling) is realized more efficiently using SockMux with a single TCP connection.
DGAuth server
Example: DGAuth-DeleGate server and its client
Example: DGAuth-DeleGate server and its client on the same host
A DGAuth server receives a set of components to be used to calculate digest for each application protocol, then return the digest, as follows.
PAM server
Example: PAM-DeleGate server and its client
Example: PAM-DeleGate server and its client communicating over SSL
Note that most of PAM authentications need to be executed under the privilege of superuser on Unix (with OWNER="root" option). But you can avoid running your PAM-DeleGate server with superuser privilege by installing external program "dgpam" under DGROOT/subin/.
The default port number of the experimental PAM/HTTP server is 8686. Other ports can be specified as AUTHRIZER=-pam//host..port, for example as AUTHORIZER="-pam//hostX..8765/passwd".
PAM/HTTP protocol uses the format of HTTP compatible request/response messages as follows.
Following the format, you can easily develop your own PAM server, instead of PAM-DeleGate, using your own HTTP server with CGI or so.
FTPxHTTP server
YYsh server
YYMUX server
SOCKMUX parameter* == SOCKMUX=host:port:option[,option]* option == acc | con | ssl -- default: none -- status: tentative
host:port specifies the port toward which a SockMux persistent connection is established. The connection is established from the DeleGate with "con" option to the DeleGate with "acc" option.
Options:
Example: SOCKS proxies chained over SockMux
Example: SOCKS proxies chained over SockMux connected from the server side
Example: HTTP proxies chained over SockMux
SOXCONF parameter* == SOXCONF=confSpec[,confSpec]* -- default: none
SockMux server
The persistent connection is established with "-Phost:port" parameter at receptor side, and "SERVER=sockmux://host:port" at connector side. The port to accept outgoing connections to be forwarded to remote is specified with PORT="listOfPorts parameter. The server to be connected for incoming connections from remote is specified with a postfix string ",-in" like SERVER="telnet://host:23,-in".
An incoming connection can be processed with DeleGate as a proxy of the specified protocol. If only protocol name is specified like SERVER="telnet,-in", or if "-in" is postfixed like "-in(option list)", then a DeleGate is invoked to process the connection. The option list is passed to the invoked DeleGate as the list of command line options. For example, SERVER="telnet://host,-in(+=config.cnf)" will invoke a DeleGate with command line options like ``delegated SERVER=telnet://host +=config.cnf''.
Example: bi-directional SockMux-DeleGate
Example: uni-directional SockMux-DeleGate
Example: uni-directional to proxy-Telent-DeleGate
When SockMux is used just to relay data between sockets, without interpreting the application protocol relayed over SockMux, such relaying can be represented with simpler expression using DEST parameter instead of SERVER as follows:
Example: tcprelay over SockMux
Example: relaying UDP over SockMux/TCP
Another way to establish a persistent connection between two SockMux-DeleGate is using a FIFO device like named pipe. It is specified like SERVER=sockmux:commtype@fifoName where commtype is one of "commin", "commout", and "comm", which represents uni-directional input, uni-directional output and bi-directional input/output respectively.
Example: use fifo device on a host
Example: use communication port between two hosts (not tested yet)
The persistent connection can be established by a given external program invoked by DeleGate. The process of the program is passed a socket to/from DeleGate at file descriptor number 0 and 1;
Example: establish connection by external command
The destination SERVER for an incoming connection from remote can be selected depending on which port it was accepted. A SERVER parameter postfixed with ":-:-Pxxxx" will be applied only to connections which is accepted on remote host with PORT=xxxx.
Example: forwarding multiple port
NOTE: forwarding FTP data connection is not supported (yet).
HTMUX parameter == HTMUX=sv[:[hostList][:portList]] | HTMUX=cl:host:port | HTMUX=px:host:port -- restriction: requires CAPSKEY -- default: none
Not only incoming connections but also outgoing connections from a HTMUX client is established via the HTMUX server by default. This might not necessary for a DeleGate that relays incoming request to internal server. In such case, use the CONNECT parameter to specify such connections to be established directory, as CONNECT="direct:*:192.168.1.*" for example.
Example:
This example implies that hostX is a multi-homed host with a private addresses 192.168.1.1 and a global address xx.xx.xx.xx. The DeleGate on hostX acts as a HTMUX server. HTTP DeleGate on hostI and FTP DeleGate on hostJ act as HTMUX client which remotely accepts requests (arrived at xx.xx.xx.xx) via the HTMUX server on HostX.
A pair of HTMUX server and client uses a single persistent connection to relay
multiple parallel connections on it multiplexing them by the
SockMux protocol.
This feature must not be exploited maliciously, for example to invite
incoming connections violating a restriction on a firewall.
Therefore you need to install CAPSKEY to enable this feature.
Other usages of HTMUX being disabled by default are
non-direct connection between client and server (connection via NAT or proxy),
too large clock skew between client and server (300 seconds by default),
or inserting SSL encryption between client and server.
There are two ways to enable non-direct connection for HTMUX. One way is to install a CAPSKEY to enable indirect HTMUX connection. Another way is inserting a HTMUX proxy as the following example.
Example: cascading HTMUX with a HTMUX proxy
The persistent connection between HTMUX client and server is capable to convey connections bi-directionally, thus can be used to make a pair of proxies over it. Each proxy accepts requests at the local port and forwards them to the remote peer as the following example.
Example: using HTMUX to make symmetric proxies (the simplest generic configuration)
In this example, -P8080 is equivalent to a wild-card address expression
"-P*:8080" to accept from the port number 8080 on any network interfaces
on the host.
Therefore requests to the port 8080 on any interface on hostX is forwarded
to the servers via the DeleGate on hostY as a HTMUX client (and a HTTP proxy).
Symmetrically, requests to the port 8080 on any interface on hostY is
forwarded to the servers via the DeleGate on hostX as a HTTP proxy (and a
HTMUX server at hostX:9876).
(Again, note that this feature is disabled by default and needs
CAPSKEY to enable it)
The port to be used on the server side and on the client side can be specified separately with the "/local" and "/remote" modifiers for -P or -Q option. "/local" marks a port to be used on the local host (on a HTMUX client), and "/remote" marks the port to be used on the remote host (on a HTMUX server). The specification "-P8080" in the above example is equivalent to "-P*:8080/remote,*:8080/local".
Example: using HTMUX bi-directionally
In this example, between hostX and hostI, requests to localhost:8081 on each host are forwarded to the peer (equivalent to "-Plocalhost:8081/remote,localhost:8081/local") Between hostX and hostJ, hostX:8082 and hostJ:8083 are forwarded to the peer (equivalent to "-PhostX:8082/remote,hostJ:8083/local")
Example: using HTMUX only for outbound requests
This is an example to use HTMUX only for outbound requests. It works even without the HTMUX parameter, but with HTMUX, a single persistent connection is used between the server and client. This usage of HTMUX is enabled by default when DeleGate is executed in foreground (with -fv option, running not as a service or a daemon), without restrictions described as above, and don't require CAPSKEY.
CAPSKEY parameter* == CAPSKEY=opaque -- default: none
Socks server
Example: Socks-DeleGate
To accept an incoming TCP connection via a SOCKS-DeleGate server, the network interface to be used for it is selected automatically by DeleGate (based on the DST.ADDR or DSTIP which is sent from a SOCKS client as the parameter of the BIND command). With the SRCIF parameter, you can select a network interface (and port number) manually, with the pseudo protocol name "tcpbind". The complete syntax of the parameter is SRCIF= "[host]:[port]:tcpbind[:dstHostList[:srcHostList]]". Typically, only the host filed is specified to select a network interface, like SRCIF="150.29.202.120::tcpbind" for example.
NOTE: When you chain DeleGate with another SOCKS server, it may cause problems in UDP relaying due to the private and tentative extensions to the SOCKS protocol by DeleGate. The following SRCIF parameters can be useful to escape such problems.