DeleGate as a multiplexed SOCKS tunnel
DeleGate as a multiplexed SOCKS tunnel
In the version 9.2.4, DeleGate as a SOCKS proxy supported an easy configuration for relaying SOCKS over SSL and multiplexing SOCKS connections over a single persistent connection using SockMux.
____________________ ____________________
\ /
| |
client --+ SOCKS | SOCKS | +---> server
+-----> DeleGate <=====================> DeleGate --+
client --+ | SockMux | +---> server
| SSL |
____________________/ (encrypted and multiplexed) \____________________
|
|
hostA% delegated -P1080 SERVER=socks |
|
hostA% delegated -P1080 SERVER=socks hostB% delegated -P1080 SERVER=socks SOCKS=hostA:1080 |
|
hostA% delegated -P1080 SERVER=socks STLS=fcl hostB% delegated -P1080 SERVER=socks STLS=fsv SOCKS=hostA:1080 |
|
hostA% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:acc |
|
hostA% delegated -P1080 SERVER=socks SOCKMUX=hostB:8000:con |
|
hostA% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:acc,ssl |
|
hostA% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:acc SOCKS=hostB:1080 hostB% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:con SOCKS=hostA:1080 |
|
hostA% delegated -P1080 SERVER=socks SOCKS=hostB:1080.sox hostB% delegated -P1080 SERVER=socks SOCKS=hostA:1080.sox |
|
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. |
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:
con -- connect a SockMux connection to "host:port". ssl -- use SSL instead of the "Credhy" encryption. Example: SOCKS proxies chained over SockMux
hostB% delegated SOCKMUX=hostA:8000:con SERVER=socks -P1080 SOCKS=hostA:8000 Example: SOCKS proxies chained over SockMux connected from the server side
hostB% delegated SOCKMUX=hostB:8000:acc SERVER=socks -P1080 SOCKS=hostA:8000 Example: HTTP proxies chained over SockMux
hostB% delegated SOCKMUX=hostA:8000:con SERVER=http -P8080 PROXY=hostA:8000 Example: HTTP via SOCKS proxy chained over SockMux
hostB% delegated SOCKMUX=hostA:8000:con SERVER=http -P8080 SOCKS=hostA:8000 |
|
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
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
hostY% delegated SERVER=sockmux://hostX:9000 PORT=hostY:9023 // hostY:9023 is forwarded to "telnet://hostX". Example: uni-directional to proxy-Telent-DeleGate
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/udp[:srcHostList] for SERVER=udprelay://host:port,-in[:-:srcHostList] Example: tcprelay over SockMux
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
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/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)
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
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
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
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 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 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 |
| PageViews: 7,871 hits / 502 nets |