diff options
Diffstat (limited to 'net-proxy')
-rw-r--r-- | net-proxy/dante/ChangeLog | 6 | ||||
-rw-r--r-- | net-proxy/dante/files/sockd.conf | 243 | ||||
-rw-r--r-- | net-proxy/dante/files/socks.conf | 127 |
3 files changed, 375 insertions, 1 deletions
diff --git a/net-proxy/dante/ChangeLog b/net-proxy/dante/ChangeLog index 99d580f51909..43c60e494dce 100644 --- a/net-proxy/dante/ChangeLog +++ b/net-proxy/dante/ChangeLog @@ -1,6 +1,10 @@ # ChangeLog for net-proxy/dante # Copyright 1999-2014 Gentoo Foundation; Distributed under the GPL v2 -# $Header: /var/cvsroot/gentoo-x86/net-proxy/dante/ChangeLog,v 1.80 2014/09/08 11:53:42 ssuominen Exp $ +# $Header: /var/cvsroot/gentoo-x86/net-proxy/dante/ChangeLog,v 1.81 2014/09/09 04:55:58 ssuominen Exp $ + + 09 Sep 2014; Samuli Suominen <ssuominen@gentoo.org> +files/sockd.conf, + +files/socks.conf: + Restore two necessary files wrt #522386 by Zhu Sha Zang 08 Sep 2014; Samuli Suominen <ssuominen@gentoo.org> -dante-1.3.2.ebuild, -dante-1.4.0-r1.ebuild, -dante-1.4.0.ebuild, -dante-1.4.0_pre1-r1.ebuild, diff --git a/net-proxy/dante/files/sockd.conf b/net-proxy/dante/files/sockd.conf new file mode 100644 index 000000000000..70b18747ba34 --- /dev/null +++ b/net-proxy/dante/files/sockd.conf @@ -0,0 +1,243 @@ +# The configfile is divided into two parts; first serversettings, +# then the rules. +# +# The recommended order is: +# Serversettings: +# logoutput +# internal +# external +# method +# clientmethod +# users +# compatibility +# extension +# connecttimeout +# iotimeout +# srchost +# +# Rules: +# client block/pass +# from to +# log +# +# block/pass +# from to +# method +# command +# log +# protocol +# proxyprotocol + +# the server will log both via syslog, to stdout and to /var/log/lotsoflogs +#logoutput: syslog stdout /var/log/lotsoflogs +logoutput: syslog + +# The server will bind to the address 10.1.1.1, port 1080 and will only +# accept connections going to that address. +#internal: 10.1.1.1 port = 1080 +# Alternatively, the interface name can be used instead of the address. +#internal: eth0 port = 1080 + +# all outgoing connections from the server will use the IP address +# 195.168.1.1 +#external: 192.168.1.1 + +# list over acceptable methods, order of preference. +# A method not set here will never be selected. +# +# If the method field is not set in a rule, the global +# method is filled in for that rule. +# + +# methods for socks-rules. +#method: username none #rfc931 + +# methods for client-rules. +#clientmethod: none + +#or if you want to allow rfc931 (ident) too +#method: username rfc931 none + +# +# An important section, pay attention. +# + +# when doing something that can require privilege, +# it will use the userid "sockd". +user.privileged: sockd + +# when running as usual, +# it will use the unprivileged userid of "sockd". +user.notprivileged: sockd + +# +# some options to help clients with compatibility: +# + +# when a client connection comes in the socksserver will try to use +# the same port as the client is using, when the socksserver +# goes out on the clients behalf (external: IP address). +# If this option is set, Dante will try to do it for reserved ports aswell. +# This will usually require user.privileged to be set to "root". +#compatibility: sameport + +# If you are using the bind extension and have trouble running servers +# via the server, you might try setting this. The consequences of it +# are unknown. +#compatibility: reuseaddr + +# +# The Dante server supports some extensions to the socks protocol. +# These require that the socks client implements the same extension and +# can be enabled using the "extension" keyword. +# +# enable the bind extension. +#extension: bind + + +# +# +# misc options. +# + +# how many seconds can pass from when a client connects til it has +# sent us it's request? Adjust according to your network performance +# and methods supported. +#connecttimeout: 30 # on a lan, this should be enough if method is "none". + +# how many seconds can the client and it's peer idle without sending +# any data before we dump it? Unless you disable tcp keep-alive for +# some reason, it's probably best to set this to 0, which is +# "forever". +#iotimeout: 0 # or perhaps 86400, for a day. + +# do you want to accept connections from addresses without +# dns info? what about addresses having a mismatch in dnsinfo? +#srchost: nounknown nomismatch + +# +# The actual rules. There are two kinds and they work at different levels. +# +# The rules prefixed with "client" are checked first and say who is allowed +# and who is not allowed to speak/connect to the server. I.e the +# ip range containing possibly valid clients. +# It is especially important that these only use IP addresses, not hostnames, +# for security reasons. +# +# The rules that do not have a "client" prefix are checked later, when the +# client has sent its request and are used to evaluate the actual +# request. +# +# The "to:" in the "client" context gives the address the connection +# is accepted on, i.e the address the socksserver is listening on, or +# just "0.0.0.0/0" for any address the server is listening on. +# +# The "to:" in the non-"client" context gives the destination of the clients +# socksrequest. +# +# "from:" is the source address in both contexts. +# + + +# the "client" rules. All our clients come from the net 10.0.0.0/8. +# + +# Allow our clients, also provides an example of the port range command. +#client pass { +# from: 10.0.0.0/8 port 1-65535 to: 0.0.0.0/0 +# method: rfc931 # match all idented users that also are in passwordfile +#} + +# This is identical to above, but allows clients without a rfc931 (ident) +# too. In practise this means the socksserver will try to get a rfc931 +# reply first (the above rule), if that fails, it tries this rule. +#client pass { +# from: 10.0.0.0/8 port 1-65535 to: 0.0.0.0/0 +#} + + +# drop everyone else as soon as we can and log the connect, they are not +# on our net and have no business connecting to us. This is the default +# but if you give the rule yourself, you can specify details. +#client block { +# from: 0.0.0.0/0 to: 0.0.0.0/0 +# log: connect error +#} + + +# the rules controlling what clients are allowed what requests +# + +# you probably don't want people connecting to loopback addresses, +# who knows what could happen then. +#block { +# from: 0.0.0.0/0 to: 127.0.0.0/8 +# log: connect error +#} + +# the people at the 172.16.0.0/12 are bad, no one should talk to them. +# log the connect request. +#block { +# from: 0.0.0.0/0 to: 172.16.0.0/12 +# log: connect error +#} + +# unless you need it, you could block any bind requests. +#block { +# from: 0.0.0.0/0 to: 0.0.0.0/0 +# command: bind +# log: connect error +#} + +# or you might want to allow it, for instance "active" ftp uses it. +# Note that a "bindreply" command must also be allowed, it +# should usually by from "0.0.0.0/0", i.e if a client of yours +# has permission to bind, it will also have permission to accept +# the reply from anywhere. +#pass { +# from: 10.0.0.0/8 to: 0.0.0.0/0 +# command: bind +# log: connect error +#} + +# some connections expect some sort of "reply", this might be +# the reply to a bind request or it may be the reply to a +# udppacket, since udp is packetbased. +# Note that nothing is done to verify that it's a "genuine" reply, +# that is in general not possible anyway. The below will allow +# all "replies" in to your clients at the 10.0.0.0/8 net. +#pass { +# from: 0.0.0.0/0 to: 10.0.0.0/8 +# command: bindreply udpreply +# log: connect error +#} + + +# pass any http connects to the example.com domain if they +# authenticate with username. +# This matches "example.com" itself and everything ending in ".example.com". +#pass { +# from: 10.0.0.0/8 to: .example.com port = http +# log: connect error +# method: username +#} + +# block any other http connects to the example.com domain. +#block { +# from: 0.0.0.0/0 to: .example.com port = http +# log: connect error +#} + +# everyone from our internal network, 10.0.0.0/8 is allowed to use +# tcp and udp for everything else. +#pass { +# from: 10.0.0.0/8 to: 0.0.0.0/0 +# protocol: tcp udp +#} + +# last line, block everyone else. This is the default but if you provide +# one yourself you can specify your own logging/actions +#block { +# from: 0.0.0.0/0 to: 0.0.0.0/0 +# log: connect error +#} 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 +#} |