PageViews: 855 hits / 115 nets |
This is a short introduction to DeleGate to be used as a SOCKS server and/or client. (If you are totally unfamiliar with DeleGate, reading a short tutorial of DeleGate is recommended before reading this introduction) In short, the option SERVER=socks specifies to work as a SOCKS server, and SOCKS=socksServer specifies to work as a SOCKS client using the socksServer as the upstream SOCKS server. The simplest specification of socksServer is the host name (or address) of the upstream SOCKS server.
Examples
A HTTP proxy as a SOCKS client:
A FTP proxy as a SOCKS client:
A SOCKS server and client (forwarding to another SOCKS server):
A pair of a server and a client of SOCKS over SSL:
A transparent proxy/NAT as a SOCKS client:
Related Documents
( excerpt from the SocksTap document )
EXAMPLES
The simplest configuration of DeleGate as a SOCKS server (SOCKS-DeleGate):
hostA% delegated -P1080 SERVER=socks
|
Chaining two SOCKS-DeleGate:
hostA% delegated -P1080 SERVER=socks hostB% delegated -P1080 SERVER=socks SOCKS=hostA:1080 |
Encrypting the communication between two SOCKS-DeleGate servers with SSL:
hostA% delegated -P1080 SERVER=socks STLS=fcl hostB% delegated -P1080 SERVER=socks STLS=fsv SOCKS=hostA:1080 |
Multiplexing the communication between two SOCKS-DeleGate servers with SockMux:
hostA% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:acc |
The SockMux connection can be in the reverse direction of the connection of SOCKS protocol as this:
hostA% delegated -P1080 SERVER=socks SOCKMUX=hostB:8000:con |
By default, the communication over SockMux is encrypted in the "Credhy" algorithm. It can be replaced with SSL with ",ssl" option as this:
hostA% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:acc,ssl |
- Bidirectional SOCKS-DeleGate servers over SockMux:
hostA% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:acc SOCKS=hostB:1080 hostB% delegated -P1080 SERVER=socks SOCKMUX=hostA:8000:con SOCKS=hostA:1080 |
- Simplified configuration parameters:
hostA% delegated -P1080 SERVER=socks SOCKS=hostB:1080.sox hostB% delegated -P1080 SERVER=socks SOCKS=hostA:1080.sox |
- Connecting multiple SockMux clients to a single SockMux server
- Routing between SockMux clients (a SockMux server like a reflector)
- On-demand SockMux with a server like HTTP to multiplex connections
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.
SOCKS parameter* == SOCKS=host[:[port][/socksOpt][:dstHostList[:srcHostList]]] socksOpt == [ -4 | -r ]* -- default: none
Example:
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
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).
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 "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: