Advanced Configuration — GNUnet documentation

Advanced Configuration — GNUnet documentation
User Manual
Advanced Configuration
View page source
Advanced Configuration
Config file format
In GNUnet realm, all components obey the same pattern to get
configuration values. According to this pattern, once the component has
been installed, the installation deploys default values in
$prefix/share/gnunet/config.d/
, in
.conf
files. In order to
override these defaults, the user can write a custom
.conf
file and
either pass it to the component at execution time, or name it
gnunet.conf
and place it under
$HOME/.config/
A config file is a text file containing sections, and each section
contains its values. The right format follows:
[section1]
value1 = string
value2 = 23

[section2]
value21 = string
value22 = /path22
Throughout any configuration file, it is possible to use
-prefixed
variables, like
$VAR
, especially when they represent filenames in in
the filesystem. It is also possible to provide defaults values for those
variables that are unset, by using the following syntax:
${VAR:-default}
However, there are two ways a user can set
-prefixable variables:
(a) by defining them under a
[paths]
section
[paths]
GNUNET_DEPLOYMENT_SHARED = ${HOME}/shared-data
..
[section-x]
path-x = ${GNUNET_DEPLOYMENT_SHARED}/x
or (b) by setting them in the environment
$ export VAR=/x
The configuration loader will give precedence to variables set under
[path]
, though.
The utility ‘
gnunet-config
‘, which gets installed along with
GNUnet, serves to get and set configuration values without directly
editing the
.conf
file. The option ‘
-f
‘ is particularly
useful to resolve filenames, when they use several levels of
-expanded variables. See ‘
gnunet-config
--help
‘.
Note that, in this stage of development, the file
$HOME/.config/gnunet.conf
can contain sections for
all
the
components.
.. _The-Single_002dUser-Setup:
The Single-User Setup
For the single-user setup, you do not need to do anything special and
can just start the GNUnet background processes using
gnunet-arm
. By
default, GNUnet looks in
~/.config/gnunet.conf
for a configuration
(or
$XDG_CONFIG_HOME/gnunet.conf
if
$XDG_CONFIG_HOME
is
defined). If your configuration lives elsewhere, you need to pass the
-c
FILENAME
option to all GNUnet commands.
Assuming the configuration file is called
~/.config/gnunet.conf
, you
start your peer using the
gnunet-arm
command (say as user
gnunet
) using:
gnunet-arm -c ~/.config/gnunet.conf -s
The "-s" option here is for "start". The command should return
almost instantly. If you want to stop GNUnet, you can use:
gnunet-arm -c ~/.config/gnunet.conf -e
The "-e" option here is for "end".
Note that this will only start the basic peer, no actual applications
will be available. If you want to start the file-sharing service, use
(after starting GNUnet):
gnunet-arm -c ~/.config/gnunet.conf -i fs
The "-i fs" option here is for "initialize" the "fs"
(file-sharing) application. You can also selectively kill only
file-sharing support using
gnunet-arm -c ~/.config/gnunet.conf -k fs
Assuming that you want certain services (like file-sharing) to be always
automatically started whenever you start GNUnet, you can activate them
by setting "IMMEDIATE_START=YES" in the respective section of the
configuration file (for example, "[fs]"). Then GNUnet with
file-sharing support would be started whenever you enter:
gnunet-arm -c ~/.config/gnunet.conf -s
Alternatively, you can combine the two options:
gnunet-arm -c ~/.config/gnunet.conf -s -i fs
Using
gnunet-arm
is also the preferred method for initializing
GNUnet from
init
Finally, you should edit your
crontab
(using the
crontab
command) and insert a line
@reboot gnunet-arm -c ~/.config/gnunet.conf -s
to automatically start your peer whenever your system boots.
The Multi-User Setup
This requires you to create a user
gnunet
and an additional group
gnunetdns
, prior to running
make
install
during installation.
Then, you create a configuration file
/etc/gnunet.conf
which should
contain the lines:
[arm]
START_SYSTEM_SERVICES = YES
START_USER_SERVICES = NO
Then, perform the same steps to run GNUnet as in the per-user
configuration, except as user
gnunet
(including the
crontab
installation). You may also want to run
gnunet-setup
to configure
your peer (databases, etc.). Make sure to pass
-c
/etc/gnunet.conf
to all commands. If you run
gnunet-setup
as user
gnunet
, you
might need to change permissions on
/etc/gnunet.conf
so that the
gnunet
user can write to the file (during setup).
Afterwards, you need to perform another setup step for each normal user
account from which you want to access GNUnet. First, grant the normal
user (
$USER
) permission to the group gnunet:
# adduser $USER gnunet
Then, create a configuration file in
~/.config/gnunet.conf
for the
$USER with the lines:
[arm]
START_SYSTEM_SERVICES = NO
START_USER_SERVICES = YES
This will ensure that
gnunet-arm
when started by the normal user
will only run services that are per-user, and otherwise rely on the
system-wide services. Note that the normal user may run gnunet-setup,
but the configuration would be ineffective as the system-wide services
will use
/etc/gnunet.conf
and ignore options set by individual
users.
Again, each user should then start the peer using
gnunet-arm
-s
and strongly consider adding logic to start the peer automatically to
their crontab.
Afterwards, you should see two (or more, if you have more than one USER)
gnunet-service-arm
processes running in your system.
Access Control for GNUnet
This chapter documents how we plan to make access control work within
the GNUnet system for a typical peer. It should be read as a
best-practice installation guide for advanced users and builders of
binary distributions. The recommendations in this guide apply to
POSIX-systems with full support for UNIX domain sockets only.
Note that this is an advanced topic. The discussion presumes a very good
understanding of users, groups and file permissions. Normal users on
hosts with just a single user can just install GNUnet under their own
account (and possibly allow the installer to use SUDO to grant
additional permissions for special GNUnet tools that need additional
rights). The discussion below largely applies to installations where
multiple users share a system and to installations where the best
possible security is paramount.
A typical GNUnet system consists of components that fall into four
categories:
User interfaces
User interfaces are not security sensitive and are supposed to be run
and used by normal system users. The GTK GUIs and most command-line
programs fall into this category. Some command-line tools (like
gnunet-transport) should be excluded as they offer low-level access
that normal users should not need.
System services and support tools
System services should always run and offer services that can then be
accessed by the normal users. System services do not require special
permissions, but as they are not specific to a particular user, they
probably should not run as a particular user. Also, there should
typically only be one GNUnet peer per host. System services include
the gnunet-service and gnunet-daemon programs; support tools include
command-line programs such as gnunet-arm.
Privileged helpers
Some GNUnet components require root rights to open raw sockets or
perform other special operations. These gnunet-helper binaries are
typically installed SUID and run from services or daemons.
Critical services
Some GNUnet services (such as the DNS service) can manipulate the
service in deep and possibly highly security sensitive ways. For
example, the DNS service can be used to intercept and alter any DNS
query originating from the local machine. Access to the APIs of these
critical services and their privileged helpers must be tightly
controlled.
Todo
Shorten these subsection titles
Recommendation - Disable access to services via TCP
GNUnet services allow two types of access: via TCP socket or via UNIX
domain socket. If the service is available via TCP, access control can
only be implemented by restricting connections to a particular range of
IP addresses. This is acceptable for non-critical services that are
supposed to be available to all users on the local system or local
network. However, as TCP is generally less efficient and it is rarely
the case that a single GNUnet peer is supposed to serve an entire local
network, the default configuration should disable TCP access to all
GNUnet services on systems with support for UNIX domain sockets. Since
GNUnet 0.9.2, configuration files with TCP access disabled should be
generated by default. Users can re-enable TCP access to particular
services simply by specifying a non-zero port number in the section of
the respective service.
Recommendation - Run most services as system user "gnunet"
GNUnet’s main services should be run as a separate user "gnunet" in a
special group "gnunet". The user "gnunet" should start the peer
using "gnunet-arm -s" during system startup. The home directory for
this user should be
/var/lib/gnunet
and the configuration file
should be
/etc/gnunet.conf
. Only the
gnunet
user should have the
right to access
/var/lib/gnunet
mode: 700
).
Recommendation - Control access to services using group "gnunet"
Users that should be allowed to use the GNUnet peer should be added to
the group "gnunet". Using GNUnet’s access control mechanism for UNIX
domain sockets, those services that are considered useful to ordinary
users should be made available by setting "UNIX_MATCH_GID=YES" for
those services. Again, as shipped, GNUnet provides reasonable defaults.
Permissions to access the transport and core subsystems might
additionally be granted without necessarily causing security concerns.
Some services, such as DNS, must NOT be made accessible to the
"gnunet" group (and should thus only be accessible to the "gnunet"
user and services running with this UID).
Recommendation - Limit access to certain SUID binaries by group "gnunet"
Most of GNUnet’s SUID binaries should be safe even if executed by normal
users. However, it is possible to reduce the risk a little bit more by
making these binaries owned by the group "gnunet" and restricting
their execution to user of the group "gnunet" as well (4750).
Recommendation - Limit access to critical gnunet-helper-dns to group "gnunetdns"
A special group "gnunetdns" should be created for controlling access
to the "gnunet-helper-dns". The binary should then be owned by root
and be in group "gnunetdns" and be installed SUID and only be
group-executable (2750).
Note that the group "gnunetdns" should have
no users in it at all, ever.
The "gnunet-service-dns" program should
be executed by user "gnunet" (via gnunet-service-arm) with the binary
owned by the user "root" and the group "gnunetdns" and be SGID
(2700). This way,
only
"gnunet-service-dns" can change its group
to "gnunetdns" and execute the helper, and the helper can then run as
root (as per SUID). Access to the API offered by "gnunet-service-dns"
is in turn restricted to the user "gnunet" (not the group!), which
means that only "benign" services can manipulate DNS queries using
"gnunet-service-dns".
Differences between "make install" and these recommendations
The current build system does not set all permissions automatically
based on the recommendations above. In particular, it does not use the
group "gnunet" at all (so setting gnunet-helpers other than the
gnunet-helper-dns to be owned by group "gnunet" must be done
manually). Furthermore, ‘make install’ will silently fail to set the DNS
binaries to be owned by group "gnunetdns" unless that group already
exists (!). An alternative name for the "gnunetdns" group can be
specified using the
--with-gnunetdns=GRPNAME
configure option.
Configuring the hostlist to bootstrap
After installing the software you need to get connected to the GNUnet
network. The configuration file included in your download is already
configured to connect you to the GNUnet network. In this section the
relevant configuration settings are explained.
To get an initial connection to the GNUnet network and to get to know
peers already connected to the network you can use the so called
"bootstrap servers". These servers can give you a list of peers
connected to the network. To use these bootstrap servers you have to
configure the hostlist daemon to activate bootstrapping.
To activate bootstrapping, edit the
[hostlist]
-section in your
configuration file. You have to set the argument
-b
in the options
line:
[hostlist]
OPTIONS = -b
Additionally you have to specify which server you want to use. The
default bootstrapping server is "
". [^]
To set the server you have to edit the line "SERVERS" in the hostlist
section. To use the default server you should set the lines to
SERVERS = http://v10.gnunet.org/hostlist [^]
To use bootstrapping your configuration file should include these lines:
[hostlist]
OPTIONS = -b
SERVERS = http://v10.gnunet.org/hostlist [^]
Besides using bootstrap servers you can configure your GNUnet peer to
receive hostlist advertisements. Peers offering hostlists to other peers
can send advertisement messages to peers that connect to them. If you
configure your peer to receive these messages, your peer can download
these lists and connect to the peers included. These lists are
persistent, which means that they are saved to your hard disk regularly
and are loaded during startup.
To activate hostlist learning you have to add the
-e
switch to the
OPTIONS
line in the hostlist section:
[hostlist]
OPTIONS = -b -e
Furthermore you can specify in which file the lists are saved. To save
the lists in the file
hostlists.file
just add the line:
HOSTLISTFILE = hostlists.file
Best practice is to activate both bootstrapping and hostlist learning.
So your configuration file should include these lines:
[hostlist]
OPTIONS = -b -e
HTTPPORT = 8080
SERVERS = http://v10.gnunet.org/hostlist [^]
HOSTLISTFILE = $SERVICEHOME/hostlists.file
Disable default bootstrap (private network)
A public node will, by default, connect to a gnunet.org peer to learn
of other peers to bootstrap the network.
To avoid this behavior, either:
before build, remove the peer entry in
$REPO/contrib/hellos
after build, remove the peer entry in
$PREFIX/share/gnunet/hellos
Conversely, any public keys added to the same directories will make the
node
always
make explicit connections to those corresponding peers.
The use of the HELLOs in this folder can be controlled with the configuration
setting
USE_INCLUDED_HELLOS
of the
peerstore
service:
$ gnunet-config -s peerstore -o USE_INCLUDED_HELLOS
Note, however, that once the included HELLOs have been parsed, the
peerstore
will cache them locally in its databse. To purge included HELLOs in this case,
the database will have to be deleted.
Unless you want to establish a private network, you should not have to touch
this option.
Manually connecting peers
A gnunet node will learn peers to connect to from hostlist servers and/or
gossip from connected peers. It will however only connect to a selection
of peers on the network.
If you wish to connect to a specific peer apart from the automatically
negotiated connections, you can use the
hello
URI of the peer. The
URI is returned by the following command to
peer to be connected to
$ gnunet-hello --export-hello
The URI output is passed to the
gnunet-hello
command of
peer
that is connecting
$ echo "gnunet://hello/..." | gnunet-hello --import-hello
Configuration of the HOSTLIST proxy settings
The hostlist client can be configured to use a proxy to connect to the
hostlist server.
The hostlist client supports the following proxy types at the moment:
HTTP and HTTP 1.0 only proxy
SOCKS 4/4a/5/5 with hostname
In addition authentication at the proxy with username and password can
be configured.
To provide these options directly in the configuration, you can enter
the following settings in the
[hostlist]
section of the
configuration:
# Type of proxy server,
# Valid values: HTTP, HTTP_1_0, SOCKS4, SOCKS5, SOCKS4A, SOCKS5_HOSTNAME
# Default: HTTP
# PROXY_TYPE = HTTP

