Socks server

Socks-DeleGate with SERVER=socks accepts both SocksV4 and SocksV5, whereas SERVER=socks4 and SERVER=socks5 accepts only SocksV4 and SocksV5 respectively. Currently, only USER/PASS authentication scheme of SocksV5 is supported.

Example: Socks-DeleGate

# delegated -P1080 SERVER=socks
Example: forwarding to an upstream Socks server
# delegated -P1080 SERVER=socks SOCKS=sockhost

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.

• SRCIF="host:port:socks-udp-tosv" -- network interface to servers
  SRCIF="0.0.0.0:0:socks-udp-tosv" makes DeleGate as a SOCKS client behave compliantly to the SOCKSv5 specification on UDP ASSOCIATE.
  
• SRCIF="host:port:socks-udp-tocl" -- network interface to clients
  SRCIF="0.0.0.0:0:socks-udp-tocl" suppresses the failure in DeleGate as a SOCKS server trying to bind a UDP socket to a specific port number.

SOCKS parameter*    ==  SOCKS=host[:[port][/socksOpt][:dstHostList[:srcHostList]]]
          socksOpt  ==  [ -4 | -r ]*
                    --  default: none

Specify to use Socks server on host. The server is expected to recognize Socks version 5 protocol. If the server supports only version 4, specify "-4" option like "SOCKS=host:port/-4".
The "-r" option controls which of DeleGate or Socks server does the name resolution (from the host name of a target host to its IP address). With a SocksV4 server, name resolution is done by DeleGate by default. "-r" option make the resolution be delegated to the server (This is applicable if the server supports extended Socks4A protocol). With a SocksV5 server, name resolution is delegated to the server by default, and "-r" option make the resolution be done locally by DeleGate.
By default, the connection establishment via Socks will be tried after all of other trials failed, but you can control the order by the CONNECT parameter.
If the dstHostList part is omitted, the default value for it is "!.localnet". This default value can be changed by redefining the named HostList ".socksdst" which is predefined as HOSTLIST=".socksdst:!.localnet"

Example:

CONNECT=s,d SOCKS="sockshost:1080:!.localnet,!*.my.domain"

SOCKMUX parameter*  ==  SOCKMUX=host:port:option[,option]*
            option  ==  acc | con | ssl
                    --  default: none
                    --  status: tentative

If specified together with SOCKS, PROXY, MASTER (to chain two DeleGate), then the communication between DeleGate is multiplexed on a single persistent connection using SockMux. This is useful to reduce the delay to establish many connections repeatedly between DeleGate which are running distant from each other with long RTT.

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:

acc -- accept a SockMux connection at "host:port".
con -- connect a SockMux connection to "host:port".
ssl -- use SSL instead of the "Credhy" encryption.

Example: SOCKS proxies chained over SockMux

hostA% delegated SOCKMUX=hostA:8000:acc SERVER=socks -P2080
hostB% delegated SOCKMUX=hostA:8000:con SERVER=socks -P1080 SOCKS=hostA:8000


Example: SOCKS proxies chained over SockMux connected from the server side

hostA% delegated SOCKMUX=hostB:8000:con SERVER=socks -P2080
hostB% delegated SOCKMUX=hostB:8000:acc SERVER=socks -P1080 SOCKS=hostA:8000


Example: HTTP proxies chained over SockMux

hostA% delegated SOCKMUX=hostA:8000:acc SERVER=http -P9080
hostB% delegated SOCKMUX=hostA:8000:con SERVER=http -P8080 PROXY=hostA:8000


Example: HTTP via SOCKS proxy chained over SockMux

hostA% delegated SOCKMUX=hostA:8000:acc SERVER=socks -P2080
hostB% delegated SOCKMUX=hostA:8000:con SERVER=http -P8080 SOCKS=hostA:8000

SockMux server

SockMux is an experimental protocol designed for inter-DeleGate communication. It is a simple protocol for "port forwarding" to accept, relay and destroy connections, multiplexed over a single persistent connection. A pair of SockMux-DeleGate establish and retain a connection between them, then forward port from local to remote each other over the connection.

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

hostX% delegated SERVER=sockmux -PhostX:9000 PORT=9023 SERVER="telnet://hostX,-in"
hostY% delegated SERVER=sockmux://hostX:9000 PORT=9023 SERVER="telnet://hostY,-in"
// a pair of SockMux-DeleGate is connected at the port "hostX:9000", then
// the port "hostX:9023" is forwarded to "telnet://hostY"
// the port "hostY:9023" is forwarded to "telnet://hostX"


Example: uni-directional SockMux-DeleGate

hostX% delegated SERVER=sockmux -PhostX:9000 SERVER="telnet://hostX,-in"
hostY% delegated SERVER=sockmux://hostX:9000 PORT=hostY:9023
// hostY:9023 is forwarded to "telnet://hostX".

