dante   Frontpage - Dante - Download - Status - Support - Modules - Docs - Links - Survey
 

Server chaining

This page describes how to configure server chaining in the Dante server.

If it possible for a Dante server to forward requests using the same route syntax found in client configuration files. The same options that can be used in the client are available for the server and forwarding can be done with any of the proxy protocols supported by the client library, with some limitations that are covered in this document.

The most typical usage scenario involves forwarding all requests to another SOCKS server. The result of this will be that all bind, connect, and other commands will be performed on the remote SOCKS server, and not the SOCKS server that the client communicates with. The remote SOCKS server can optionally forward some or all requests to a third SOCKS server, a UPnP device or other supported proxy. Multiple route statements can be used to forward traffic to different SOCKS servers depending on source or destination address, port numbers, etc. For details on the route statement consult the Dante client configuration page.

Note that currently, only forwarding of the (TCP) connect command is supported by the Dante server.

Forwarding to SOCKS server

#forwarding route to SOCKS server (which supports both SOCKS version 4 and 5)
route {                                                                        
        from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.0.2.1 port = 1080            
        proxyprotocol: socks_v4 socks_v5
	command: connect
	protocol: tcp #udp not supported
        method: none
}

The route statement above shows how a server can be configured to forward requests to another SOCKS server. Forwarding of UDP is currently not supported by Dante. The protocol keyword is used to illustrate this by specifying that only TCP traffic should be forwarded.

Using authentication between two SOCKS servers is possible, but not currently supported. For this reason it is recommended that authentication between the servers is disabled when server chaining is used, by adding a method: none statement.

Remote SOCKS server configuration

#authentication methods
socksmethod: none

No special configuration is needed for the remote SOCKS server that will receive the forwarded requests. These requests will appear to be no different from SOCKS requests from other clients. The only limitation is that authentication between servers is not easily configured, as noted above. For this reason the server should have the none authentication method listed in the socksmethod keyword.

Forwarding to an HTTP proxy

#forwarding route to an HTTP proxy
route {                                                                        
        from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.0.2.1 port = 3128
        proxyprotocol: http_v1.0
	command: connect
}

Rather than forwarding requests to another SOCKS server, they can be forwarded to a HTTP proxy. This limits the commands that can be used to connect, which allows outgoing TCP connections to be made. Other commands are generally not supported by HTTP-proxies such as squid. The proxy server might need to be configured to allow this type of proxy request. No authentication is possible.

Forwarding to a UPnP device

#forwarding route to a UPnP device
route {                                                                        
        from: 0.0.0.0/0 to: 0.0.0.0/0
             via: http://192.0.2.2:1900/InternetGatewayDevice.xml
        proxyprotocol: upnp
	command: connect
}

The client can support UPnP if this is compiled in, and the same is the case with the server. It is possible to use the broadcast value to have the server try to discover the IGD address, but hardcoding the full address will improve forwarding performance.

Full remote SOCKS server template

The template for a remote server that will receive forwarded SOCKS requests is identical to the full server template found in the server configuration page. No changes should be necessary relative to this page.

Full server chaining template

This template does forwarding via the SOCKS protocol to another SOCKS server. Entries for other protocols are included but are commented out.

#logging
#errorlog: /var/log/sockd.errlog
logoutput: /var/log/sockd.log
#debug: 2

#server address specification
internal: 192.0.2.1 port = 1080
external: eth1

#server identities (not needed on solaris)
#user.privileged    : root
user.notprivileged : socks
#user.libwrap       : libwrap

#authentication methods
clientmethod: none
socksmethod: none

##
## SOCKS client access rules
##
#rule processing stops at the first match, no match results in blocking

#block access to socks server from 192.0.2.22
# client block {
#        #block connections from 192.0.2.22/32
#        from: 192.0.2.22/24 to: 0.0.0.0/0
#        log: error # connect disconnect
# }

#allow connections from local network (192.0.2.0/24)
client pass {
        from: 192.0.2.0/24 to: 0.0.0.0/0
	log: error # connect disconnect
}

##
## SOCKS command rules
##
#rule processing stops at the first match, no match results in blocking

#block communication with www.example.org
# socks block {
#        from: 0.0.0.0/0 to: www.example.org
#        command: connect
#        log: error # connect disconnect iooperation
# }

#generic pass statement - bind/outgoing traffic
socks pass {  
        from: 0.0.0.0/0 to: 0.0.0.0/0
	command: command #only connect supported currently
        log: error # connect disconnect iooperation
}

#forwarding route to SOCKS server (which supports both SOCKS version 4 and 5)
route {                                                                        
        from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.0.2.1 port = 1080            
        proxyprotocol: socks_v4 socks_v5
	command: connect
	protocol: tcp #udp not supported
        method: none
}

#forwarding route to HTTP proxy
#route {                                                                        
#        from: 0.0.0.0/0 to: 0.0.0.0/0 via: 192.0.2.1 port = 3128
#        proxyprotocol: http_v1.0
#	command: connect
#}

#forwarding route to UPnP device
#route {                                                                        
#        from: 0.0.0.0/0 to: 0.0.0.0/0
#             via: http://192.0.2.2:1900/InternetGatewayDevice.xml
#        proxyprotocol: upnp
#	command: connect
#}

Copyright © 1998-2016 Inferno Nettverk A/S