summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'net-proxy')
-rw-r--r--net-proxy/dante/ChangeLog6
-rw-r--r--net-proxy/dante/files/sockd.conf243
-rw-r--r--net-proxy/dante/files/socks.conf127
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
+#}