Example: uni-directional to proxy-Telent-DeleGate

hostX% delegated SERVER=sockmux -PhostX:9000 PORT=hostX:9023
hostY% delegated SERVER=sockmux://hostX:9000 SERVER="telnet,-in"
// hostX:9023 is forwarded to a Telnet proxy on hostY.

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:

DEST=host:port[:srcHostList] for SERVER=tcprelay://host:port,-in[:-:srcHostList]
DEST=host:port/udp[:srcHostList] for SERVER=udprelay://host:port,-in[:-:srcHostList]

Example: tcprelay over SockMux

hostX% delegated SERVER=sockmux://hostY:9000 PORT=hostX:111
hostY% delegated SERVER=sockmux -PhostY:9000 DEST=hostT:111
// hostX:111/tcp is forwarded to the server at hostT:111/tcp via hostY.

Example: relaying UDP over SockMux/TCP

hostX% delegated SERVER=sockmux://hostY:9000 PORT=hostX:53/udp
hostY% delegated SERVER=sockmux -PhostY:9000 DEST=hostU:53/udp
// hostX:53/udp is forwarded to the server at hostU:53/udp via hostY.

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

% mkfifo /tmp/com0
% mkfifo /tmp/com1
serv1) SERVER=sockmux:commin@/tmp/com0 SERVER=sockmux:commout@/tmp/com1 ...
serv2) SERVER=sockmux:commin@/tmp/com1 SERVER=sockmux:commout@/tmp/com0 ...


Example: use communication port between two hosts (not tested yet)

host1) SERVER=sockmux:comm@com1 ...
host2) SERVER=sockmux:comm@com2 ...


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

% SERVER="sockmux:proc@connectCommand" ...


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

hostX% ... PORT=8023,8080
hostY% ... SERVER=telnet,-in:-:-P8023 SERVER=http,-in:-:-P8080
// hostX:8023 is forwarded to Telnet-proxy on hostY
// hostX:8080 is forwarded to HTTP-proxy on hostY


NOTE: forwarding FTP data connection is not supported (yet).

STLS parameter*     ==  STLS=stlsSpecs[,sslwayCom][:connMap]
         stlsSpecs  ==  [-]stlsSpec[/im][/ssl][,stlsSpecs]
          stlsSpec  ==  fsv | fcl | mitm | imimSec
         sslwayCom  ==  {sslway [-Vrfy] [-CApath dir] ...}
           connMap  ==  ProtoList:dstHostList:srcHostList
                    --  default: none
                    --  restriction: applicable to HTTP, FTP, SMTP, POP, IMAP, SOCKS
                    --  required: SSLway

This parameter controls the initiation of SSL (TLS) based on a negotiation between client and server in each application protocol. The common scheme of the negotiation is known as "STARTTLS". "fsv" specifies using SSL with server and "fcl" specifies using SSL with client. When SSL is not supported on a connection, the STARTTLS negotiation will fail and the connection will be closed by default. To continue a session even when SSL is not available, prefix "-" to "fsv" or "fcl".

If "fcl" is specified, a client may start SSL without STARTTLS negotiation. Such implicit SSL negotiation from the client-side is detected by peeping a SSL hand-shake packet on the connection from the client-side at the beginning of a session for a certain period specified with imimSec. The default value is "im0.25" (250m seconds). "-im" disables this implicit SSL negotiation. If a stlsSpec is followed with "/im" as STLS="fsv/im" for example, SSL with the peer (with the server in this case) is applied without the STARTTLS negotiation.

If "mitm" is specified, it behaves like "-fcl,-fsv" that is if SSL is enabled in the client side then SSL on the server side is enabled. It can be used with a HTTP proxy DeleGate as a "secure proxy" or "SSL-tunnel" to peep the bidirectional communication in CONNECT method, relaying it as a usual HTTP applying filters and cache. ("mitm" means "Man-In-The-Middle" mode) If it is set optional as "STLS=-mitm" then the MITM mode is activated only when the client specified the server name prefixing with "-mitm." as "https://-mitm.host.domain/" for "https://host.domain/".

If non default SSLway command path or options are necessary to be used, the SSLway command can be specified after stlsSpecs as STLS="fcl,sslway -Vrfy -cert mycert.pem" for example.

Example:

STLS="fcl" -- use SSL with client (exit the session if not available)
STLS="-fcl" -- use SSL with client if available
STLS="fsv,-fcl" -- use SSL with server, and with client if available
STLS="fsv/ssl" SERVER="ftp" -- use AUTH SSL instead of AUTH TLS
STLS="fsv,im0.5" SERVER="ftp" -- automatic detection of implicit/explicit SSL server