/etc/dante.conf is in dante-client 1.1.19.dfsg-3ubuntu6.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 | # $Id: socks.conf,v 1.28 2001/12/12 13:56:42 karls Exp $
#
# A sample dante.conf
# The configfile is divided into two parts; first misc. settings,
# then the routes. Objects in '[]' are optional.
#
#
# recommended order is:
# [debug]
# [logoutput]
# [resolveprotocol]
#
# routes:
# from to via
# [command]
# [extension]
# [protocol]
# [proxyprotocol]
#debug: 1 # uncomment to enable debugging
#logoutput: stdout # users usually don't want to be bothered with that.
# What protocol should be used for resolving hostnames? It's important
# to set this right.
#resolveprotocol: udp # default
#resolveprotocol: tcp # set this if your socksserver only supports socksv4.
#resolveprotocol: fake # set this if your clients can't access nameserver,
# neither directly nor proxied.
#
# the routes
#
# specifying routes for accepting remote connections (via bind()) is
# difficult since we can't know what the "to:" address is
# until we actually get the connection Since we support letting
# the client accept connections both via the proxyserver and
# "directly" at the same time, we have two options though:
# a) specify a route for bind (only) first going via the proxyserver.
# This will also handle "direct" connections.
# b) specify a route for bind (only) first going "direct".
# This means clients will only be able to accept "direct"
# connections.
# we want to accept remote connections via the proxyserver.
#route {
# from: 0.0.0.0/0 to: 0.0.0.0/0 via: 10.1.1.1 port = 1080
# command: bind
#}
# we do not want to accept remote connections via the proxyserver.
#route {
# from: 0.0.0.0/0 to: 0.0.0.0/0 via: direct
# command: bind
#}
# if you don't route all local connections via direct, you should
# at least route nameserver connections via direct connections if you
# can. That can make for much better performance, depending on
# your setup. Make sure the nameserver line is the first.
#
# Assuming your nameserver runs on address 10.1.1.1, you can do it like this:
#route {
# from: 0.0.0.0/0 to: 10.1.1.1/32 port = domain via: direct
#}
# have a route making all connections to loopback addresses be direct.
#route {
# from: 0.0.0.0/0 to: 127.0.0.0/8 via: direct
# command: connect udpassociate # everything but bind, bind confuses us.
#}
# Our net is the 10.0.0.0/8 net, let clients going to local address go
# direct, not via server.
#route {
# from: 0.0.0.0/0 to: 10.0.0.0/8 via: direct
#}
# for poor souls trapped behind a msproxy server.
#route {
# from: 0.0.0.0/0 to: 0.0.0.0/0 via: 10.1.1.1 port = 1745
# protocol: tcp # server supports tcp
# proxyprotocol: msproxy_v2 # server runs msproxy_v2
#}
# clients going anywhere else go via server listening at
# IP address 10.1.1.1, port 1080. Note that unless you have
# specified a direct connection for DNS, or the socksserver is resolvable
# without network traffic, you can't give a hostname for the socksserver,
# you must give a IP address. (the reasons for that are logical enough,
# you would create a loop otherwise.)
#route {
# from: 0.0.0.0/0 to: 0.0.0.0/0 via: 10.1.1.1 port = 1080
# protocol: tcp udp # server supports tcp and udp.
# proxyprotocol: socks_v4 socks_v5 # server supports socks v4 and v5.
# method: none #username # we are willing to authenticate via
# # method "none", not "username".
#}
# this is identical to the above, but it matches hostnames instead.
# This is if you have clients that are unable to resolve hostnames.
# It can be important that hostname routes come after address routes.
#route {
# from: 0.0.0.0/0 to: . via: 10.1.1.1 port = 1080
# protocol: tcp udp # server supports tcp and udp.
# proxyprotocol: socks_v4 socks_v5 # server supports socks v4 and v5.
# method: none #username # we are willing to authenticate via
# # method "none", not "username".
#}
# identical to above two routes, but using a httpproxy instead.
#
#route {
# from: 0.0.0.0/0 to: 0.0.0.0/0 via: 10.1.1.1 port = 3128
# command: connect # only thing a httproxy supports.
# proxyprotocol: http_v1.0
#}
#route {
# from: 0.0.0.0/0 to: . via: 10.1.1.1 port = 3128
# command: connect # only thing a httproxy supports.
# proxyprotocol: http_v1.0
#}
|