diff options
Diffstat (limited to 'net-proxy/dante/files/socks.conf')
| -rw-r--r-- | net-proxy/dante/files/socks.conf | 127 |
1 files changed, 127 insertions, 0 deletions
diff --git a/net-proxy/dante/files/socks.conf b/net-proxy/dante/files/socks.conf new file mode 100644 index 000000000000..4a7d1520a7b5 --- /dev/null +++ b/net-proxy/dante/files/socks.conf @@ -0,0 +1,127 @@ +# 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 +#} |