[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] HOWTO gnunet-vpn and gnunet-exit with shared secrets

From: carlo von lynX
Subject: [GNUnet-developers] HOWTO gnunet-vpn and gnunet-exit with shared secrets
Date: Mon, 12 Dec 2016 11:27:47 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

Picking up an old thread since there has been some misunderstanding
of what was said here:

On Fri, May 06, 2016 at 03:50:19PM +0200, Christian Grothoff wrote:
> On 05/05/2016 02:29 PM, Daniel Golle wrote:
> > Hi everyone!
> > 
> > I got a bunch of questions about the subsystems mentioned above:
> > 
> > 1. If TUNNEL_IPV? is set in [pt], how is the choice of gateway
> > implemented? Is there a way to explicitely choose a specific exit peer?
> Nope, the current code is supposed to find "some" peer that allows
> exiting to the specified destination, but there is no way from the
> outside to influence the endpoint of the tunnel.

This sentence was misunderstood by some people, so I try to clear
it up:

That is for the specific purpose of finding an exit to anywhere.
Not when creating exits to specific hosts. Generic exits are defined
in the [exit] label of gnunet.conf and do not provide a way to
specify some shared secret string that a vpn "client" node could
use to find just that specific exit, right?

> > 2. How to implement access control for default-route exits and
> > services? Other (IP-based) overlays allow using the usual netfilter
> > and hosts_access mechanisms, while (obviously) this is not possible
> > for gnunet-exit... So what if I want to offer a gateway to the ARPA
> > internet or a specific local service only to my friends (and maybe
> > or maybe not: their friends as well...)
> You can restrict the EXIT by IP address. Also, you can use exit to offer
> access to only very specific services. In that case, the services get a
> name and you create a VPN service record in GNS. If you do that, you can

"GNS" in this case means you use the gnunet-namestore feature to map
a <host>.gnu name to a VPN exit on a specific peerid, like this:

        gnunet-namestore -z master-zone -t vpn -ap -e "2 hours"
                 -n <host> -V "6 <peerid> <sharedsecret>"

The meaning of 6 is a bit cryptic. It comes from netinet/in.h:
        IPPROTO_TCP = 6,     /* Transmission Control Protocol.  */

"master-zone" is the name you gave to your own local peer zone, the script uses this name by default. Further details,
see man page.

What's important to note here is that, if I understood correctly, this 
name.gnu mapping takes effect locally and it doesn't actually matter 
if it is published to GNS in the network - so in a way we are not 
*really* using GNS here, just the OS integration on the localhost.

> use a passphrase as the label and thereby restrict who can access the
> service.  What you cannot do right now is offer an exit that isn't to a
> specific address and then restrict that to friends.

In order for gnunet-vpn to actually find a service on the remote peer,
that peer needs to have such a service configured. In gnunet.conf,
like this:

TCP_REDIRECTS = 80:;4404:

"" is the magic IP number that gnunet-exit allocates
by default for incoming localhost vpn traffic. I think this number
should not appear in gnunet.conf, but currently you have to put
it in there for each port number you want to export to your vpn
"clients". The syntax is <vpn-port>:<target-ip>:<target-port> -
so you should also be able to say "" but the
feature Dan was asking for would be something like "80:"
which I presume isn't implemented. This is all in IP4 thinking,
but I bet you can have this all also in IPv6. Oh, and don't ask
why it has to be ".gnunet." in the name, I have no clue.

By the way, bureaucracy isn't complete if you haven't allowed
the IP numbers you specified in your ".gnunet." also in a more
generic setting here:


To me this appears redundant but it all has its logic.

> The feature-set is admittedly still a bit, eh, limited ;-).

CG fixed this vpn/exit/namestore feature this summer and for a
few days it worked wonderfully. I hope it still does. Also, I
have been playing around with gnunet-fs ever since around 2014.
It works. GNUnet should make a release at least of those parts
that do work, no?

  E-mail is public! Talk to me in private using encryption:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]