# Hostname or IP of proxy server
# PROXY =
# User name for proxy server
# PROXY_USERNAME =
# User password for proxy server
# PROXY_PASSWORD =
Configuring your peer to provide a hostlist
If you operate a peer permanently connected to GNUnet you can configure
your peer to act as a hostlist server, providing other peers the list of
peers known to him.
Your server can act as a bootstrap server and peers needing to obtain a
list of peers can contact it to download this list. To download this
hostlist the peer uses HTTP. For this reason you have to build your peer
with libgnurl (or libcurl) and microhttpd support.
To configure your peer to act as a bootstrap server you have to add the
-p
option to
OPTIONS
in the
[hostlist]
section of your
configuration file. Besides that you have to specify a port number for
the http server. In conclusion you have to add the following lines:
[hostlist]
HTTPPORT = 12980
OPTIONS = -p
If your peer acts as a bootstrap server other peers should know about
that. You can advertise the hostlist your are providing to other peers.
Peers connecting to your peer will get a message containing an
advertisement for your hostlist and the URL where it can be downloaded.
If this peer is in learning mode, it will test the hostlist and, in the
case it can obtain the list successfully, it will save it for
bootstrapping.
To activate hostlist advertisement on your peer, you have to set the
following lines in your configuration file:
[hostlist]
EXTERNAL_DNS_NAME = example.org
HTTPPORT = 12981
OPTIONS = -p -a
With this configuration your peer will a act as a bootstrap server and
advertise this hostlist to other peers connecting to it. The URL used to
download the list will be
Please notice:
The hostlist is
not
human readable, so you should not try to
download it using your webbrowser. Just point your GNUnet peer to the
address!
Advertising without providing a hostlist does not make sense and will
not work.
Configuring the datastore
The datastore is what GNUnet uses for long-term storage of file-sharing
data. Note that long-term does not mean ‘forever’ since content does
have an expiration date, and of course storage space is finite (and
hence sometimes content may have to be discarded).
Use the
QUOTA
option to specify how many bytes of storage space you
are willing to dedicate to GNUnet.
In addition to specifying the maximum space GNUnet is allowed to use for
the datastore, you need to specify which database GNUnet should use to
do so. Currently, you have the choice between sqlite and
Postgres.
Configuring the Postgres database
This text describes how to setup the Postgres database for GNUnet.
This Postgres plugin was developed for Postgres 8.3 but might work for
earlier versions as well.
Reasons to use Postgres
Easier to setup than MySQL
Real database
Reasons not to use Postgres
Quite slow
Still some manual setup required
Manual setup instructions
In
gnunet.conf
set in section
DATASTORE
the value for
DATABASE
to
postgres
Access Postgres to create a user:
with Postgres 8.x, use:
# su - postgres
createuser
and enter the name of the user running GNUnet for the role
interactively. Then, when prompted, do not set it to superuser,
allow the creation of databases, and do not allow the creation of
new roles.
with Postgres 9.x, use:
# su - postgres
createuser
$GNUNET_USER
where $GNUNET_USER is the name of the user running GNUnet.
As that user (so typically as user "gnunet"), create a database (or
two):
createdb
gnunet
# this way you can run "make check"
createdb
gnunetcheck
Now you should be able to start
gnunet-arm
Testing the setup manually
You may want to try if the database connection works. First, again login
as the user who will run
gnunet-arm
. Then use:
psql
gnunet
# or gnunetcheck
gnunet=>
\dt
If, after you have started
gnunet-arm
at least once, you get a
gn090
table here, it probably works.
Configuring the datacache
The datacache is what GNUnet uses for storing temporary data. This data
is expected to be wiped completely each time GNUnet is restarted (or the
system is rebooted).
You need to specify how many bytes GNUnet is allowed to use for the
datacache using the
QUOTA
option in the section
[dhtcache]
Furthermore, you need to specify which database backend should be used
to store the data. Currently, you have the choice between sqLite, MySQL
and Postgres.
Configuring the file-sharing service
In order to use GNUnet for file-sharing, you first need to make sure
that the file-sharing service is loaded. This is done by setting the
START_ON_DEMAND
option in section
[fs]
to "YES".
Alternatively, you can run
$ gnunet-arm -i fs
to start the file-sharing service by hand.
Except for configuring the database and the datacache the only important
option for file-sharing is content migration.
Content migration allows your peer to cache content from other peers as
well as send out content stored on your system without explicit
requests. This content replication has positive and negative impacts on
both system performance and privacy.
FIXME: discuss the trade-offs. Here is some older text about it...
Setting this option to YES allows gnunetd to migrate data to the local
machine. Setting this option to YES is highly recommended for
efficiency. Its also the default. If you set this value to YES, GNUnet
will store content on your machine that you cannot decrypt. While this
may protect you from liability if the judge is sane, it may not (IANAL).
If you put illegal content on your machine yourself, setting this option
to YES will probably increase your chances to get away with it since you
can plausibly deny that you inserted the content. Note that in either
case, your anonymity would have to be broken first (which may be
possible depending on the size of the GNUnet network and the strength of
the adversary).
Configuring logging
Since version 0.9.0, logging in GNUnet is controlled via the
-L
and
-l
options. Using
-L
, a log level can be specified. With log
level
ERROR
only serious errors are logged. The default log level is
WARNING
which causes anything of concern to be logged. Log level
INFO
can be used to log anything that might be interesting
information whereas
DEBUG
can be used by developers to log debugging
messages (but you need to run
meson
setup
with
-Dlogging=verbose
to get them compiled). The
-l
option is
used to specify the log file.
Since most GNUnet services are managed by
gnunet-arm
, using the
-l
or
-L
options directly is not possible. Instead, they can be
specified using the
OPTIONS
configuration value in the respective
section for the respective service. In order to enable logging globally
without editing the
OPTIONS
values for each service,
gnunet-arm
supports a
GLOBAL_POSTFIX
option. The value specified here is given
as an extra option to all services for which the configuration does
contain a service-specific
OPTIONS
field.
GLOBAL_POSTFIX
can contain the special sequence "{}" which is
replaced by the name of the service that is being started. Furthermore,
GLOBAL_POSTFIX
is special in that sequences starting with "$"
anywhere in the string are expanded (according to options in
PATHS
);
this expansion otherwise is only happening for filenames and then the
"$" must be the first character in the option. Both of these
restrictions do not apply to
GLOBAL_POSTFIX
. Note that specifying
anywhere in the
GLOBAL_POSTFIX
disables both of these
features.
In summary, in order to get all services to log at level
INFO
to
log-files called
SERVICENAME-logs
, the following global prefix
should be used:
GLOBAL_POSTFIX = -l $SERVICEHOME/{}-logs -L INFO
Configuring the transport service and plugins
The transport service in GNUnet is responsible to maintain basic
connectivity to other peers. Besides initiating and keeping connections
alive it is also responsible for address validation.
The GNUnet transport supports more than one transport protocol. These
protocols are configured together with the transport service.
The configuration section for the transport service itself is quite
similar to all the other services
START_ON_DEMAND = YES
@UNIXONLY@ PORT = 2091
HOSTNAME = localhost
HOME = $SERVICEHOME
CONFIG = $DEFAULTCONFIG
BINARY = gnunet-service-transport
#PREFIX = valgrind
NEIGHBOUR_LIMIT = 50
ACCEPT_FROM = 127.0.0.1;
ACCEPT_FROM6 = ::1;
PLUGINS = tcp udp
UNIXPATH = /tmp/gnunet-service-transport.sock
Different are the settings for the plugins to load
PLUGINS
. The
first setting specifies which transport plugins to load.
transport-unix A plugin for local only communication with UNIX domain
sockets. Used for testing and available on unix systems only. Just
set the port
transport
unix
PORT
22086
TESTING_IGNORE_KEYS
ACCEPT_FROM
transport-tcp A plugin for communication with TCP. Set port to 0 for
client mode with outbound only connections
transport
tcp
# Use 0 to ONLY advertise as a peer behind NAT (no port binding)
PORT
2086
ADVERTISED_PORT
2086
TESTING_IGNORE_KEYS
ACCEPT_FROM
# Maximum number of open TCP connections allowed
MAX_CONNECTIONS
128
transport-udp A plugin for communication with UDP. Supports peer
discovery using broadcasts.
transport
udp
PORT
2086
BROADCAST
YES
BROADCAST_INTERVAL
30
MAX_BPS
1000000
TESTING_IGNORE_KEYS
ACCEPT_FROM
transport-http HTTP and HTTPS support is split in two part: a client
plugin initiating outbound connections and a server part accepting
connections from the client. The client plugin just takes the maximum
number of connections as an argument.
transport
http_client
MAX_CONNECTIONS
128
TESTING_IGNORE_KEYS
ACCEPT_FROM
transport
https_client
MAX_CONNECTIONS
128
TESTING_IGNORE_KEYS
ACCEPT_FROM
The server has a port configured and the maximum number of
connections. The HTTPS part has two files with the certificate key
and the certificate file.
The server plugin supports reverse proxies, so a external hostname
can be set using the
EXTERNAL_HOSTNAME
setting. The webserver
under this address should forward the request to the peer and the
configure port.
transport
http_server
EXTERNAL_HOSTNAME
fulcrum
net
in
tum
de
gnunet
PORT
1080
MAX_CONNECTIONS
128
TESTING_IGNORE_KEYS
ACCEPT_FROM
transport
https_server
PORT
4433
CRYPTO_INIT
NORMAL
KEY_FILE
https
key
CERT_FILE
https
cert
MAX_CONNECTIONS
128
TESTING_IGNORE_KEYS
ACCEPT_FROM
transport-wlan
The next section describes how to setup the WLAN plugin, so here only
the settings. Just specify the interface to use:
transport
wlan
# Name of the interface in monitor mode (typically monX)
INTERFACE
mon0
# Real hardware, no testing
TESTMODE
TESTING_IGNORE_KEYS
ACCEPT_FROM
Configuring the WLAN transport plugin
The wlan transport plugin enables GNUnet to send and to receive data on
a wlan interface. It has not to be connected to a wlan network as long
as sender and receiver are on the same channel. This enables you to get
connection to GNUnet where no internet access is possible, for example
during catastrophes or when censorship cuts you off from the internet.
Requirements for the WLAN plugin
wlan network card with monitor support and packet injection (see
aircrack-ng.org
Linux kernel with mac80211 stack, introduced in 2.6.22, tested with
2.6.35 and 2.6.38
Wlantools to create the a monitor interface, tested with airmon-ng of
the aircrack-ng package
Configuration
There are the following options for the wlan plugin (they should be like
this in your default config file, you only need to adjust them if the
values are incorrect for your system)
# section for the wlan transport plugin
[transport-wlan]
# interface to use, more information in the
# "Before starting GNUnet" section of the handbook.
INTERFACE = mon0
# testmode for developers:
# 0 use wlan interface,
#1 or 2 use loopback driver for tests 1 = server, 2 = client
TESTMODE = 0
Before starting GNUnet
Before starting GNUnet, you have to make sure that your wlan interface
is in monitor mode. One way to put the wlan interface into monitor mode
(if your interface name is wlan0) is by executing:
sudo airmon-ng start wlan0
Here is an example what the result should look like:
Interface Chipset Driver
wlan0 Intel 4965 a/b/g/n iwl4965 - [phy0]
(monitor mode enabled on mon0)
The monitor interface is mon0 is the one that you have to put into the
configuration file.
Limitations and known bugs
Wlan speed is at the maximum of 1 Mbit/s because support for choosing
the wlan speed with packet injection was removed in newer kernels.
Please pester the kernel developers about fixing this.
The interface channel depends on the wlan network that the card is
connected to. If no connection has been made since the start of the
computer, it is usually the first channel of the card. Peers will only
find each other and communicate if they are on the same channel.
Channels must be set manually, e.g. by using:
iwconfig wlan0 channel 1
Configuring HTTP(S) reverse proxy functionality using Apache or nginx
The HTTP plugin supports data transfer using reverse proxies. A reverse
proxy forwards the HTTP request he receives with a certain URL to
another webserver, here a GNUnet peer.
So if you have a running Apache or nginx webserver you can configure it
to be a GNUnet reverse proxy. Especially if you have a well-known
website this improves censorship resistance since it looks as normal
surfing behaviour.
To do so, you have to do two things:
Configure your webserver to forward the GNUnet HTTP traffic
Configure your GNUnet peer to announce the respective address
As an example we want to use GNUnet peer running:
HTTP server plugin on
gnunet.foo.org:1080
HTTPS server plugin on
gnunet.foo.org:4433
A apache or nginx webserver on
A apache or nginx webserver on
And we want the webserver to accept GNUnet traffic under
. The required steps are described here:
Reverse Proxy - Configure your Apache2 HTTP webserver
First of all you need mod_proxy installed.
Edit your webserver configuration. Edit
/etc/apache2/apache2.conf
or
the site-specific configuration file.
In the respective
server
config
virtual
host
or
directory
section add the following lines:
ProxyTimeout 300
ProxyRequests Off

ProxyPass http://gnunet.foo.org:1080/
ProxyPassReverse http://gnunet.foo.org:1080/

Reverse Proxy - Configure your Apache2 HTTPS webserver
We assume that you already have an HTTPS server running, if not please
check how to configure a HTTPS host. An uncomplicated to use example is
the example configuration file for Apache2/HTTPD provided in
apache2/sites-available/default-ssl
In the respective HTTPS
server
config
virtual
host
or
directory
section add the following lines:
SSLProxyEngine On
ProxyTimeout 300
ProxyRequests Off

ProxyPass https://gnunet.foo.org:4433/
ProxyPassReverse https://gnunet.foo.org:4433/

More information about the apache mod_proxy configuration can be found
in the
Apache
documentation
Reverse Proxy - Configure your nginx HTTPS webserver
Since nginx does not support chunked encoding, you first of all have to
install the
chunkin
module
To enable chunkin add:
chunkin
on
error_page
411
@my_411_error
location
@my_411_error
chunkin_resume
Edit your webserver configuration. Edit
/etc/nginx/nginx.conf
or the
site-specific configuration file.
In the
server
section add:
location
/bar/
proxy_pass
proxy_buffering
off
proxy_connect_timeout
# more than http_server
proxy_read_timeout
350
# 60 default, 300s is GNUnet's idle timeout
proxy_http_version
.1
# 1.0 default
proxy_next_upstream
error
timeout
invalid_header
http_500
http_503
http_502
http_504
Reverse Proxy - Configure your nginx HTTP webserver
Edit your webserver configuration. Edit
/etc/nginx/nginx.conf
or the
site-specific configuration file.
In the
server
section add:
ssl_session_timeout
6m
location
/bar/
proxy_pass
proxy_buffering
off
proxy_connect_timeout
# more than http_server
proxy_read_timeout
350
# 60 default, 300s is GNUnet's idle timeout
proxy_http_version
.1
# 1.0 default
proxy_next_upstream
error
timeout
invalid_header
http_500
http_503
http_502
http_504
Reverse Proxy - Configure your GNUnet peer
To have your GNUnet peer announce the address, you have to specify the
EXTERNAL_HOSTNAME
option in the
[transport-http_server]
section:
[transport-http_server]
EXTERNAL_HOSTNAME = http://www.foo.org/bar/
and/or
[transport-https_server]
section:
[transport-https_server]
EXTERNAL_HOSTNAME = https://www.foo.org/bar/
Now restart your webserver and your peer...
Blacklisting peers
Transport service supports to deny connecting to a specific peer of to a
specific peer with a specific transport plugin using the blacklisting
component of transport service. With blacklisting it is possible to deny
connections to specific peers of to use a specific plugin to a specific
peer. Peers can be blacklisted using the configuration or a blacklist
client can be asked.
To blacklist peers using the configuration you have to add a section to
your configuration containing the peer id of the peer to blacklist and
the plugin if required.
Examples:
To blacklist connections to P565... on peer AG2P... using tcp add:
Todo
too long?
Todo
verify whether these still produce errors in pdf output
[transport-blacklist AG2PHES1BARB9IJCPAMJTFPVJ5V3A72S3F2A8SBUB8DAQ2V0O3V8G6G2JU56FHGFOHMQVKBSQFV98TCGTC3RJ1NINP82G0RC00N1520]
P565723JO1C2HSN6J29TAQ22MN6CI8HTMUU55T0FUQG4CMDGGEQ8UCNBKUMB94GC8R9G4FB2SF9LDOBAJ6AMINBP4JHHDD6L7VD801G = tcp
To blacklist connections to P565... on peer AG2P... using all plugins
add:
[transport-blacklist-AG2PHES1BARB9IJCPAMJTFPVJ5V3A72S3F2A8SBUB8DAQ2V0O3V8G6G2JU56FHGFOHMQVKBSQFV98TCGTC3RJ1NINP82G0RC00N1520]
P565723JO1C2HSN6J29TAQ22MN6CI8HTMUU55T0FUQG4CMDGGEQ8UCNBKUMB94GC8R9G4FB2SF9LDOBAJ6AMINBP4JHHDD6L7VD801G =
You can also add a blacklist client using the blacklist API. On a
blacklist check, blacklisting first checks internally if the peer is
blacklisted and if not, it asks the blacklisting clients. Clients are
asked if it is OK to connect to a peer ID, the plugin is omitted.
On blacklist check for (peer, plugin)
Do we have a local blacklist entry for this peer and this plugin?
YES: disallow connection
Do we have a local blacklist entry for this peer and all plugins?
YES: disallow connection
Does one of the clients disallow?
YES: disallow connection
Configuration of the HTTP and HTTPS transport plugins
The client parts of the http and https transport plugins can be
configured to use a proxy to connect to the hostlist server.
Both the HTTP and HTTPS clients support the following proxy types at the
moment:
HTTP 1.1 proxy
SOCKS 4/4a/5/5 with hostname
In addition authentication at the proxy with username and password can
be configured.
To configure these options directly in the configuration, you can
configure the following settings in the
[transport-http_client]
and
[transport-https_client]
section of the configuration:
# Type of proxy server,
# Valid values: HTTP, SOCKS4, SOCKS5, SOCKS4A, SOCKS5_HOSTNAME
# Default: HTTP
# PROXY_TYPE = HTTP

# Hostname or IP of proxy server
# PROXY =
# User name for proxy server
# PROXY_USERNAME =
# User password for proxy server
# PROXY_PASSWORD =
Configuring the GNUnet VPN
Before configuring the GNUnet VPN, please make sure that system-wide DNS
interception is configured properly as described in the section on the
GNUnet DNS setup. see
Configuring the GNU Name
System
, if you haven’t done so
already.
The default options for the GNUnet VPN are usually sufficient to use
GNUnet as a Layer 2 for your Internet connection. However, what you
always have to specify is which IP protocol you want to tunnel: IPv4,
IPv6 or both. Furthermore, if you tunnel both, you most likely should
also tunnel all of your DNS requests. You theoretically can tunnel
"only" your DNS traffic, but that usually makes little sense.
The other options as shown on the gnunet-setup tool are:
IPv4 address for interface
This is the IPv4 address the VPN interface will get. You should pick a
‘private’ IPv4 network that is not yet in use for you system. For
example, if you use
10.0.0.1/255.255.0.0
already, you might use
10.1.0.1/255.255.0.0
. If you use
10.0.0.1/255.0.0.0
already,
then you might use
192.168.0.1/255.255.0.0
. If your system is not in
a private IP-network, using any of the above will work fine. You should
try to make the mask of the address big enough (
255.255.0.0
or, even
better,
255.0.0.0
) to allow more mappings of remote IP Addresses
into this range. However, even a
255.255.255.0
mask will suffice for
most users.
IPv6 address for interface
The IPv6 address the VPN interface will get. Here you can specify any
non-link-local address (the address should not begin with
fe80:
). A
subnet Unique Local Unicast (
fd00::/8
prefix) that you are currently
not using would be a good choice.
Configuring the GNUnet VPN DNS
To resolve names for remote nodes, activate the DNS exit option.
Configuring the GNUnet VPN Exit Service
If you want to allow other users to share your Internet connection (yes,
this may be dangerous, just as running a Tor exit node) or want to
provide access to services on your host (this should be less dangerous,
as long as those services are secure), you have to enable the GNUnet
exit daemon.
You then get to specify which exit functions you want to provide. By
enabling the exit daemon, you will always automatically provide exit
functions for manually configured local services (this component of the
system is under development and not documented further at this time). As
for those services you explicitly specify the target IP address and
port, there is no significant security risk in doing so.
Furthermore, you can serve as a DNS, IPv4 or IPv6 exit to the Internet.
Being a DNS exit is usually pretty harmless. However, enabling IPv4 or
IPv6-exit without further precautions may enable adversaries to access
your local network, send spam, attack other systems from your Internet
connection and do other mischiefs that will appear to come from your
machine. This may or may not get you into legal trouble. If you want to
allow IPv4 or IPv6-exit functionality, you should strongly consider
adding additional firewall rules manually to protect your local network
and to restrict outgoing TCP traffic (e.g. by not allowing access to
port 25). While we plan to improve exit-filtering in the future, you’re
currently on your own here. Essentially, be prepared for any kind of
IP-traffic to exit the respective TUN interface (and GNUnet will enable
IP-forwarding and NAT for the interface automatically).
Additional configuration options of the exit as shown by the
gnunet-setup tool are:
IP Address of external DNS resolver
If DNS traffic is to exit your machine, it will be send to this DNS
resolver. You can specify an IPv4 or IPv6 address.
IPv4 address for Exit interface
This is the IPv4 address the Interface will get. Make the mask of the
address big enough (255.255.0.0 or, even better, 255.0.0.0) to allow
more mappings of IP addresses into this range. As for the VPN interface,
any unused, private IPv4 address range will do.
IPv6 address for Exit interface
The public IPv6 address the interface will get. If your kernel is not a
very recent kernel and you are willing to manually enable IPv6-NAT, the
IPv6 address you specify here must be a globally routed IPv6 address of
your host.
Suppose your host has the address
2001:4ca0::1234/64
, then using
2001:4ca0::1:0/112
would be fine (keep the first 64 bits, then
change at least one bit in the range before the bitmask, in the example
above we changed bit 111 from 0 to 1).
You may also have to configure your router to route traffic for the
entire subnet (
2001:4ca0::1:0/112
for example) through your computer
(this should be automatic with IPv6, but obviously anything can be
disabled).
Bandwidth Configuration
You can specify how many bandwidth GNUnet is allowed to use to receive
and send data. This is important for users with limited bandwidth or
traffic volume.
Configuring NAT
Most hosts today do not have a normal global IP address but instead are
behind a router performing Network Address Translation (NAT) which
assigns each host in the local network a private IP address. As a
result, these machines cannot trivially receive inbound connections from
the Internet. GNUnet supports NAT traversal to enable these machines to
receive incoming connections from other peers despite their limitations.
In an ideal world, you can press the "Attempt automatic configuration"
button in gnunet-setup to automatically configure your peer correctly.
Alternatively, your distribution might have already triggered this
automatic configuration during the installation process. However,
automatic configuration can fail to determine the optimal settings,
resulting in your peer either not receiving as many connections as
possible, or in the worst case it not connecting to the network at all.
To manually configure the peer, you need to know a few things about your
network setup. First, determine if you are behind a NAT in the first
place. This is always the case if your IP address starts with "10.*"
or "192.168.*". Next, if you have control over your NAT router, you
may choose to manually configure it to allow GNUnet traffic to your
host. If you have configured your NAT to forward traffic on ports 2086
(and possibly 1080) to your host, you can check the "NAT ports have
been opened manually" option, which corresponds to the "PUNCHED_NAT"
option in the configuration file. If you did not punch your NAT box, it
may still be configured to support UPnP, which allows GNUnet to
automatically configure it. In that case, you need to install the
"upnpc" command, enable UPnP (or PMP) on your NAT box and set the
"Enable NAT traversal via UPnP or PMP" option (corresponding to
"ENABLE_UPNP" in the configuration file).
Some NAT boxes can be traversed using the autonomous NAT traversal
method. This requires certain GNUnet components to be installed with
"SUID" privileges on your system (so if you’re installing on a system
you do not have administrative rights to, this will not work). If you
installed as ‘root’, you can enable autonomous NAT traversal by checking
the "Enable NAT traversal using ICMP method". The ICMP method requires
a way to determine your NAT’s external (global) IP address. This can be
done using either UPnP, DynDNS, or by manual configuration. If you have
a DynDNS name or know your external IP address, you should enter that
name under "External (public) IPv4 address" (which corresponds to the
"EXTERNAL_ADDRESS" option in the configuration file). If you leave the
option empty, GNUnet will try to determine your external IP address
automatically (which may fail, in which case autonomous NAT traversal
will then not work).
Finally, if you yourself are not behind NAT but want to be able to
connect to NATed peers using autonomous NAT traversal, you need to check
the "Enable connecting to NATed peers using ICMP method" box.
Peer configuration for distributors (e.g. Operating Systems)
The "GNUNET_DATA_HOME" in "[PATHS]" in
/etc/gnunet.conf
should
be manually set to "/var/lib/gnunet/data/" as the default
"~/.local/share/gnunet/" is probably not that appropriate in this
case. Similarly, distributors may consider pointing
"GNUNET_RUNTIME_DIR" to "/var/run/gnunet/" and "GNUNET_HOME" to
"/var/lib/gnunet/". Also, should a distributor decide to override
system defaults, all of these changes should be done in a custom
/etc/gnunet.conf
and not in the files in the
config.d/
directory.
Given the proposed access permissions, the "gnunet-setup" tool must be
run as use "gnunet" (and with option "-c /etc/gnunet.conf" so that
it modifies the system configuration). As always, gnunet-setup should be
run after the GNUnet peer was stopped using "gnunet-arm -e".
Distributors might want to include a wrapper for gnunet-setup that
allows the desktop-user to "sudo" (e.g. using gtksudo) to the
"gnunet" user account and then runs "gnunet-arm -e",
"gnunet-setup" and "gnunet-arm -s" in sequence.
Other Versions
v: latest
Tags
latest
Branches
master
v0.20.x
v0.21.x
v0.22.x
v0.23.x
v0.24.x
v0.25.x
v0.26.x
v0.27.x