Differences between revisions 3 and 5 (spanning 2 versions)
Revision 3 as of 2007-02-05 14:58:08
Size: 3438
Comment:
Revision 5 as of 2007-02-05 15:06:57
Size: 3743
Comment: keep address allocations here
Deletions are marked like this. Additions are marked like this.
Line 34: Line 34:
}} }}}
Line 76: Line 76:
== Address Allocation ==

=== Servers ===

|| Server || 10.11.255.? || Port || Proto || Compression || Dev ||
|| donk.personaltelco.net || 1 || 1195/udp || OpenVPN || lzo || tap0 ||

=== Clients ===

|| Client || Tunnel To || 10.11.255.? ||
|| NodeLuckyLab || donk.personaltelco.net || 5 ||

Personal Telco VPN

This is a page to tie together any and all information about a ["VPN"] which exists within ["PTPnet"]. At some point in the DistantFuture, JimmySchmierbach worked on a proposal (with assistance from KeeganQuinn) to build VPN connections between some (if not all) nodes. There are a few motivations to do this:

  • Maintenance - some nodes are behind NAT and we can't get to them otherwise. One current example is NodeLuckyLab.

  • Fake Internode Links - ideally, all of our nodes would be connected wirelessly into one big ["PTPnet"] cloud. However, at present, this is not the case. To give the 'feeling' of interconnectedness in spite of the lack of real connectedness, we can build tunnels between nodes accross the internet. It should be noted that some people seem to think that this isn't a good motivation - it is just a result of us becoming complacent and lazy about our idealistic goals.

Here are the places on this wiki where there is currently information on VPNs:

Goals

The goal is to scrape the cruft off the partially implemented VPN, build something new and functional according to Jimmy's ideas, and then document it here so that it can be maintained/learned-from with ease. After some brainstormin between myself, DonPark, and RussellSenior, the consensus is to start with NodesBehindNat using maintainance as a motivator, and then, if we have extra time and energy, to work on interconnecting other nodes.

Methodology

At least for now, we will use 1 server and several clients. At some point, it will make more sense to use the more scalable organization suggested by Jimmy, where most nodes connect to maybe three other nodes (cornerstone, bone, and alithea, historically), and then those nodes connect once more upstream to the supernode (donk) to create a sort of 2-hop hierarchy.

Configuration

To make a new client key do something like this:

ssh you@donk
cd /usr/share/doc/openvpn/examples/easy-rsa
sudo ./build-key thenode
sudo cp thenode.key thenode.crt /etc/openvpn/keys/

Then, do the configuration on the server side - add a file in /etc/openvpn/ccd with a name like thenode.personaltelco.net. The contents should be something like (replacing 10.11.255.X with an unused IP within 10.11.255.0/24 from the NetworkAddressAllocations page):

ifconfig-push 10.11.255.X 255.255.255.0

Finally, you must configure the client. Do something like:

ssh you@thenode
sudo apt-get update
sudo apt-get install openvpn
cd /etc/openvpn
sudo scp you@donk:/etc/openvpn/keys/thenode.* .
sudo scp you@donk:/etc/openvpn/keys/ca.crt .

Create the clients configuration file at /etc/openvpn/client.conf

client
remote donk.personaltelco.net 1195
proto udp
dev tap
ca /etc/openvpn/ca.crt
cert /etc/openvpn/thenode.crt
key /etc/openvpn/thenode.key
comp-lzo

And finally, start openvpn on the client-side:

/etc/init.d/openvpn restart

Now, you should be able to goto 10.11.255.1 from the client and get to donk, or 10.11.255.X (where X is whatever you assigned it) on donk to get to the client.

Address Allocation

Servers

Server

10.11.255.?

Port

Proto

Compression

Dev

donk.personaltelco.net

1

1195/udp

OpenVPN

lzo

tap0

Clients

Client

Tunnel To

10.11.255.?

NodeLuckyLab

donk.personaltelco.net

5

References

PersonalTelcoVPN (last edited 2009-10-01 11:54:05 by JasonMcArthur)