`
18 |
19 | ---
20 |
21 | ### Peer Efficiently
22 |
23 | Murphy's Law applies to cjdns routing: if a packet can take a weird or inefficient route, it probably will. When you choose bad peers, it degrades the quality of the entire network. When you are peering over the internet, you should be peering with those who are in relative geographical proximity to you.
24 |
25 | You should only be peering with people whom you (moderately) trust. Peering with total strangers ruins the friend-of-a-friend nature of the network.
26 |
27 | ---
28 |
29 | ### Keep Peering Credentials Safe
30 |
31 | On the same lines as peering efficiently, be careful that nobody steals your peering credentials.
32 |
33 | The passwords should not be passwords, they should be long strings of gibberish that are practically impossible for an attacker to guess. To generate a strong password, you can run this bash command:
34 |
35 | ```
36 | $ cat /dev/urandom | strings | head -n 20 | tr -d '\n"`\ \t{}' | head -c 40 && echo
37 |
38 | ```
39 |
40 | DO NOT transfer peering credentials over any sort of plaintext medium, such as IRC or unencrypted email. It's probably also a good idea to use a service like [EZCrypt](https://ezcrypt.it) (also available [on Hyperboria](http://cjdns.ezcrypt.it)) or send your peering details via encrypted email with PGP.
41 |
42 | ---
43 |
44 | ### Get on IRC!
45 |
46 | As a service provider, you need to be available in case someone needs you.
47 |
--------------------------------------------------------------------------------
/cjdns/nodeinfo-json.md:
--------------------------------------------------------------------------------
1 | # nodeinfo.json
2 |
3 | *A way for nodes to provide info about themselves and improve discoverability.*
4 |
5 | This is an evolving standard, we've generally agreed on this format, but we'll
6 | see what people do with it.
7 |
8 | A JSON file at `/nodeinfo.json` that looks something like below. Parsers should
9 | have no expecations about this file, in my tests found several 404 or other
10 | non-JSON pages at that path returning HTTP 200. Further, all keys are optional.
11 | Additional fields can me made up by other node operators. This spec
12 | will change as we see how people use it. Please provide at least a contact
13 | email, and ideally a PGP fingerprint with the full key on public keyservers.
14 |
15 | Sample Files:
16 | * http://[fcef:96c2:7226:a4b1:97ea:59bf:cb2e:51f0]/nodeinfo.json
17 | * http://[fcec:ae97:8902:d810:6c92:ec67:efb2:3ec5]/nodeinfo.json
18 |
19 |
20 | ```json
21 | {
22 | "key": "cjdnspublickey.k",
23 | "hostname": "your.nodes.fqdn",
24 | "contact": {
25 | "name": "Your name, handle, nick, whatever",
26 | "email": "you@domain.tld",
27 | "xmpp": "you@domain.tld",
28 | "other cool communication service": "whatever identifier they use"
29 | },
30 | "last_modified": "2014-11-30T00:35:48+00:00",
31 | "pgp": {
32 | "fingerprint": "FULL40CHARFINGERPRINT",
33 | "full": "http://link.to.download/full.key",
34 | "keyserver": "hkp://pgp.mit.edu"
35 | },
36 | "services": [
37 | {
38 | "uri": "http://[fc00:]/",
39 | "name": "My awesome http website",
40 | "description": "my blag and stuff"
41 | },
42 | {
43 | "uris": {
44 | "webInterface" :"http://example.tld/",
45 | "otherthing": "cactus://example.tld/"
46 | },
47 | "name": "MutliURI service",
48 | "description": "Some service with multiple URIs"
49 | }
50 | ],
51 | "location":{
52 | "longitude":0,
53 | "latitude":0,
54 | "altitude":0,
55 | "continent":"NA",
56 | "region":"Cascadia",
57 | "municipality":"Seattle",
58 | "uri":"https://www.seattlemesh.net/"
59 | }
60 | }
61 | ```
62 |
63 | ## Regarding continent codes
64 |
65 | ```
66 | Asia : AS
67 | South America: SA
68 | North America: NA
69 | Africa: AF
70 | Europe: EU
71 | Antarctica: AN
72 | Oceania: OC
73 | ```
74 |
--------------------------------------------------------------------------------
/bugs/distro-quirks.md:
--------------------------------------------------------------------------------
1 | # OS/distribution-specific quirks
2 |
3 | ## OSX
4 |
5 | ### Failure to autopeer
6 |
7 | ```IRC
8 | 16:46 < ansuz> sounds like you guys are in srs mode, but that mac no-auto-peering thing only really has one line of documentation
9 | 16:46 < ansuz> at some point if someone could fill me in on the why, it would get more
10 | 16:47 <@cjd> ahh, it's because generating ethernet frames is different per operating system
11 | 16:47 <@cjd> there's no standardized socket(SO_LINK_LAYER, "eth0")
12 | 16:48 <@cjd> so ETHInterface_darwin.c just isn't written
13 | 16:49 <@cjd> now you can copy/paste that into a little txt file and when some poor bastard asks why, tell him and then shout at him to update the documentation
14 | 16:49 <@cjd> and if he doesn't, shitlist him so no more questions \:D/
15 | 16:49 <@Arceliar> or bug people who own a mac to write ETHInterface_darwin.c
16 | ```
17 |
18 | There you have it, Macs don't autopeer via ethernet frames.
19 |
20 | This is also probably why it doesn't work on windows, either.
21 |
22 | ## Raspbian
23 |
24 | ### Failure to start Cjdns
25 | When running Cjdns on Raspberry Pi with Raspbian you can run in to problems because IPv6 is not enabled by default. This causes Cjdns to fail on startup with the following error message:
26 |
27 | ```
28 | CRITICAL Configurator.c:107 Got error [UDPAddrIface.c:273 call to uv_udp_bind() failed [bad file descriptor]] calling [UDPInterface_new]
29 | ```
30 |
31 | Enable IPv6 with
32 |
33 | ```bash
34 | $ sudo modprobe ipv6
35 | ```
36 |
37 | and Cjdns should start correctly. To keep IPv6 on after reboot add `ipv6` to the end of the file `/etc/modules`
38 |
39 | ```bash
40 | $ sudo sh -c 'echo ipv6 >> /etc/modules'
41 | ```
42 |
43 | ## Windows
44 |
45 | ### Not resolving DNS correctly
46 |
47 | Windows is having problems with resolving CNAME records referencing AAAA only records.
48 |
49 | The fix is easy, you have to lie to windows saying that you have an existing IPv6 connection under your main network card.
50 |
51 | To do so enter your main network card contex menu, select `Properties` and enter IPv6 configuration.
52 | Select manual configuration and type `::1` as your IPv6 address, DNS fields can be empty as you don't have a IPv6 communication after all.
53 | Click OK and after that CNAME records will be resolved correctly.
54 |
55 |
--------------------------------------------------------------------------------
/notes/gsoc.md:
--------------------------------------------------------------------------------
1 | ## cjdns google summer of code
2 |
3 | [Google Summer of Code](https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2015/help_page) has several goals:
4 |
5 | 1. Create and release open source code for the benefit of all
6 | 2. Inspire young developers to begin participating in open source development
7 | 3. Help open source projects identify and bring in new developers and committers
8 | 4. Provide students the opportunity to do work related to their academic pursuits (think "flip bits, not burgers")
9 | 5. Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette)
10 |
11 | ## Our goals
12 |
13 | 1. Get funding! Fixing cjdns is hard work, and it takes a lot of time. A precedent of funding from google might make it easier to pick up funding from other sources.
14 | 2. Get attention! People pay attention to projects that google funds. We need more eyes.
15 | 3. Structure! Hard deadlines get people moving. We'll get more done as a well-defined organization.
16 | 4. A working product... an android app? Something to improve the core routing algorithm? Debugging/visualization/simulation tools? Userland config management?
17 |
18 | ## Ideas
19 |
20 | ### cjdns on the Freifunk backbone (BBB) and network (IC-VPN)
21 |
22 | The Berlin BackBone (BBB) is a network of dedicated wifi links between several sites at public buildings like churches or townhalls. It is the backbone of Freifunk Berlin's network, which other nodes in the neighbourhoods connect to. The InterCity VPN (IC-VPN) connects the Berlin network with the networks of other Freifunk communities, e.g. in Leipzig and Hamburg.
23 |
24 | The goal is to:
25 |
26 | - tunnel Internet traffic from the neighbourhood to the Freifunk <-> Internet exchanges
27 | - link cjdns islands in the community
28 | - automate the tunnel setup on leaf nodes
29 |
30 | TODO: need to think about how remote-friendly this idea is
31 |
32 | ### Continuous simulations and benchmarks of cjdns
33 |
34 | - [HACKING.md#simulating](https://github.com/cjdelisle/cjdns/blob/master/HACKING.md#simulating)
35 | - [cjdns-testbed](https://github.com/lgierth/cjdns-testbed)
36 |
37 | ### DNS
38 |
39 | See [DNS, with trust based on peering-like agreements](dns.md#dns-with-trust-based-on-peering-like-agreements)
40 |
--------------------------------------------------------------------------------
/meshlocals/intro.md:
--------------------------------------------------------------------------------
1 | # Mesh Local Intro
2 |
3 | ## What is a Mesh Local?
4 |
5 | A 'Mesh Local' is a mesh network situated in a particular geographic locale, focused on providing a community-centric alternative (or complement) to the internet.
6 |
7 | ## How local is local?
8 |
9 | Project Meshnet's mesh networking protocol (cjdns) was designed to be agnostic of the medium over which it communicates. That means that even if the closest node is beyond the functional range of radio signals, you can still peer with it over the internet.
10 |
11 | While this is useful for connecting with others who are interested, and for forming a seed from which a local network can grow, it relies on another network to exist. The ultimate goal is to create a net which will not fail if the internet does.
12 |
13 |
14 | graph LR;
15 | A(Local node)--\>|wireless lan cable|B(Other local node);
16 | B--\>A;
17 |
18 |
19 | **NOTE**: If you're viewing this on a web page which does not include [mermaid.js](https://github.com/knsv/mermaid), you'll just see some weird text. For an example of how it **should** look, see it in [its original context](https://docs.meshwith.me/en/meshlocals/intro.html).
20 |
21 | ## What if physical peering is out of the question?
22 |
23 | If you're located somewhere extremely remote, you don't have to count yourself out of the picture. Try to gather some resources for a meshlocal anyway, as you might be pleasantly surprised to find someone nearby despite what you may have thought. That means letting people know that you're working on it (at least for yourself).
24 |
25 | Read as much documentation as you can, and familiarize yourself with the software so that if someone does contact you, you have some knowledge to share. If you find any documentation that's unclear or misleading, get in touch with us and help to [write the fine manual](http://roaming-initiative.com/blog/posts/wtfm).
26 |
27 | Finally, ask around for someone willing to peer with you despite the distance, but be patient. As time goes by and you find closer peers, disable the connections to those who are further away.
28 |
29 | ## About Wifi tuning
30 |
31 | Antenna directionality, Signal to Noise ratio, beamforming: http://apenwarr.ca/log/?m=201408#01
32 |
33 | A guide to tuning your wifi for adverse conditions: http://kmkeen.com/linux-wifi/
34 |
--------------------------------------------------------------------------------
/proxying.md:
--------------------------------------------------------------------------------
1 | Proxying
2 | ===========================
3 |
4 | #Keep in mind that we'd rather you put cjdns on all your machines!
5 |
6 | Sometimes it's just not possible to get cjdns working on a machine.
7 |
8 | The easiest way to access Hyperboria if you can't get access on your machine is through a box that already has access.
9 | This can be simply done using a SSH connection.
10 |
11 | Creating SOCKSv5 connection
12 | ----------------------------
13 |
14 | To create SOCKS SSH connection in Linux/OSX:
15 |
16 | ```bash
17 | ssh -f -N -D 8080 [your_cjdns_capable_host]
18 | ```
19 | This will connect to host under `[your_cjdns_capable_host]`.
20 |
21 | This can be also achieved in PuTTY by creating a dynamic tunnel on port `8080`.
22 |
23 | (The port `8080` can be any different port but you will have to edit PAC later to make it work)
24 |
25 | Configuring your Web Browser
26 | ----------------------------
27 |
28 | If proxying all of your traffic through the server is acceptable to you, then just select SOCKS5 proxy
29 | and put `localhost` as hostname and `8080` as port.
30 |
31 | If you want your normal traffic to travel directly and only cjdns traffic to connect though the proxy,
32 | you have to use Proxy auto-config (PAC).
33 |
34 | The following PAC file checks if the host you are connecting to is a cjdns IPV6 address, if not tries to resolve it. (If that fails, it usually means current DNS server is not IPv6 capable, so it redirects the traffic through the proxy)Finally, if resolving via DNS is successful (and the current host is IPv6 capable) it checks whether the address is in cjdns space.
35 |
36 | ```js
37 | function FindProxyForURL(url, host) {
38 | // If we can't resolve this means that this host is IPv4 only. Trying cjdns won't hurt.
39 | // It also make IPv4 only hosts connect ot clearnet IPv6 hosts if proxy is IPv6 capable.
40 | // If we can resolve check if the host is insice cjdns network space.
41 | if (shExpMatch(host, "fc*:*") || !dnsResolve(host) || shExpMatch(dnsResolve(host), "fc*:*")) {
42 | return "SOCKS5 localhost:8080";
43 | }
44 | return "DIRECT";
45 | }
46 | ```
47 | Also available as a file in this repo: [cjdns.pac](/cjdns.pac)
48 |
49 | This PAC file uses SOCKS5 connection with proxy server on `localhost` at port `8080`.
50 | If you'd like to use a different port, you have to change it accordingly.
51 |
52 | Use this PAC file for `Automatic Proxy Configuration` option which is available in most browsers and other proxy management solutions.
53 |
--------------------------------------------------------------------------------
/config/proxying.md:
--------------------------------------------------------------------------------
1 | Proxying
2 | ===========================
3 |
4 | #Keep in mind that we'd rather you put cjdns on all your machines!
5 |
6 | Sometimes it's just not possible to get cjdns working on a machine.
7 |
8 | The easiest way to access Hyperboria if you can't get access on your machine is through a box that already has access.
9 | This can be simply done using a SSH connection.
10 |
11 | Creating SOCKSv5 connection
12 | ----------------------------
13 |
14 | To create SOCKS SSH connection in Linux/OSX:
15 |
16 | ```bash
17 | ssh -f -N -D 8080 [your_cjdns_capable_host]
18 | ```
19 | This will connect to host under `[your_cjdns_capable_host]`.
20 |
21 | This can be also achieved in PuTTY by creating a dynamic tunnel on port `8080`.
22 |
23 | (The port `8080` can be any different port but you will have to edit PAC later to make it work)
24 |
25 | Configuring your Web Browser
26 | ----------------------------
27 |
28 | If proxying all of your traffic through the server is acceptable to you, then just select SOCKS5 proxy
29 | and put `localhost` as hostname and `8080` as port.
30 |
31 | If you want your normal traffic to travel directly and only cjdns traffic to connect though the proxy,
32 | you have to use Proxy auto-config (PAC).
33 |
34 | The following PAC file checks if the host you are connecting to is a cjdns IPV6 address, if not tries to resolve it. (If that fails, it usually means current DNS server is not IPv6 capable, so it redirects the traffic through the proxy). Finally, if resolving via DNS is successful (and the current host is IPv6 capable) it checks whether the address is in cjdns space.
35 |
36 | ```js
37 | function FindProxyForURL(url, host) {
38 | // If we can't resolve this means that this host is IPv4 only. Trying cjdns won't hurt.
39 | // It also make IPv4 only hosts connect ot clearnet IPv6 hosts if proxy is IPv6 capable.
40 | // If we can resolve check if the host is insice cjdns network space.
41 | if (shExpMatch(host, "fc*:*") || !dnsResolve(host) || shExpMatch(dnsResolve(host), "fc*:*")) {
42 | return "SOCKS5 localhost:8080";
43 | }
44 | return "DIRECT";
45 | }
46 | ```
47 | Also available as a file in this repo: [cjdns.pac](/cjdns.pac)
48 |
49 | This PAC file uses SOCKS5 connection with proxy server on `localhost` at port `8080`.
50 | If you'd like to use a different port, you have to change it accordingly.
51 |
52 | Use this PAC file for `Automatic Proxy Configuration` option which is available in most browsers and other proxy management solutions.
53 |
--------------------------------------------------------------------------------
/intro.md:
--------------------------------------------------------------------------------
1 | # What the fc00::/8
2 | ## a brief introduction to cjdns
3 |
4 | author: [kpcyrd](https://github.com/kpcyrd)
5 |
6 | original location: https://github/ansuz/cjdns-pr
7 |
8 | ```quote
9 | We have the means and we have the technology to end mass surveillance without any legislative action at all, without any policy changes. By basically adopting changes like making encryption a universal standard - where all communications are encrypted by default - we can end mass surveillance not just in the United States but around the world.
10 | - Edward Snowden
11 | ```
12 |
13 | ## The current internet
14 |
15 | - Addresses get spoofed
16 | - Services get censored
17 | - Networks get hijacked
18 | - Controlled by evil corps
19 | - **Everybody can read yo packets**
20 |
21 | ## Where we're going
22 |
23 | - Encrypts all your packets
24 | - Almost zeroconf
25 | - No authorities like IANA
26 | - Clean IPv6 networking interface
27 | - Enough addresses for everybody
28 |
29 | ## Sounds complicated
30 |
31 | 1. Install cjdns
32 | 2. Find a friend to connect to
33 |
34 | ## Friend to Friend
35 |
36 | - Nobody knows who's behind an address since there's no registry
37 | - Your friends know, though
38 | - In case of abuse your friends may stop peering with you
39 |
40 | ## Peering (The simple way)
41 |
42 | 1. Get a friend who's connected
43 | 2. Get a cable
44 | 3. Connect the cable to each computer
45 | 4. Enable autopeering
46 | 5. Connection established
47 |
48 | ## Peering (Over the internet)
49 |
50 | 1. Configure an IP address on both sides
51 | 2. Ensure one is able to connect to the other
52 | 3. Exchange peering credentials over a secure channel
53 | 4. Encrypted traffic will be encapsulated in UDP packets
54 |
55 | ## How is it secure?
56 |
57 | There's no central trust authority.
58 |
59 | **fc42:18f1:763b:9b70:0059:9896:ef20:6de7**
60 |
61 | All those random letters are used to verify your identity.
62 |
63 | The address is the cryptographical fingerprint.
64 |
65 | ## ICANN hax it
66 |
67 | - Don't use DNS to distribute your IPv6
68 | - DNS can be hijacked
69 | - Thus, cjdns addresses can get spoofed
70 |
71 | If we use the current domain name system it's not very secure
72 |
73 | ## Namecoin to the rescue
74 |
75 | - Fully decentralized
76 | - Stores all addresses in an uncensorable blockchain
77 | - Cryptographically ensures authenticity
78 |
79 | ## Next steps
80 |
81 | - Android devs - Help going mobile
82 | - Peers - Help the networks health
83 | - Services - Help providing more useful stuff
84 | - Windows devs - Help the lost souls
85 |
86 | All skill levels wanted
87 |
--------------------------------------------------------------------------------
/install/build-on-windows.md:
--------------------------------------------------------------------------------
1 | CultureSpy worked out how to compile cjdns for Windows for Windows. So if you happen to use this broken ass OS and want to use cjdns....
2 |
3 | # Building cjdns On Windows For Windows
4 |
5 | Install Cygwin from [here](https://cygwin.com/install.html)
6 |
7 | Extra packages to install, if they're not installed by default:
8 |
9 | ```
10 | gcc-core
11 | gcc-g++
12 | libltdl7
13 | mingw-binutils
14 | mingw-gcc-core
15 | mingw-pthreads
16 | mingw-w32api
17 | mingw64-i686-binutils
18 | ming64-i686-gcc
19 | ming64-i686-gcc-core
20 | ming64-i686-gcc-g++
21 | ming64-i686-headers
22 | ming64-i686-pthreads
23 | ming64-i686-runtime
24 | ming64-i686-windows-default-manifest
25 | ming64-i686-winpthreads
26 | python
27 | w32api-headers
28 | w32api-runtime
29 | windows-default-manifest
30 | make
31 | ```
32 |
33 | [Install node.js](https://nodejs.org/download/)
34 |
35 | Get the [cjdns source](https://github.com/cjdelisle/cjdns)
36 |
37 | Create `C:\tmp`
38 |
39 | Start a cygwin session and update your environment for mingw compilation:
40 |
41 | ```
42 | export CC=i686-w64-mingw32-gcc
43 | export CXX=i686-w64-mingw32-g++
44 | ```
45 |
46 | Make a small edit to the cjdns JS build system:
47 |
48 | ```
49 | --- a/node_build/make.js
50 | +++ b/node_build/make.js
51 | @@ -43,7 +43,7 @@ Builder.configure({
52 | systemName: SYSTEM,
53 | crossCompiling: process.env['CROSS'] !== undefined,
54 | gcc: GCC,
55 | - tempDir: '/tmp',
56 | + tempDir: 'C:\\tmp',
57 | optimizeLevel: '-O2',
58 | logLevel: process.env['Log_LEVEL'] || 'DEBUG'
59 | }, function (builder, waitFor) {
60 | ```
61 |
62 | (that is, replace the line that says `tempDir: '/tmp'` with `tempDir: 'C:\\tmp'`)
63 |
64 | This works around an issue with the detection of the tmp directory.
65 |
66 | Also, make sure libuv will build:
67 |
68 | `cp node_build/dependencies/libuv/Makefile.mingw node_build/dependencies/libuv/Makefile`
69 |
70 | Edit `node_build/dependencies/libuv/Makefile` so that it will use the mingw gcc instead of the cygwin gcc:
71 |
72 | ```
73 | 15c15
74 | < CC = gcc
75 | ---
76 | > #CC = gcc
77 | ```
78 |
79 | (That is, comment out the line that sets the CC variable.)
80 |
81 | Then run `./do` to build
82 |
83 | The system churns for a while, hopefully producing no errors. It will eventually tell you it's time to run `cjdroute`. It lies.
84 |
85 | `cp build_win32/admin_angel_cjdroute2_c.exe cjdroute.exe`
86 |
87 | Or put cjdroute.exe wherever you like.
88 |
89 | Continue following [instructions here](windows.md#run-time-dependencies)
90 |
91 | And obviously [secure your shit](../config/windows-firewall.md)
92 |
--------------------------------------------------------------------------------
/notes/build-on-windows.md:
--------------------------------------------------------------------------------
1 | CultureSpy worked out how to compile cjdns for Windows for Windows. So if you happen to use this broken ass OS and want to use cjdns....
2 |
3 | # Building cjdns On Windows For Windows
4 |
5 |
6 | Install Cygwin from [here](https://cygwin.com/install.html)
7 |
8 | Extra packages to install, if they're not installed by default:
9 |
10 | ```
11 | gcc-core
12 | gcc-g++
13 | libltdl7
14 | mingw-binutils
15 | mingw-gcc-core
16 | mingw-pthreads
17 | mingw-w32api
18 | mingw64-i686-binutils
19 | ming64-i686-gcc
20 | ming64-i686-gcc-core
21 | ming64-i686-gcc-g++
22 | ming64-i686-headers
23 | ming64-i686-pthreads
24 | ming64-i686-runtime
25 | ming64-i686-windows-default-manifest
26 | ming64-i686-winpthreads
27 | python
28 | w32api-headers
29 | w32api-runtime
30 | windows-default-manifest
31 | make
32 | ```
33 |
34 | [Install node.js](http://nodejs.org/download/)
35 |
36 |
37 | Get the [cjdns source](https://github.com/cjdelisle/cjdns)
38 |
39 |
40 | Create `C:\tmp`
41 |
42 | Start a cygwin session and update your environment for mingw compilation:
43 |
44 | ```
45 | export CC=i686-w64-mingw32-gcc
46 | export CXX=i686-w64-mingw32-g++
47 | ```
48 |
49 | Make a small edit to the cjdns JS build system:
50 |
51 | ```
52 | --- a/node_build/make.js
53 | +++ b/node_build/make.js
54 | @@ -43,7 +43,7 @@ Builder.configure({
55 | systemName: SYSTEM,
56 | crossCompiling: process.env['CROSS'] !== undefined,
57 | gcc: GCC,
58 | - tempDir: '/tmp',
59 | + tempDir: 'C:\\tmp',
60 | optimizeLevel: '-O2',
61 | logLevel: process.env['Log_LEVEL'] || 'DEBUG'
62 | }, function (builder, waitFor) {
63 | ```
64 | (that is, replace the line that says `tempDir: '/tmp'` with `tempDir: 'C:\\tmp'`)
65 |
66 | This works around an issue with the detection of the tmp directory.
67 |
68 | Also, make sure libuv will build:
69 |
70 | `cp node_build/dependencies/libuv/Makefile.mingw node_build/dependencies/libuv/Makefile`
71 |
72 | Edit `node_build/dependencies/libuv/Makefile` so that it will use the mingw gcc instead of the cygwin gcc:
73 |
74 | ```
75 | 15c15
76 | < CC = gcc
77 | ---
78 | > #CC = gcc
79 | ```
80 |
81 | (That is, comment out the line that sets the CC variable.)
82 |
83 | Then run `./do` to build
84 |
85 | The system churns for a while, hopefully producing no errors. It will eventually tell you it's time to run `cjdroute`. It lies.
86 |
87 | `cp build_win32/admin_angel_cjdroute2_c.exe cjdroute.exe`
88 |
89 | Or put cjdroute.exe wherever you like.
90 |
91 | Continue following [instructions here](../windows.md#run-time-dependencies)
92 |
93 | And obviously [secure your shit](windows-firewall.md)
94 |
--------------------------------------------------------------------------------
/security_specification.md:
--------------------------------------------------------------------------------
1 | #Security Specification
2 |
3 | This document is here to help define security flaws in a way that can be agreed upon.
4 |
5 | ##Definitions
6 |
7 | * Reveal: To reveal a piece of content is to send over the wire that content or something from which
8 | that content can be mathematically derived (not withstanding theoretical attacks
9 | eg: Quantum Computers unless explicitly said otherwise)
10 |
11 | * Matching Keypair: In relation to an IPv6 address, a public and private key for which the first
12 | 16 bytes of the double-SHA-512 (the SHA-512 of the SHA-512) of the public key matches the IPv6
13 | address.
14 |
15 | * Permanent Private Key: The key which is in the configuration file which defines the node's
16 | identity.
17 |
18 | ##Limitation of Scope
19 |
20 | This document applies to the current version (latest master branch) of cjdns compiled and running
21 | on a Linux system using a version of GCC with no known security issues and running on an
22 | x86 or amd64 processor. Older versions and git branches may be non-compliant with this
23 | specification.
24 |
25 | ##Integrity and Confidentiality
26 |
27 | 1. It must not be possible to reveal the permanent private key or any temporary session private keys
28 | to anyone.
29 |
30 | 2. It must not be possible to reveal any temporary symmetrical session keys to anyone other than the
31 | identity (permanent public key) with which the session has been established.
32 |
33 | 3. It must not be possible to reveal the content of any packet with an fc00::/8 destination address
34 | which enters cjdns through the TUN device, except revealing it to the holder(s) of the Matching
35 | Keypair for that address.
36 |
37 | 4. It must not be possible to receive any packet with an fc00::/8 source address unless the sender
38 | is in possession of the Matching Keypair for that address and the content (not including fields in
39 | the IPv6 header other than source and destination addresses) has not been altered en-route.
40 |
41 | 5. It must not be possible to receive a packet which is part of an ESTABLISHED session of that
42 | packet was already received before.
43 |
44 | 6. If the permanent private key is compromised, any traffic which was sent during a previous
45 | ESTABLISHED session which has since ended will not be compromised as a result.
46 |
47 | NOTE: Traffic may also be sent when a session is in HANDSHAKE state and for traffic sent while the
48 | session is in HANDSHAKE state, 5 and 6 may be violated.
49 |
50 | 7. In the event of a cryptographic break of Curve25519 ECDH (for example using the Shor attack with
51 | a Quantum Computer) any cryptographic session which was initiated using a password will remain
52 | as strong as a session which had been initiated using that password as a symmetrical key.
53 |
54 |
55 |
--------------------------------------------------------------------------------
/security-specifications.md:
--------------------------------------------------------------------------------
1 | #Security Specification
2 |
3 | This document is here to help define security flaws in a way that can be agreed upon.
4 |
5 | ##Definitions
6 |
7 | * Reveal: To reveal a piece of content is to send over the wire that content or something from which
8 | that content can be mathematically derived (not withstanding theoretical attacks
9 | eg: Quantum Computers unless explicitly said otherwise)
10 |
11 | * Matching Keypair: In relation to an IPv6 address, a public and private key for which the first
12 | 16 bytes of the double-SHA-512 (the SHA-512 of the SHA-512) of the public key matches the IPv6
13 | address.
14 |
15 | * Permanent Private Key: The key which is in the configuration file which defines the node's
16 | identity.
17 |
18 | ##Limitation of Scope
19 |
20 | This document applies to the current version (latest master branch) of cjdns compiled and running
21 | on a Linux system using a version of GCC with no known security issues and running on an
22 | x86 or amd64 processor. Older versions and git branches may be non-compliant with this
23 | specification.
24 |
25 | ##Integrity and Confidentiality
26 |
27 | 1. It must not be possible to reveal the permanent private key or any temporary session private keys
28 | to anyone.
29 |
30 | 2. It must not be possible to reveal any temporary symmetrical session keys to anyone other than the
31 | identity (permanent public key) with which the session has been established.
32 |
33 | 3. It must not be possible to reveal the content of any packet with an fc00::/8 destination address
34 | which enters cjdns through the TUN device, except revealing it to the holder(s) of the Matching
35 | Keypair for that address.
36 |
37 | 4. It must not be possible to receive any packet with an fc00::/8 source address unless the sender
38 | is in possession of the Matching Keypair for that address and the content (not including fields in
39 | the IPv6 header other than source and destination addresses) has not been altered en-route.
40 |
41 | 5. It must not be possible to receive a packet which is part of an ESTABLISHED session of that
42 | packet was already received before.
43 |
44 | 6. If the permanent private key is compromised, any traffic which was sent during a previous
45 | ESTABLISHED session which has since ended will not be compromised as a result.
46 |
47 | NOTE: Traffic may also be sent when a session is in HANDSHAKE state and for traffic sent while the
48 | session is in HANDSHAKE state, 5 and 6 may be violated.
49 |
50 | 7. In the event of a cryptographic break of Curve25519 ECDH (for example using the Shor attack with
51 | a Quantum Computer) any cryptographic session which was initiated using a password will remain
52 | as strong as a session which had been initiated using that password as a symmetrical key.
53 |
54 |
55 |
--------------------------------------------------------------------------------
/bugs/configurator-timeout.md:
--------------------------------------------------------------------------------
1 | # Configurator.c: Timed out waiting for a response
2 |
3 | In some scenario cjdns could fail at starting up with the following cryptic
4 | messages:
5 |
6 | ```
7 | 1428440513 DEBUG AdminClient.c:333 Connecting to [127.0.0.1:11234]
8 | 1428440513 DEBUG UDPAddrIface.c:294 Bound to address [0.0.0.0:58063]
9 | 1428440518 CRITICAL Configurator.c:96 Failed to make function call [Timed out waiting for a response], error: [ping]
10 | 1428440518 CRITICAL Configurator.c:56 enable Log_LEVEL=KEYS to see message content.
11 | 1428440523 CRITICAL Configurator.c:68 Failed to stop the core.
12 | 1428440523 CRITICAL Configurator.c:70 Aborting.
13 | ```
14 |
15 | ## Cause
16 |
17 | cjdns is configured via the admin interface, listening by default on
18 | `localhost`, port `11234`.
19 |
20 | However, there are some machine configurations where the firewall has a default
21 | policy different from ACCEPT for the INPUT chain and there's an exception for
22 | loopback interface missing. Checking with `iptables -t filter -L` (as root)
23 | should output something like:
24 |
25 | ```
26 | Chain INPUT (policy ACCEPT)
27 | target prot opt source destination
28 |
29 | Chain FORWARD (policy ACCEPT)
30 | target prot opt source destination
31 |
32 | Chain OUTPUT (policy ACCEPT)
33 | target prot opt source destination
34 | ```
35 |
36 | The above output is the default configuration of the firewall, with everything
37 | allowed, your own could be configured in many different ways. However, you have
38 | to check your INPUT chain policy, if it's REJECT or DROP that could be causing
39 | the problem above.
40 |
41 | ## Solution
42 |
43 | There are a couple of solutions to this issue.
44 |
45 | ### ACCEPT everything on INPUT
46 |
47 | Piece of cake: just run `iptables -t filter -P INPUT ACCEPT`.
48 |
49 | ### Add an exception for loopback traffic
50 |
51 | This solution is more complex, but allows you to retain your full firewall
52 | functionality while allowing cjdns at the same time.
53 | You have to allow both inbound and outbound traffic on the loopback interface,
54 | usually named `lo`. That name is the one which is going to be used in the
55 | following code snippet.
56 |
57 | ```
58 | iptables -t filter -I INPUT -i lo -j ACCEPT
59 | iptables -t filter -I INPUT -o lo -j ACCEPT
60 | ```
61 |
62 | Ok, I cheated. The rules are really simple: just ACCEPT everything from (`-i`) or
63 | to (`-o`) loopback interface (`lo`) on chain `INPUT`.
64 |
65 | Maybe not so simple really...
66 |
67 | #### ... and now you can't peer
68 |
69 | Just adding an exception for `lo` is not enough if you want to peer via UDP and
70 | you didn't load the conntrack module. Load it or add an exception for the port
71 | used by the UDPInterface.
72 |
73 | Or just use the first solution.
74 |
75 |
--------------------------------------------------------------------------------
/notes/cjdroute-conf.md:
--------------------------------------------------------------------------------
1 | # What does everything in your configuration file do?
2 |
3 | If you've never worked with [JSON](https://en.wikipedia.org/wiki/JSON) before, you might feel a little overwhelmed editing your **cjdroute.conf** for the first time.
4 |
5 | One thing that makes matters more difficult is that your cjdroute.conf is **not** actually valid JSON.
6 |
7 | This document will:
8 |
9 | 1. Indicate the exact purpose of each attribute of your configuration file.
10 | 2. Document the permitted and recommended syntax you can use, and the difference between the two.
11 | 3. Indicate which attributes are required, and which are optional.
12 | 4. Refer to related documentation about specific attributes, and the surrounding recomended practices.
13 |
14 | ## Structure
15 |
16 | * privateKey
17 | * publicKey
18 | * ipv6
19 | * authorizedPasswords
20 | + password
21 | + ipv6
22 | + user
23 | * admin
24 | + bind
25 | + password
26 | * interfaces
27 | + UDPInterface
28 | + bind
29 | + connectTo
30 | + ETHInterface
31 | + bind
32 | + beacon
33 | + connectTo
34 | * router
35 | + interface
36 | * type
37 | + ipTunnel
38 | * allowedConnections
39 | + publicKey
40 | + ip4Address
41 | + ip6Address
42 | * outgoingConnections
43 | * resetAfterInactivitySeconds
44 | * security
45 | + setuser
46 | + exemptAngel
47 | * logging
48 | + logTo
49 | * noBackground
50 | * dns
51 | + keys
52 | + servers
53 | + minSignatures
54 |
55 | ## Functionality
56 |
57 | ### privateKey, publicKey, ipv6
58 |
59 | As indicated in [this article on cjdns' cryptographic functions](cryptography.md), your ipv6 is derived from your publicKey, which is in turn derived from your privateKey.
60 |
61 | **cjdroute --genconf** produces a sample configuration file which includes all three, but they are not all actually required to launch your router.
62 |
63 | Instead, cjdns only uses your privateKey, then derives the rest. As such, the publicKey and ipv6 are only there for your benefit.
64 |
65 | ### authorizedPasswords
66 |
67 | This is an array of objects. Each object can contain a number of keys that specify how that password is to be used:
68 |
69 | 1. "password" specificies a password that your node will accept as valid. It's recommended that each peer be given a unique password. Without a valid password, a peer will not be able to connect.
70 | 2. "ipv6" specifies which ipv6 can be used in conjunction with a particular password. Additional nodes attempting to connect using the same password and a different ipv6 will be rejected.
71 | 3. "user" is an optional label which must be unique among passwords in your configuration file. It has no effect on peering, otherwise, but is used to label connections when using the peerStats API call. This human readable format makes it easier to determine how each of your peers is behaving, and whether they need to update.
72 |
--------------------------------------------------------------------------------
/notes/wanted.md:
--------------------------------------------------------------------------------
1 | # Help Wanted
2 |
3 | First and foremost, we need someone to constantly review this repository, and keep this file up to date.
4 |
5 | If you see something listed here that has been taken care of, please knock it off the list. If you see something here, and take care of it yourself, please do us another favour and cross it out and link to your work.
6 |
7 | * cjdns
8 | + breakdown of 3 parts of cjdns as explained in the [whitepaper](https://github.com/cjdelisle/cjdns/blob/master/doc/Whitepaper.md)
9 | + how to [cjdroute.conf](https://wiki.projectmeshnet.org/Cjdroute.conf)
10 | + Admin API
11 | * Community
12 | + latest news
13 | + current public peers policy (with links to peers)
14 | + public peers vs open peers (dedicated passwords)
15 | + abuse policy
16 | + what is _official_?
17 | * Peering
18 | + generating and transferring credentials
19 | + ~~over UDP/IP~~
20 | + over Ethernet
21 | + over Wireless
22 | - [batman-adv](http://www.open-mesh.org/projects/open-mesh/wiki)
23 | - [oslr/commotion](https://en.wikipedia.org/wiki/Optimized_Link_State_Routing_Protocol)
24 | - [802.11s](http://lars.meshnet.berlin/view/welcome-visitors/view/80211s-instead-of-adhoc)
25 | - [Adhoc](https://wiki.projectmeshnet.org/Wireless_Autopeering_Tutorial)
26 | + over TCP/IP
27 | - allows obfsproxy deployment
28 | + in datacenters (private networking)
29 | + over iodine
30 | * Security mechanisms (seccomp, angel/core, etc.)
31 | * WiFi Recommendations
32 | * cjdns/contrib/ scripts
33 | + dumpTable
34 | + systemd/upstart
35 | + peerStats
36 | + python/cjdnsadminmaker
37 | * the build system :(
38 | + cjdns/node_build/make.js
39 | * in the media
40 | * [FAQ](../faq/)
41 | + how does cjdns choose which path to take? latency? number of hops?
42 | * choosing paths presupposes knowing them, which can get in the way of finding the _optimal_ path. Paths to nodes are stored preferentially based on the [xor metric](../cjdns/functions/Address_xorcmp.md).
43 | * the path choice metric is a combination of various factors (latency and number of hops are among them). This is poorly documented, and we need someone to explore the exact details. Contributions should go in `../cjdns/functions/`
44 | + My service doesn't like ipv6. how can I get it to run on hype? [6tunnel?](http://toxygen.net/6tunnel/)
45 | * inet6 with tcp6 and netcat
46 | + How can I help?
47 | * documentation!
48 | * coding
49 | - C - help build cjdroute!
50 | - [Android](https://github.com/berlinmeshnet/cjdns-android)
51 | - Go - help jph build zlarkd!
52 | - Windows/CrossPlatform devs - Help us make cjdns portable to *all* the devices!
53 | + Jargon file
54 | * [Known bugs && their circumstances](../bugs/index.md)
55 | + Failure to reestablish connection after disconnect/ipv4 change
56 | + [OS/distro-specific quirks](../bugs/distro-quirks.md)
57 | - OSX doesn't autopeer
58 |
--------------------------------------------------------------------------------
/notes/windows-firewall.md:
--------------------------------------------------------------------------------
1 | # Purpose
2 |
3 | With the Windows population of Hyperboria set to grow, some basic security advice may be needed. Because many of Windows' services cannot be disabled without sacrificing desktop functionality, we will rely on the Windows Firewall as a first line of defense,
4 |
5 | ## Configuration
6 |
7 | On a general purpose desktop PC, it is possible for the firewall to become disabled for any number of reasons. This is generally considered bad practice but not fatal on a LAN. Cjdns will expose the PC to a large network where every node is considered local. The potential for hostile traffic is much higher. Therefore, we must make sure the firewall is enabled:
8 |
9 |
10 | 1. Right click network icon in the system tray and select "Open Network and Sharing Center".
11 | 2. On the left pane of the window, click "Change adapter settings".
12 | 3. Make note of the name of TAP adapter and hit the Back button.
13 | 4. Make sure the TAP adapter is listed as being in a "Public network" and that your LAN is listed as anything other than public. This procedure varies on different Windows versions:
14 | * On Windows 7, you should be able to click the "Private" or "Work" indicator and select a new network type.
15 | * On Windows 8, you need to enable Network Discovery to make a network "Private".
16 | 5. On the left pane of the window, click "Windows Firewall".
17 | 6. On the left pane of the window, click "Tuen Windows Firewall on or off".
18 | 7. Make sure that the firewall is on for Public networks.
19 | 8. Make sure that "Block all incoming connections..." is unchecked under Public networks.
20 | 9. Make sure that "Notify me..." is checked under Public networks.
21 | 10. Accept your changes, provide the Administrator password if needed.
22 | 11. On the left pane of the window, click "Advanced settings".
23 | 12. On the left pane of the window, click "Inbound Rules". (Here you will probably see an overwhelming amount of configuration options. Windows software is allowed to programmatically add firewall rules, sometimes without the approval of the user. Each of these is a potential attack vector, so we need to disable most of them.)
24 | 13. On the right pane of the window, "Filter by profile: Public" and "Filter by state: Enabled"
25 | 14. Sort by the "Action" column so that "Allowed" is at the top.
26 | 15. For each enabled allow rule, you must do the following:
27 | * Ignore "Core Networking - ...." rules.
28 | * Ignore "File and Print Sharing (Echo Request ...)" rules.
29 | * For any rule that is in more than one profile:
30 | + Double click it.
31 | + Switch to the Advanced tab.
32 | + Uncheck "Public".
33 | * For any rule that is in "Public" profile only, disable it.
34 | + This can be done in batches, so it's a little less tedious.
35 | 16. Done!
36 |
37 | This leaves your PC able to participate in basic networking functions like responding to pings, but closes all services to the Cjdns network.
38 |
39 |
--------------------------------------------------------------------------------
/config/windows-firewall.md:
--------------------------------------------------------------------------------
1 | # Purpose
2 |
3 | With the Windows population of Hyperboria set to grow, some basic security advice may be needed. Because many of Windows' services cannot be disabled without sacrificing desktop functionality, we will rely on the Windows Firewall as a first line of defense,
4 |
5 | ## Configuration
6 |
7 | On a general purpose desktop PC, it is possible for the firewall to become disabled for any number of reasons. This is generally considered bad practice but not fatal on a LAN. Cjdns will expose the PC to a large network where every node is considered local. The potential for hostile traffic is much higher. Therefore, we must make sure the firewall is enabled:
8 |
9 |
10 | 1. Right click network icon in the system tray and select "Open Network and Sharing Center".
11 | 2. On the left pane of the window, click "Change adapter settings".
12 | 3. Make note of the name of TAP adapter and hit the Back button.
13 | 4. Make sure the TAP adapter is listed as being in a "Public network" and that your LAN is listed as anything other than public. This procedure varies on different Windows versions:
14 | * On Windows 7, you should be able to click the "Private" or "Work" indicator and select a new network type.
15 | * On Windows 8, you need to enable Network Discovery to make a network "Private".
16 | 5. On the left pane of the window, click "Windows Firewall".
17 | 6. On the left pane of the window, click "Tuen Windows Firewall on or off".
18 | 7. Make sure that the firewall is on for Public networks.
19 | 8. Make sure that "Block all incoming connections..." is unchecked under Public networks.
20 | 9. Make sure that "Notify me..." is checked under Public networks.
21 | 10. Accept your changes, provide the Administrator password if needed.
22 | 11. On the left pane of the window, click "Advanced settings".
23 | 12. On the left pane of the window, click "Inbound Rules". (Here you will probably see an overwhelming amount of configuration options. Windows software is allowed to programmatically add firewall rules, sometimes without the approval of the user. Each of these is a potential attack vector, so we need to disable most of them.)
24 | 13. On the right pane of the window, "Filter by profile: Public" and "Filter by state: Enabled"
25 | 14. Sort by the "Action" column so that "Allowed" is at the top.
26 | 15. For each enabled allow rule, you must do the following:
27 | * Ignore "Core Networking - ...." rules.
28 | * Ignore "File and Print Sharing (Echo Request ...)" rules.
29 | * For any rule that is in more than one profile:
30 | + Double click it.
31 | + Switch to the Advanced tab.
32 | + Uncheck "Public".
33 | * For any rule that is in "Public" profile only, disable it.
34 | + This can be done in batches, so it's a little less tedious.
35 | 16. Done!
36 |
37 | This leaves your PC able to participate in basic networking functions like responding to pings, but closes all services to the Cjdns network.
38 |
39 |
--------------------------------------------------------------------------------
/install/osx.md:
--------------------------------------------------------------------------------
1 | # Installing on Mac OS X
2 |
3 | The easiest way to get cjdns is to use [brew](http://brew.sh/). To get the latest brew formulae run this command from your terminal:
4 |
5 | `brew update`
6 |
7 | Then you should be able to install cjdns with by running:
8 |
9 | `brew install cjdns`
10 |
11 | After which you should have a cjdroute binary available at `/usr/local/Cellar/cjdns//bin/cjdroute`. Usually brew will link the binary to your `/usr/local/bin directory`, to make it available in your `$PATH`.
12 |
13 | # Running CJDNS as launchd daemon
14 | To keep cjdns running in background and to start it automatically when your Mac turns on, it is possible to create a launchd daemon.
15 |
16 | First of all we need to create a script that will be called by launchd and run cjdroute with the specific configuration. This file will contain the path of your configuration, for this example I will assume that your settings are stored in `/etc/cjdroute.conf`. It is vital that the service will NOT run in background, so remember to edit the end of the configuration to have something similar to this:
17 |
18 | ```
19 | ...
20 |
21 | // If set to non-zero, cjdns will not fork to the background.
22 | // Recommended for use in conjunction with "logTo":"stdout".
23 | "noBackground": 1
24 | }
25 | ```
26 |
27 | Create or/and edit the file `/usr/local/bin/cjdroute_start` with the following content:
28 |
29 | ```
30 | #!/bin/bash
31 | # You can use custom path or enable sleeping time to delay the process
32 | /usr/local/bin/cjdroute < /etc/cjdroute.conf
33 | ```
34 |
35 | Now that the script is created, we need to write the instructions for launchd. Create the file `/Library/LaunchDaemons/com.cjdns.cjdroute.plist` using administrator permissions (`sudo nano ...`) and insert the following content in it:
36 |
37 | ```
38 |
39 |
41 |
42 |
43 | Label
44 | com.cjdns.cjdroute
45 | Program
46 | /usr/local/bin/cjdroute_start
47 | RunAtLoad
48 |
49 | KeepAlive
50 |
51 |
52 |
53 | ```
54 |
55 | This will keep our process alive and run it at the startup. At this point we just need to set the right permissions and load the daemon in the configuration by running the following commands in a termianl:
56 |
57 | ```
58 | sudo chmod +x /usr/local/bin/cjdroute_start # Execution
59 | sudo sudo launchctl load /Library/LaunchDaemons/com.cjdns.cjdroute.plist
60 | ```
61 |
62 | If everything is correct, you can now restart your Mac and it will automatically run cjdns. If you want to avoid the reboot, you can start the daemon using the following command:
63 |
64 | ```
65 | sudo launchctl start com.cjdns.cjdroute # To start without rebooting
66 | ```
67 |
68 | Enjoy!
69 |
--------------------------------------------------------------------------------
/bugs/policy.md:
--------------------------------------------------------------------------------
1 | ## Policy
2 |
3 | cjd recently closed the issue tracker on his [cjdns repo](https://github.com/cjdelisle/cjdns) on the basis that it had the effect of encouraging people to submit errors, then wander off feeling like they had done their part in solving the problem (my words, not his (--ansuz)).
4 |
5 | Several of us from within the community encouraged him to do so, justifying the action by considering that it had not been maintained in some time, and without having someone assume responsibility for its maintenance there was little reason to keep it around.
6 |
7 | To make up for its absence, however, we decided to provide [a fork of cjdns](https://github.com/hyperboria/cjdns), with [its own issue tracker](https://github.com/hyperboria/cjdns/issues) which would be maintained by the community. There are quite a few of us who care enough about this project to invest our time in improving things, however, it should be understood that:
8 |
9 | 1. like cjd, we are contributing our own personal time to do so
10 | 2. many of us balance these volunteer commitments against full time jobs
11 | 3. our volunteers are generally intelligent, charming, motivated individuals who could otherwise spend their personal time cavorting with other similarly charming, intelligent, and motivated humans
12 |
13 | With that in mind, the [remarkably small group](https://github.com/orgs/hyperboria/people) who have pushed to curate our documentation and maintain our cjdns fork could really use some help.
14 |
15 | > This document exists to explain how you can get involved, as well as what our terms are for continuing to offer our collective efforts
16 |
17 | 1. We are going to push harder to implement a stricter [WTFM](http://www.roaming-initiative.com/blog/posts/wtfm) policy. If a solution to your problem has been documented, you will be directed to it. If it has not, it will be explained to you under the assumption that you will contribute documentation for the next person to encounter the problem.
18 | 2. If you say you will document something, but you don't, you might end up on a blacklist. Nobody is under any obligation to ignore you, and there will not be any repercussions for offering assistance. However, you probably want to avoid developing a bad reputation. Negative reenforcement tends to be ineffective, though, so you may want a method of encouraging people to contribute, and keeping track of those that have. [VOILA](https://github.com/hyperboria/docs/graphs/contributors)! Contributing lands you on the contributers list.
19 | 3. Issues will be closed if nobody volunteers to investigate further. If three months go by, and nobody contributes more information, we may just assume that the problem has been solved. Similarly, if your issue is vague, or lacks a descriptive title, you will be asked to elaborate. If you do not, it will be closed.
20 | 4. [Gitboria](http://gitboria.com), a GitLab instance on Hyperboria, hosts the canonical repository for these documents. If at all possible, make pull requests or issues there, and not here on github.
21 |
--------------------------------------------------------------------------------
/install/fedora.md:
--------------------------------------------------------------------------------
1 | Installing CJDNS on Fedora
2 | ==========================
3 |
4 | Since Fedora 22, cjdns is in the Fedora repository. To install the easy way:
5 |
6 | ```bash
7 | sudo dnf install cjdns cjdns-tools cjdns-selinux
8 | ```
9 | For rhel6 and rhel7 use:
10 | ```bash
11 | yum install epel-release
12 | yum install cjdns cjdns-tools cjdns-selinux
13 | ```
14 |
15 | The `cjdns-tools` package has peerStats and other nodejs tools. Python versions of the tools are in `cjdns-python` - although the ones conflicting with the nodejs tools are not symlinked to /bin.
16 |
17 | The `cjdns-selinux` package has an selinux sandbox for cjdroute, to prevent it from doing anything wonky through accident or malice. SELinux is enabled by default on Fedora and RHEL - so if you are running Fedora or RHEL/CentOS you'll usually want this.
18 |
19 | Start cjdroute:
20 |
21 | ```bash
22 | sudo systemctl enable cjdns #This sets cjdns to be started on boot. if you don't want that, feel free to leave this line out.
23 | sudo systemctl start cjdns #This actually starts cjdroute.
24 | ```
25 |
26 | For rhel6, use ```start cjdns``` instead of systemctl. Add to /etc/rc.d/rc.local to enable on boot.
27 |
28 | Checking the logs:
29 | ```bash
30 | sudo systemctl status -l cjdns
31 | ```
32 |
33 | Starting cjdroute for the first time will generate a new config file in ```/etc/cjdroute.conf```. The default config will Just Work if there are any other cjdns nodes within reach of ethernet broadcast - for example on your local LAN or mesh. Otherwise, you will need to [add some internet peers as discussed elsewhere.](../configure.md)
34 |
35 | After changing anything in the configuration, restart cjdns:
36 |
37 | ```bash
38 | sudo systemctl restart cjdns
39 | ```
40 |
41 | For rhel6, use ```restart cjdns``` instead of systemctl.
42 |
43 | If you are on a laptop, you may find that after waking up from suspend or hibernate, cjdroute takes a minute or two to make coffee and figure out what just happened. To speed this up, just restart cjdroute. To always restart cjdroute upon awakening, enable the cjdns-resume service:
44 |
45 | ```bash
46 | sudo systemctl enable cjdns-resume
47 | ```
48 |
49 | # Installing CJDNS manually
50 |
51 | ## Prerequisites
52 | ```bash
53 | sudo dnf install git automake nodejs libseccomp-devel gcc
54 | ```
55 |
56 | ## Getting cjdns
57 | ```bash
58 | git clone https://github.com/hyperboria/cjdns
59 | ```
60 |
61 | ## Building cjdns
62 | ```bash
63 | cd cjdns/
64 | ./do
65 | ```
66 |
67 | ## Generating a confighttps://github.com/hyperboria/docs
68 | ```bash
69 | ./cjdroute --genconf > cjdroute.conf
70 | ```
71 |
72 | ## Setting cjdns to autostart on boot.
73 |
74 | First you'll want to edit contrib/systemd/cjdns.service to properly reflect where your cjdns binary and configuration are.
75 | Then, run these commands:
76 |
77 | ```bash
78 | sudo cp cjdns.service /etc/systemd/system/cjdns.service # This gives systemd some information about cjdns.
79 | sudo systemctl enable cjdns.service #This sets cjdns to be started on boot. if you don't want that, feel free to leave this line out.
80 | sudo systemctl start cjdns.service #This actually starts cjdns.
81 | ```
82 |
83 | Checking the logs:
84 | ```bash
85 | sudo systemctl status -l cjdns
86 | ```
87 |
--------------------------------------------------------------------------------
/bugs/horizon.md:
--------------------------------------------------------------------------------
1 | One of the central ideas behind the development of cjdns is that networking protocols should scale up smoothly.
2 | Early development dealt with problems like **not** constructing circular routes, and while that was not yet solved it made sense to limit the length of a path to what would fit within 64 bits of the header of each packet.
3 |
4 | At this point, many of the early issues that were once challenging have been dealt with, and tucked away into a list of things that we shouldn't forget, but which are no longer relevant.
5 | As the protocol has improved and allowed nodes to see and route further into the network, though, we have begun to encounter bugs which we previously had no opportunity to debug, and consequentially, no opportunity to fix.
6 |
7 | The **Horizon** bug is one that we knew was coming, but now we've officially started to hit its limitation.
8 |
9 | ## The nature of the bug
10 |
11 | * the header of each packet has 64 bits of space to store the path to the destination
12 | * using more space (all of the time) would waste precious packet overhead, decreasing usable packet size limit
13 | * each node along the path consumes a variable number of bits dependiung on the number of peers between which they must distinguish (see [switchfun.txt](../switchfun.txt) for some idea of how this works)
14 | * your node cannot route to any node beyond this _horizon_ for the lack of bits required
15 |
16 | ## So what are the implications of this bug?
17 |
18 | 1. nodes with more peers consume more bits, and are generally a good thing as they reduce the number of hops to a wider audience of nodes
19 | 2. nodes with fewer peers consume fewer bits, and result in more hops on average, however, their simpler encoding will allow your node to reach further into the network
20 | 3. If you want to have effective routing to the greatest number of nodes possible, the onus is on you to evaluate your position in the network and peer in such a way that the nodes you wish to connect to are within a reasonable distance (via 'backhaul' links with few peers, or via hubs which connect you within a few hops to a large portion of the net)
21 |
22 | ## How can we deal with this?
23 |
24 | Naturally, we can approach the problem from a few angles, so whatever your skill set is, there's likely something that you can do to help.
25 |
26 | 1. help rewrite the parts of cjdns which encode the paths such that a variable number of bits can be used
27 | 1.1. Probably less code is needed than it first seems... If the final representation is a stack of 64 bit labels, many places in the code will still work with 64 bits quite happily.
28 | 2. use the admin interface to figure out which parts of the network your node can see, and compare those results against a wider view of the network, so we can identify our blind spots
29 | 3. evaluate your peering choices, and try to drop bad peers and pick good ones, so that we can continue to have a functional network in the meantime (we're still quite likely to have lots of paths that are out of reach, so we'll still be able to debug this issue, don't worry)
30 | 4. talk to your friends about cjdns, and get them to join the network, so we have more opportunity to find long _shortest-paths_ to any particular node (see, you don't even need to know how to code!)
31 |
32 | ## Conclusion
33 |
34 | This is great news! That we are hitting this bug at all means we've progressed quite a bit.
35 | Let's sort this one out so we can move on to the next and make cjdns the de facto choice for mesh networking!
36 |
--------------------------------------------------------------------------------
/notes/cjdns-core.md:
--------------------------------------------------------------------------------
1 | # Cjdns Core Notes
2 |
3 | ## Introduction
4 |
5 | A number of us have begun the task of documenting and reverse engineering the cjdns core. The "core" refers to the core functionality required to implement a cjdns-compatible router.
6 |
7 | To speak with those involved, join **irc.fc00.io/#documentation**
8 |
9 | ## Status
10 |
11 | ansuz has re-implemented the [xor metric](https://github.com/ansuz/cjdnsjs/tree/master/scripts/xor) and [key generation process](https://github.com/ansuz/cjdnsjs/tree/master/scripts/keys), along with the support functions involved, notably the implementation of Base32 used by cjdns.
12 |
13 | [jph](https://hackworth.be/) is experimenting with writing a minimal, linux first implementation in golang, along with deconstructing everything involved in making that happen. He is also investigating TUN support in other languages (notably Python and ocaml).
14 |
15 | **Note to contributors**:
16 |
17 | * If you think of additional core functions to document, please add them below
18 | * Please provide either pseudo-code or working code examples inline. Longer code examples should be linked to, and preferably hosted on gitboria
19 |
20 | # TUN device support
21 |
22 | ## Overview
23 |
24 | Cjdns uses [TUN devices](https://www.kernel.org/doc/Documentation/networking/tuntap.txt) to create a virtual network interface and enable routable peer to peer connections. Therefore, TUN support is a critical requirement for implement a cjdns router.
25 |
26 | At this time, the following languages have built-in or third-party TUN support:
27 |
28 | * C
29 | * Golang
30 | * Python
31 | * Ruby
32 | * Ocaml
33 |
34 | Please note that "TUN support" may not have the full functionality required by a cjdns router. As this section is expanded, we will describe what that functionality is.
35 |
36 | In addition, be aware that TUN implementation varies across operating system implementations. Multiplatform router implementations need to keep this in mind.
37 |
38 | ## Creating a TUN device
39 |
40 | TBC
41 |
42 | ## Configuring a TUN device
43 |
44 | TBC
45 |
46 | # Cryptography
47 |
48 | Cryptography provides core functionality within cjdns. [Here](cryptography.md) we will describe some of the cryptographic functions performed within cjdns and implementation details.
49 |
50 | ## Public Keys
51 |
52 | * Cryptographic algorithms required
53 | * Creating a private/public key pair
54 | * Encoding private/public keys into a string
55 | * Decoding private/public keys from a string
56 | * Format for sharing public keys (peering credentials)
57 |
58 | # Utility Functions
59 |
60 | Instead of relying on external libraries, some utility functions have been re-implemented within cjdns. We will describe those functions that differ from standard implementations to ensure compatibility with existing cjdns routers.
61 |
62 | ## JSON
63 |
64 | cjdns config files are typically stored as what the community often refers to as [cjdson](https://github.com/cjdson). As [finn](https://github.com/thefinn93) has pointed out, [comments](https://commentjson.readthedocs.org/en/latest/) [in json](https://www.npmjs.com/package/strip-json-comments) are [not unheard of](https://www.npmjs.com/package/json-comments).
65 |
66 | In any case, we're going to try to add some functionality to that repo that the others lack, such as _inserting fields without deleting comments_.
67 |
68 | ## Base32
69 |
70 | [This Javascript library](https://github.com/ansuz/cjdnsjs/blob/master/scripts/keys/cjdb32.js) is a direct translation of [the cjdns base32 encoder written in C](https://github.com/cjdelisle/cjdns/blob/master/util/Base32.h#L109)
71 |
--------------------------------------------------------------------------------
/faq/security.md:
--------------------------------------------------------------------------------
1 | ## Security
2 |
3 | ```
4 | 16:39 < Erkan> well, I am not so sure about using VPS, tbh
5 | 16:39 < Erkan> your hoster (or the agency showing him the judge's paper) can get your config
6 | ```
7 |
8 | Suppose you want to [pull a snowden](https://en.wikipedia.org/wiki/Global_surveillance_disclosures_%282013%E2%80%93present%29) and release some sensitive documents. Suppose that for some reason you're relying on an experimental protocol (cjdns) to do so. `Erkan` is wondering about the wisdom of doing so.
9 |
10 | [cjdns](https://github.com/cjdelisle/cjdns) is big and complicated, and without a fair deal of experience with cryptographic tools you may have a hard time understanding what's safe and what is not.
11 |
12 | ## If you're hosting a cjdns node on a VPS
13 |
14 | There are quite likely measures that you can take to encrypt your VPS's hard drive, and you should look into that, but suppose you haven't encrypted anything. In that case, yes, your VPS provider can probably just go and look at your private keys, and read your encrypted traffic.
15 |
16 | Even if you have encrypted your hard drive:
17 |
18 | > your provider can pause you for a moment and take a snapshot of your ram, then dump your keys
19 |
20 | > `--cjd`
21 |
22 | The implication of this is that any traffic originating with, or destined for your VPS, should not be treated as being absolutely secure.
23 |
24 | ## The upside
25 |
26 | What you should understand is cjdns uses [end to end encryption](https://en.wikipedia.org/wiki/End-to-end_encryption). That means that having your own private key compromised only affects that particular node's security. A compromised node can continue to forward traffic, and because of the nature of public key cryptography, it will be unable to read the contents of the packets it relays.
27 |
28 | So, should you worry about hosting on a VPS? **Only if you intend to _send_ or _receive_ sensitive information on that particular node**.
29 |
30 | If you want to connect to Hyperboria, but are for whatever reason unable to do so from your main computer, using a VPS as a static link into the network is quite reasonable. As long as you take precautions to protect the private keys on any nodes which initiate connections, **your data will remain secure in transit**.
31 |
32 | ## Perfect Forward Secrecy
33 |
34 | Temporary keys are used and destroyed when cryptAuth sessions time out. Timeouts are subject to environmental influence, but can be considered _random_ for most practical purposes. CryptAuth sessions are all killed when cjdroute is restarted.
35 |
36 | If your `cjdroute.conf` file is somehow compromised, it _does **not**_ mean that all prior sessions have also been compromised.
37 |
38 | A compromised private key means someone can impersonate you going forward, though, it is quite likely that any party motivated to compromise your node would not do so. It is far more likely that a skilled aggressor would simply use it to eavesdrop, and you would not realize that your node had been undermined.
39 |
40 | ## A few notes
41 |
42 | cjdns is experimental! It is possible that someone is using a zero-day exploit in the wild to compromise a node's security.
43 |
44 | If you're really worried, you can also use tools like PGP to further encrypt data before sending it.
45 |
46 | You could also use an [XMPP client](https://en.wikipedia.org/wiki/XMPP) that supports the [OTR](https://otr.cypherpunks.ca/) protocol, and use that to transfer PGP-encrypted data over cjdns.
47 |
48 | If you have good reason to protect your data (other than simply doing it on principal), then redundancy is your friend!
49 |
50 | If it's not completely clear from the information above, you should not store your PGP keys on your VPS either! Encrypt locally, protect your keys, and be mindful that others do not have physical access to the device which stores your private keys!
51 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Hyperboria/docs
2 |
3 | ## What is Hyperboria?
4 |
5 | Hyperboria is test network built of cjdns nodes.
6 |
7 | ## What is cjdns?
8 |
9 | Cjdns is an experimental, cryptographic mesh networking suite.
10 |
11 | ## What is notable about cjdns? Why should I use it?
12 |
13 | Cjdns builds an [end-to-end encrypted](https://en.wikipedia.org/wiki/End-to-end_encryption) [IPv6](https://en.wikipedia.org/wiki/IPv6) [mesh network](https://en.wikipedia.org/wiki/Mesh_networking) that utilizes the [fc00::/8 address space](https://en.wikipedia.org/wiki/Unique_local_address).
14 |
15 | ### Encryption
16 |
17 | Cjdns provides an encrypted tunnel which utilizes a [private/public keypair](https://en.wikipedia.org/wiki/Public-key_cryptography) to encrypt everything that passes through it with the [SALSA20 stream cypher](https://en.wikipedia.org/wiki/Salsa20), which affords the user [perfect forward secrecy](https://en.wikipedia.org/wiki/Forward_secrecy).
18 |
19 | ### Address Allocation
20 |
21 | The ipv6 assigned to the TUN interface is composed of the first 16 bytes of the SHA512 hash of the [SHA512 hash](https://en.wikipedia.org/wiki/SHA-2) of your public key. Keypairs are generated via a [brute force method](https://en.wikipedia.org/wiki/Brute-force_search) until a corresponding address is found with a starting byte FC. The FC00::/8 address space has been allocated as a Unique Local Address space, and so these addresses should not conflict with ICANN assigned IPv6 addresses or any other conventional internet operation.
22 |
23 | ### Hybrid topology
24 |
25 | Cjdns was designed to be used with a [friend of a friend](https://en.wikipedia.org/wiki/Friend_of_a_friend) topology. It builds an [overlay network](https://en.wikipedia.org/wiki/Overlay_network) which traverses NAT ([Network Address Translation](https://en.wikipedia.org/wiki/Network_address_translation)), exposing all ports of every node to every other node within the network. Those who are used to relying on NAT to protect their devices may find this troublesome.
26 |
27 | At one point it was expected that each person who peered would do so with only trusted friends. You need not trust relaying nodes with the confidentiality or integrity of your packets, however, if you wish to restrict access to certain services, it is your responsibility to implement effective access control rules.
28 |
29 | Links between nodes may be established over deliberate [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol) links across the internet, or over deliberate or automatic connections across Ethernet, Wireless access points, Ad-hoc connections, or various system-specific transmission and addressing protocols.
30 |
31 | ### Cryptographic verification and routing
32 |
33 | Establishing a link between two nodes includes a cryptographic authorization process, after which other nodes within the network can establish a connection with the new node.
34 |
35 | Due to the relationship between each node's public key and its ipv6, and the fact that this relationship is verified upon connecting to a node, a user can be sure that if it connects to an IPv6 address and receives a response then the node that responded possesses the requisite private key to decrypt the response.
36 |
37 | If you are able to connect at all over cjdns, then you can be quite sure that the node you connected to possesses the private key that corresponds to the IPv6.
38 |
39 | ## How can I get involved?
40 |
41 | If you are totally new to cjdns, you'll want to start by installing it somewhere and familiarizing yourself with how it works. Take notes of anything that you find difficult, unintuitive, or poorly documented, and share your knowledge so the next person who installs cjdns after reading the documentation has an easier time.
42 |
43 | Also, read our [contributing](contributing.md) document for notes on our policies for accepting contributions.
44 |
--------------------------------------------------------------------------------
/projectGoals_ru.md:
--------------------------------------------------------------------------------
1 | # Project Goals
2 | ## Зачем?
3 |
4 | Для того, чтобы дать обычным людям больше возможностей при обмене информацией.
5 |
6 | Cjdns позволяет решить множество проблем текущих сетей. При его использовании вы полностью обладаете своей инфраструктурой обмена информацией.
7 |
8 | Кроме того, данный протокол позволяет решить проблему оптимального перераспределения трафика, не делая практически ничего.
9 |
10 | Вот простой пример. Сколько у вас дома есть открытых Wi-Fi сетей?
11 |
12 | Вероятно, не меньше двух. А теперь представьте, что они работают в Mesh режиме, динамически перенаправляя нагрузку и распределяя трафик.
13 |
14 | Централизация власти проявляется в закрытии таких сайтов, как Wikileaks, и любых других — неугодных власти.
15 |
16 | В цивилизованном, демократическом обществе каждый должен иметь свободу слова, а цензурироваться могут лишь очевидно-плохие вещи: детская порнография, мошенничество, спам. И конечно, решения о цензуре должно принимать общество, а не правительство.
17 |
18 |
19 | ## Как мы близки к финальной версии?
20 |
21 | В данный момент работает тестовая сеть, в которой имеется от 500 до 1000 узлов.
22 |
23 | Cjdns была протестирована на x86, amd64, ARMv5, ARMv7, MIPS, PowerPC32 и PowerPC64. Тестирование на различных Linux системах продолжается.
24 |
25 | Программное обеспечение работает стабильно, но мы не знаем, как поведут себя в реальном мире наши алгоритмы и протоколы. Пожалуйста, следите за обновлениями cjdns. С помощью тестирования мы сможем определить оптимальный набор алгоритмов и протоколов для использования в реальном мире.
26 |
27 |
28 | ## Ты можешь помочь!
29 |
30 | Нам нужны добровольцы для тестирования по автоматической сборке cjdns на Apple OS X системе, если вы можете пожертвовать нам деньги для этого дела — напишите нам на почту.
31 |
32 | Или же вы можете помочь нам, предоставив 24/7 shell доступ к компьютеру с системой OS X для проведения тестирования.
33 |
34 | Всё это можно обсудить в нашем IRC канале.
35 |
36 |
37 | ## Анонимность
38 |
39 | В отличии от TOR, I2P, и Freenet’a, cjdns планировалась не как анонимная есть. Она не использует случайную маршрутизацию, динамические маршруты и другие технологии для обеспечения анонимности.
40 |
41 | Наоборот, cjdns использует самый оптимальный маршрут. Мы пошли на такой шаг, для обеспечения максимальной производительности.
42 |
43 | С другой стороны, некий уровень анонимности всё же присутствует. Для того, чтобы определить ваше физическое положение на основе вашего cjdns адреса, потребуется сделать трассировку по IPv4 адресам от конечной ноды до вас, запросив информацию по проходящему трафику от операторов всех транзитных нод.
44 |
45 |
46 | ## Безопасность
47 |
48 | Когда вы получаете информационный пакет из интернета, это означает, что он предназначен для вас, но никто не знает, модифицировался ли пакет по пути или же нет. Множество программ, которые взаимодействуют с интернетом, не проверяют неизменность пакета, а такие программно-аппаратные средства, как DPI, могут вносить значительные изменения в пакеты.
49 |
50 | Cjdns гарантирует, что пакет по пути был не кем не модифицирован, что подтверждается криптографическими средствами, которые используются в этом протоколе.
51 |
52 | Cjdns защищает информацию которая поступает к вам, от использования заведомо ложного маршрута, что позволяет полностью избежать атаки man-in-the-middle.
53 |
54 |
55 | ## Простота
56 |
57 | Представьте себе такую компьютерную сеть, в которой всё, что нужно сделать инженеру — это подключить компьютер сетевым кабелем, а компьютер сам узнает, как найти других и сам сконфигурируется.
58 |
59 | Это и есть основная цель cjdns. Конечно же, сетевые специалисты всё еще будут нужны для решения сложных технических вопросов, но большую часть решения проблем сможет взять на себя cjdns.
60 |
61 |
62 | ## Масштабируемость
63 |
64 | С основе Cjdns лежат принципы одноранговой сети, таким образом, cjdns может масштабироваться бесконечно — нет большой нагрузки на какой-то определенный узел.
65 | Cjdns использует распределенную хэш таблицу (DHT) для обмена маршрутами, это позволяет не иметь карту всей сети каждому узлу (не раздувать таблицу маршрутов).
66 |
--------------------------------------------------------------------------------
/project-goals-ru.md:
--------------------------------------------------------------------------------
1 | # Project Goals
2 | ## Зачем?
3 |
4 | Для того, чтобы дать обычным людям больше возможностей при обмене информацией.
5 |
6 | Cjdns позволяет решить множество проблем текущих сетей. При его использовании вы полностью обладаете своей инфраструктурой обмена информацией.
7 |
8 | Кроме того, данный протокол позволяет решить проблему оптимального перераспределения трафика, не делая практически ничего.
9 |
10 | Вот простой пример. Сколько у вас дома есть открытых Wi-Fi сетей?
11 |
12 | Вероятно, не меньше двух. А теперь представьте, что они работают в Mesh режиме, динамически перенаправляя нагрузку и распределяя трафик.
13 |
14 | Централизация власти проявляется в закрытии таких сайтов, как Wikileaks, и любых других — неугодных власти.
15 |
16 | В цивилизованном, демократическом обществе каждый должен иметь свободу слова, а цензурироваться могут лишь очевидно-плохие вещи: детская порнография, мошенничество, спам. И конечно, решения о цензуре должно принимать общество, а не правительство.
17 |
18 |
19 | ## Как мы близки к финальной версии?
20 |
21 | В данный момент работает тестовая сеть, в которой имеется от 500 до 1000 узлов.
22 |
23 | Cjdns была протестирована на x86, amd64, ARMv5, ARMv7, MIPS, PowerPC32 и PowerPC64. Тестирование на различных Linux системах продолжается.
24 |
25 | Программное обеспечение работает стабильно, но мы не знаем, как поведут себя в реальном мире наши алгоритмы и протоколы. Пожалуйста, следите за обновлениями cjdns. С помощью тестирования мы сможем определить оптимальный набор алгоритмов и протоколов для использования в реальном мире.
26 |
27 |
28 | ## Ты можешь помочь!
29 |
30 | Нам нужны добровольцы для тестирования по автоматической сборке cjdns на Apple OS X системе, если вы можете пожертвовать нам деньги для этого дела — напишите нам на почту.
31 |
32 | Или же вы можете помочь нам, предоставив 24/7 shell доступ к компьютеру с системой OS X для проведения тестирования.
33 |
34 | Всё это можно обсудить в нашем IRC канале.
35 |
36 |
37 | ## Анонимность
38 |
39 | В отличии от TOR, I2P, и Freenet’a, cjdns планировалась не как анонимная есть. Она не использует случайную маршрутизацию, динамические маршруты и другие технологии для обеспечения анонимности.
40 |
41 | Наоборот, cjdns использует самый оптимальный маршрут. Мы пошли на такой шаг, для обеспечения максимальной производительности.
42 |
43 | С другой стороны, некий уровень анонимности всё же присутствует. Для того, чтобы определить ваше физическое положение на основе вашего cjdns адреса, потребуется сделать трассировку по IPv4 адресам от конечной ноды до вас, запросив информацию по проходящему трафику от операторов всех транзитных нод.
44 |
45 |
46 | ## Безопасность
47 |
48 | Когда вы получаете информационный пакет из интернета, это означает, что он предназначен для вас, но никто не знает, модифицировался ли пакет по пути или же нет. Множество программ, которые взаимодействуют с интернетом, не проверяют неизменность пакета, а такие программно-аппаратные средства, как DPI, могут вносить значительные изменения в пакеты.
49 |
50 | Cjdns гарантирует, что пакет по пути был не кем не модифицирован, что подтверждается криптографическими средствами, которые используются в этом протоколе.
51 |
52 | Cjdns защищает информацию которая поступает к вам, от использования заведомо ложного маршрута, что позволяет полностью избежать атаки man-in-the-middle.
53 |
54 |
55 | ## Простота
56 |
57 | Представьте себе такую компьютерную сеть, в которой всё, что нужно сделать инженеру — это подключить компьютер сетевым кабелем, а компьютер сам узнает, как найти других и сам сконфигурируется.
58 |
59 | Это и есть основная цель cjdns. Конечно же, сетевые специалисты всё еще будут нужны для решения сложных технических вопросов, но большую часть решения проблем сможет взять на себя cjdns.
60 |
61 |
62 | ## Масштабируемость
63 |
64 | С основе Cjdns лежат принципы одноранговой сети, таким образом, cjdns может масштабироваться бесконечно — нет большой нагрузки на какой-то определенный узел.
65 | Cjdns использует распределенную хэш таблицу (DHT) для обмена маршрутами, это позволяет не иметь карту всей сети каждому узлу (не раздувать таблицу маршрутов).
66 |
--------------------------------------------------------------------------------
/index.md:
--------------------------------------------------------------------------------
1 | # Hyperboria
2 |
3 | ## The privacy-friendly network without borders
4 |
5 | We're a community of local Wifi initiatives, programmers, and enthusiasts.
6 | We run a peer-to-peer IPv6 network with automatic end-to-end encryption,
7 | distributed IP address allocation, and DHT-based Source Routing.
8 |
9 | - Existing applications Just Work
10 | - Low entry barriers for users and ISPs
11 | - Runs on Linux, Android, OpenWrt, OS X, and many others
12 |
13 | Hyperboria is based on the cjdns routing protocol.
14 |
15 | You can contribute to its documentaion: https://github.com/hyperboria/docs
16 |
17 |
18 | ## About Hyperboria
19 |
20 | - [Asking Questions](wtfm.md) *TODO*
21 | - [Peering](faq/peering.md)
22 | - [Security](faq/security.md)
23 | - [Meshlocals](meshlocals/intro.md)
24 | - [Meshlocals around the world](meshlocals/existing/index.md)
25 | - [Starting a Meshlocal](meshlocals/diy.md)
26 | - [FAQ](faq/general.md)
27 | - [Achievements](achievements.md)
28 | - [Glossary](faq/glossary.md)
29 |
30 |
31 | ## The cjdns routing protocol
32 |
33 | - About
34 | - [Goals](project-goals.md) ([russian](project-goals-ru.md))
35 | - [Original whitepaper](Whitepaper.md)
36 | - [Brief intro](intro.md)
37 | - [Security Specification](security-specifications.md)
38 | - Installation
39 | - [Most Linuxes](install/linux.md) *TODO*
40 | - [OpenWrt](install/openwrt.md)
41 | - [Ubiquiti EdgeOS](install/ubiquiti-edgeos.md)
42 | - [Android](install/android.md) *TODO*
43 | - [Firefox OS](install/firefoxos.md) *TODO*
44 | - [OS X](install/osx.md)
45 | - [Debian Wheezy](install/debian-wheezy.md)
46 | - [Debian Jessie](install/debian-jessie.md)
47 | - [Arch](install/arch.md)
48 | - [Fedora](install/fedora.md)
49 | - [FreeBSD](install/freebsd.md) *TODO*
50 | - [OpenBSD](install/openbsd.md) *TODO*
51 | - [Windows](install/windows.md)
52 | - [Building *on* Windows](install/build-on-windows.md)
53 | - [Securing your Windows system](config/windows-firewall.md)
54 | - Usage
55 | - [Setup](config/configure.md)
56 | - [Operator guidelines](cjdns/operator-guidelines.md)
57 | - [Securing your system](config/network-services.md)
58 | - [Tools](tools/index.md) *TODO*
59 | - [Third party tools](ctrls.md)
60 | - [Admin API](cjdns/admin-api.md)
61 | - Working with cjdns
62 | - [Anatomy of cjdroute](cjdns/anatomy.md)
63 | - [Peering over UDP](cjdns/peering-over-UDP-IP.md)
64 | - [nodeinfo.json](cjdns/nodeinfo-json.md)
65 | - [Changelog](cjdns/changelog.md)
66 | - HowTo
67 | - [Using cjdns as a VPN](config/tunnel.md)
68 | - [Shorewall and VPN gateway](config/shorewall-and-vpn-gateway-howto.md)
69 | - [NAT gateway for non-cjdns nodes](config/nat-gateway.md)
70 | - [Autostart at login](config/autostart-at-login.md)
71 | - [Run as non-root user](config/non-root-user.md)
72 | - Troubleshooting
73 | - [Read this first](bugs/policy.md)
74 | - [Memory leaks](bugs/debugging-memory-leaks.md)
75 | - [SecComp](bugs/Seccomp.md)
76 | - [Analyzing network IO](traffic-analysis.md)
77 | - Known issues
78 | - [Horizon](bugs/horizon.md)
79 | - [Black Hole](bugs/black-hole.md)
80 | - [Secret Santa](bugs/santa.md)
81 | - Configurator timeout
82 | - [Firewall on localhost](bugs/configurator-timeout.md)
83 | - [UDP overflow](bugs/connectTo-overflow.md)
84 | - ~~[Hidden Peers](bugs/hidden-peers.md)~~
85 | - [OS/distro-specific quirks](bugs/distro-quirks.md)
86 | - [Reporting bugs](bugs/reporting.md)
87 |
88 |
89 | ## Random notes, work-in-progress, inbox
90 |
91 | These notes are unstructured, and most of them likely outdated.
92 |
93 | * [Interesting links](notes/links.md)
94 | * [ansuz' Q&A with Arceliar](notes/arc-workings.md)
95 | * [cjdns-core](notes/cjdns-core.md)
96 | * [cryptography](notes/cryptography.md)
97 | * [cjdroute.conf](notes/cjdroute-conf.md)
98 | * [./do](notes/do.md)
99 | * [DNS ideas](notes/dns.md)
100 | * [DJC layer model](djc-layer-model.md)
101 | * [Benchmarks](benchmark.txt)
102 | * [Fun with the switch](switchfun.txt)
103 |
104 | More of this in `notes/`.
105 |
--------------------------------------------------------------------------------
/projectGoals.md:
--------------------------------------------------------------------------------
1 | # Project goals
2 |
3 | ## With built-in security and auto-configuration, everybody can own a part of the network
4 |
5 | The Internet gives everyone incredible power of expression that was once
6 | reserved for those wealthy enough to own a radio station or newspaper. Still,
7 | the Internet's aging protocols have inherent limitations which make them
8 | unfavorable toward a network owned by the people.
9 |
10 | Recent revelations over governments reading our emails have triggered public
11 | outcry but few stop to imagine the implications of an unsecured
12 | mesh network, in such a network *everybody* could read your email.
13 |
14 | Competition in Internet Access markets worldwide has withered, dominated by a
15 | few businesses who charge outrageous rates and have not materially increased
16 | Internet speed since crushing the dial-up providers. Most agree that more market
17 | diversity is necessary, but if the handful of ISPs we have now cannot be trusted
18 | to handle our data, there is no reason to expect that the next generation of
19 | Internet Service Providers would either.
20 |
21 | The problem of trust extends beyond private correspondence. The very
22 | fabric of the Internet can be torn apart by a malicious ISP or even an honest
23 | mistake. On April 8th, 2010, an employee at China Telecom misconfigured a
24 | router - causing widespread Internet outages lasting up to fifteen minutes.
25 |
26 | As world governments continue pushing to filter websites, there is an ever
27 | increasing risk of back-and-forth retaliatory filtration eventually leaving
28 | entire nations isolated and breeding the hate and intolerance which the Internet
29 | promised to end.
30 |
31 | Cjdns was designed with the understanding that for the Internet to continue
32 | existing without borders, authority over its processes must be decentralized.
33 | This isn't, and can't be, just a dream - the future of the open Internet is at
34 | stake.
35 |
36 |
37 | ## Security
38 |
39 | When you receive a packet of information from the Internet, it seems logical to
40 | assume that it was meant for you - that it came from the computer which it says
41 | it came from and that nobody else has read or modified it on the way. While many
42 | popular software applications are designed around these assumptions, the
43 | existing Internet does not guarantee any of them and a number of network
44 | security exploits come from the cases where these assumptions break down.
45 |
46 | Cjdns guarantees confidentiality, authenticity and integrity of data by using
47 | modern cryptography in a non-intrusive way. Information transmitted over a cjdns
48 | network can't be altered or read en-route. While you can create multiple
49 | identities, it's practically impossible to impersonate other nodes on the
50 | network and since a node's IPv6 address is the fingerprint of its key,
51 | man-in-the-middle attacks are not possible.
52 |
53 |
54 | ## Simplicity
55 |
56 | Traditional networks require manual configuration of IP addresses. For one to
57 | get these addresses one must join an Internet Registry and file a lengthy
58 | application. Cjdns nodes generate their own addresses along with their keys.
59 | When two nodes find each other, they connect. When many nodes find one another,
60 | they form a network. General network architecture is of course needed to avoid
61 | bottlenecks but once the nodes are put in the right places, they will discover
62 | their roles in the network.
63 |
64 |
65 | ## Scalability
66 |
67 | Cjdns is built around the bold and unproven assumption that a non-hierarchical
68 | network can scale. Cjdns uses a [distributed hash table][] to spread the load
69 | of routing among a number of nodes, rather than requiring every node know the
70 | exact location of every other node. At the bottom layer, packets are tagged
71 | with the exact route they should take, think of it like driving directions.
72 | At the upper layer the nodes maintain and test routes to other nodes who have
73 | numerically similar IPv6 addresses to their own. Forwarding is achieved by
74 | sending a packet to physically nearby nodes who have destinations numerically
75 | close to the target address.
76 |
--------------------------------------------------------------------------------
/project-goals.md:
--------------------------------------------------------------------------------
1 | # Project goals
2 |
3 | ## With built-in security and auto-configuration, everybody can own part of the network
4 |
5 | The Internet gives everyone incredible power of expression that was once
6 | reserved for those wealthy enough to own a radio station or newspaper. Still,
7 | the Internet's aging protocols have inherent limitations which make them
8 | unfavorable toward a network owned by the people.
9 |
10 | Recent revelations over governments reading our emails have triggered public
11 | outcry but few stop to imagine the implications of an unsecured
12 | mesh network, in such a network *everybody* could read your email.
13 |
14 | Competition in Internet Access markets worldwide has withered, dominated by a
15 | few businesses who charge outrageous rates and have not materially increased
16 | Internet speed since crushing the dial-up providers. Most agree that more market
17 | diversity is necessary, but if the handful of ISPs we have now cannot be trusted
18 | to handle our data, there is no reason to expect that the next generation of
19 | Internet Service Providers would either.
20 |
21 | The problem of trust extends beyond private correspondence. The very
22 | fabric of the Internet can be torn apart by a malicious ISP or even an honest
23 | mistake. On April 8th, 2010, an employee at China Telecom misconfigured a
24 | router - causing widespread Internet outages lasting up to fifteen minutes.
25 |
26 | As world governments continue pushing to filter websites, there is an ever
27 | increasing risk of back-and-forth retaliatory filtration eventually leaving
28 | entire nations isolated and breeding the hate and intolerance which the Internet
29 | promised to end.
30 |
31 | Cjdns was designed with the understanding that for the Internet to continue
32 | existing without borders, authority over its processes must be decentralized.
33 | This isn't, and can't be, just a dream - the future of the open Internet is at
34 | stake.
35 |
36 |
37 | ## Security
38 |
39 | When you receive a packet of information from the Internet, it seems logical to
40 | assume that it was meant for you - that it came from the computer which it says
41 | it came from and that nobody else has read or modified it on the way. While many
42 | popular software applications are designed around these assumptions, the
43 | existing Internet does not guarantee any of them and a number of network
44 | security exploits come from the cases where these assumptions break down.
45 |
46 | Cjdns guarantees confidentiality, authenticity and integrity of data by using
47 | modern cryptography in a non-intrusive way. Information transmitted over a cjdns
48 | network can't be altered or read en-route. While you can create multiple
49 | identities, it's practically impossible to impersonate other nodes on the
50 | network and since a node's IPv6 address is the fingerprint of its key,
51 | man-in-the-middle attacks are not possible.
52 |
53 |
54 | ## Simplicity
55 |
56 | Traditional networks require manual configuration of IP addresses. For one to
57 | get these addresses one must join an Internet Registry and file a lengthy
58 | application. Cjdns nodes generate their own addresses along with their keys.
59 | When two nodes find each other, they connect. When many nodes find one another,
60 | they form a network. General network architecture is of course needed to avoid
61 | bottlenecks but once the nodes are put in the right places, they will discover
62 | their roles in the network.
63 |
64 |
65 | ## Scalability
66 |
67 | Cjdns is built around the bold and unproven assumption that a non-hierarchical
68 | network can scale. Cjdns uses a [distributed hash table](https://en.wikipedia.org/wiki/Distributed_hash_table)
69 | to spread the load of routing among a number of nodes, rather than requiring
70 | every node know the exact location of every other node. At the bottom layer,
71 | packets are tagged with the exact route they should take, think of it like
72 | driving directions. At the upper layer the nodes maintain and test routes to
73 | other nodes who have numerically similar IPv6 addresses to their own.
74 | Forwarding is achieved by sending a packet to physically nearby nodes who have
75 | destinations numerically close to the target address.
76 |
--------------------------------------------------------------------------------
/cjdns/anatomy.md:
--------------------------------------------------------------------------------
1 | # Anatomy of a running cjdns
2 |
3 | We examine a running cjdns instance using standard UNIX tools.
4 |
5 | For the rest of this document, we assume that cjdns has been started with the default config, using the following command:
6 |
7 | ```
8 | # cjdroute --genconf > cjdroute.conf
9 | # cjdroute --nobg < cjdroute.conf
10 | ```
11 |
12 |
13 | ## Processes
14 |
15 | ```
16 | # ps aux | grep cjd
17 | root 3020 0.0 0.1 18052 2908 ? Ss 22:55 0:00 /usr/sbin/cjdroute --nobg
18 | root 3022 0.0 0.0 9276 948 ? S 22:55 0:00 /usr/sbin/cjdroute angel client-angel-2mtr2h715xzmlpy97pt9z4x1t6082z
19 | nobody 3023 1.1 0.2 18672 3856 ? S 22:55 0:27 /usr/sbin/cjdroute core cq9xvsmb1l95mltplt23jl7n56sbwz
20 | ```
21 |
22 | We're seeing three processes.
23 |
24 | 1. The process we started, which doesn't serve any particular purpose, apart from staying in the foreground, and capturing the other two processes' log output.
25 | - The `--nobg` switch is equivalent to setting `"noBackground": 1` in `cjdroute.conf`.
26 | - If we omit `--nobg`, we will see a bit of log output from cjdns' starting up. Then the process will exit and cjdns will continue to run in the background.
27 | 2. The Angel process
28 | - Child of the process we started
29 | - If we omit `--nobg`, it will get re-parented to pid 1 (usually `init`.)
30 | - Reponsible for system integration -- bind sockets, create TUN interface, etc.
31 | 3. The Core process
32 | - Child of the Angel process
33 | - It drops permissions and runs as `nobody`
34 | - Responsible for actual routing and switching
35 |
36 | Find out more about the Angel/Core split: [Security mechanisms](security.md)
37 |
38 | Notes:
39 |
40 | - Busybox' `ps` doesn't support the options used above. That means we'll use just `ps | grep cjd` on systems like OpenWrt or Android.
41 |
42 |
43 | ## Listening ports
44 |
45 | ```
46 | # netstat -ulp | grep cjd
47 | udp 0 0 localhost:11234 *:* 3023/cjdroute
48 | udp 0 0 172.17.42.1:60814 *:* 3023/cjdroute
49 | udp 0 0 *:60814 *:* 3023/cjdroute
50 | udp6 0 0 [::]:55709 [::]:* 3023/cjdroute
51 | ```
52 |
53 | We're seeing a couple of listening UDP ports.
54 |
55 | 1. [Admin API](admin.md)
56 | 2. UDPInterface on my local docker0 bridge
57 | 3. Default UDPInterface listening on all interfaces
58 | 4. RainflyClient, which is dead code (admin/angel/Core.c:439 ff.)
59 |
60 |
61 | ## Network interface and routes
62 |
63 | ```
64 | # ifconfig tun0
65 | tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
66 | inet addr:192.168.223.2 P-t-P:192.168.223.2 Mask:255.255.255.255
67 | inet6 addr: fc06:c135:28a5:8c0b:dd4e:bcb6:d4d6:c96d/8 Scope:Global
68 | UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1312 Metric:1
69 | RX packets:1449 errors:0 dropped:0 overruns:0 frame:0
70 | TX packets:2289 errors:0 dropped:0 overruns:0 carrier:0
71 | collisions:0 txqueuelen:500
72 | RX bytes:1389870 (1.3 MB) TX bytes:310214 (310.2 KB)
73 |
74 | # netstat -nr
75 | fc00::/8 :: U 256 5 0 tun0
76 | fc06:c135:28a5:8c0b:dd4e:bcb6:d4d6:c96d/128 :: Un 0 2 254 lo
77 | ```
78 |
79 | We notice a few things about this TUN interface.
80 |
81 | 1. The lack of a link encapsulation (e.g. Ethernet) or MAC address (`HWaddr`). The `tun0` interface isn't backed by a physical interfaces, as `eth0` or `wlan0` are. It's backed by a userland process instead (cjdroute).
82 | 2. The `inet` and `P-t-P` addresses, which are assigned by cjdns' tunneling functionality: [IPTunnel](iptunnel.md)
83 | 3. The `RX` and `TX` values, which count the IP traffic received and transmitted by this cjdns node.
84 |
85 | The routes look a bit more obscure.
86 |
87 | 1. All packets for addresses starting with `fc` are handed to cjdns' TUN interface.
88 | 2. Packets addressed to the local `fc` address are redirected to loopback device (`lo`).
89 | That route is managed by the OS kernel and it's needed to actually send packets to local machine
90 | network stack. That's like the _self interface director_ used by cjdns.
91 |
--------------------------------------------------------------------------------
/contributing.md:
--------------------------------------------------------------------------------
1 | # Docs
2 |
3 | *Documenting things related to the meshnet*
4 |
5 | [cjdns](https://github.com/hyperboria/cjdns) addresses a large number of complex issues in an elegant way. While efforts have been made to provide a default configuration that matches the greatest number of use cases, it is impractical to expect software to replace understanding.
6 |
7 | > Enter the documentation project...
8 |
9 | The good citizens of Hyperboria decided to put together this collection of documentation to help make the inner workings of cjdns more transparent.
10 |
11 | We want you to [get involved](http://www.roaming-initiative.com/blog/posts/wtfm)! Feel free to submit pull requests.
12 |
13 | See [index.md](index.md) for current progress. We'd love more languages!
14 |
15 | Also have a look at [Prose for Programmers](https://github.com/joshuacc/prose-for-programmers), a work-in-progress book aimed at helping software developers write better prose.
16 |
17 |
18 | ## The scope of this project
19 |
20 | We are interested in documenting a range of topics:
21 |
22 | 1. cjdns internals: bugs and features
23 | 2. operator culture and best practices
24 | 3. meshlocal resources
25 | 4. introductory literature
26 |
27 |
28 | ## Reporting bugs
29 |
30 | [cjd](https://github.com/cjdelisle) would rather write code than troubleshoot trivial issues which often turn out to have resulted from user error. To make this easier, a few members of the community have offered to investigate issues on his behalf.
31 |
32 | If you think you've found a bug, report it on [our fork's issue tracker](https://github.com/hyperboria/cjdns/issues). We'll try to gather up documentation related to the issue, to better understand where it might be coming from. Once we can narrow it down, and research some of the background details to that particular piece of functionality, we may be able to submit patches ourselves.
33 |
34 | Anything you can submit that gets us closer to understanding some bug or function within cjdns is welcome. By starting an inquiry, you make it just a little bit easier for someone else to continue it. With that in mind, please read [this note on reporting bugs](bugs/reporting.md) and [our more general contribution policy](bugs/policy.md). Get involved!
35 |
36 | ## License
37 |
38 | Unless otherwise noted, the contained documents are licensed under a
39 | Creative Commons Attribution 4.0 Unported License.
40 |
41 | See [LICENSE.txt](LICENSE.txt), or <[creativecommons.org/licenses/by/4.0/](https://creativecommons.org/licenses/by/4.0/)>
42 |
43 |
44 | ## For committers
45 |
46 | Please remember that the canonical repo is at [gitboria.com/projectmeshnet/documentation](http://gitboria.com/projectmeshnet/documentation) in Hyperboria.
47 | Pull from there, and push there first.
48 | If the canonical repo and mirror at [github.com/hyperboria/docs](https://github.com/hyperboria/docs) diverge,
49 | the canonical repo's respective branch shall be force-pushed to the mirror.
50 |
51 | If you must create a new file, come talk to us on irc.fc00.io #documentation about where it should be located. If it deals with configuration of cjdns or the host system, it should be located in `config/`. Installation guides go in `install/`, bugs or quirks go in `bugs/`. Files **must** adhere to the existing naming scheme: `lower-case-with-hyphens.md` if they are to be accepted into the repository.
52 |
53 |
54 | ## Documentation in cjdns.git/doc
55 |
56 | This repository is semi-regularly merged into cjdns' `doc/` directory.
57 | It's useful to ship documentation with the code.
58 | We use the following commands.
59 |
60 | ```sh
61 | $ cd cjdns/
62 | $ git remote add hyperboria git@github.com:hyperboria/cjdns.git
63 | $ git remote add docs git@gitboria.com:projectmeshnet/docs.git
64 | ```
65 |
66 | To merge documentation changes into cjdns,
67 | we squash all new commits since the last merge into one commit,
68 | and merge that commit into master.
69 |
70 | ```sh
71 | $ git checkout master
72 | $ git pull hyperboria master
73 | $ git subtree pull --squash -P doc/ docs/master
74 | $ git push hyperboria master
75 | ```
76 |
77 | To merge documentation changes in cjdns back upstream into this repository,
78 | we create a merge commit, and push it.
79 |
80 | ```
81 | $ git subtree split -P doc/
82 | 38e3bc6f899de49213aed754c74046b9ae4a85d2
83 | $ git push docs 38e3bc6f:master
84 | ```
85 |
--------------------------------------------------------------------------------
/faq/doppleganger.md:
--------------------------------------------------------------------------------
1 | # How does cjdns handle duplicate nodes?
2 |
3 | `cow_2001` asks:
4 |
5 | > what happens if there are ip clones?
6 | >
7 | > does the network knows how to handle that?
8 |
9 | ## There are two ways that this can play out:
10 |
11 | 1. At least two nodes with identical ipv6 addresses, but different keys.
12 | 2. Two instances of the same public-private keypair (and necessarily the same ipv6) connected to the same network from different locations.
13 |
14 | ## Scenario one
15 |
16 | As addressed by `gloe-ih`:
17 |
18 | > the address is in the range of a hash function and, by definition, multiple keys can have the same fingerprint, however you'll not be able to establish a cryptoauth session with that node with the knowledge of another key
19 | > because you know that key1 -> addr, so you'll try to use key1 as the pubkey for that session, and the node owning key2, with the same addr, won't be able to decrypt
20 |
21 | So the session _should_ be rejected, but in reality this is incredibly hard to test. As far as we know, nobody has generated to distinct private keys with identical ipv6 addresses. The probability of someone doing so is incredibly low..
22 |
23 | > <@ircerr> ? lotto
24 | >
25 | > <@irbawt> lotto: 1 in 1,329,227,995,784,915,872,903,807,060,280,344,576 chance of generating the same IPv6. Feeling Lucky?
26 |
27 | ## Scenario two
28 |
29 | `cow_2001` asks:
30 |
31 | > won't the routing be all messed up because routing is address dependant?
32 |
33 | This hasn't really been tested, or, if it has been, nobody has reported their findings. Everything below is speculative, so if you find the answer, feel free to update this document.
34 |
35 | We expect that if two distinct nodes (using different ipv4 addresses if connecting via udp) cannot successfully connect to a common peer directly using the same configuration file. The common node won't know which connection to treat as the actual destination.
36 |
37 | If two nodes are launched, and they connect to different parts of the network using the same configuration file, then in theory they may both function. Since indirect connections are made using only a virtual address (your cjdns ipv6), the two nodes should be indistinguishable to anyone trying to connect to them.
38 |
39 | Cjdns works by using the first path it finds, then replacing that path if it finds a better one. It is commonly believed that if a node were to try to connect to that ipv6, they would first try to find a path to that node, then they would establish a cryptauth session. Whichever instance of a node it found first would establish this session.
40 |
41 | It's possible that the connecting node might find a path to each target node, but it wouldn't know the difference between them aside from the fact that it had established a cryptauth session with one but not the other. We are unsure of how it would handle that information, however, it might prevent the connecting node from flipping between two distinct sessions. This would be desirable, since doing so would probably wreak havoc on the higher level protocols being established over such a connection.
42 |
43 | If that's the case, then this could be used to provide an inherent [load balancing](https://en.wikipedia.org/wiki/Load_balancing_%28computing%29) effect.
44 |
45 | As noted above, this has not been thoroughly tested. Changes to the source code in the future could possibly make this impossible (via assertion failures). If it is currently a _property_ of cjdns, then the best way to ensure that it continues to function would be if someone were to take advantage of it, and report its breakage with future revisions.
46 |
47 | So please, give it a try, and let us know what you experience. Write about how you used this to your advantage, and go down in cjdns history!
48 |
49 | ```
50 | 09:55 < cow_2001> gloe-ih: yes
51 | 09:55 < gloe-ih> check if it bounds to the tun interface
52 | 09:56 < cow_2001> it has a build plan for x86_XVA or w/e it's called
53 | 09:56 < gloe-ih> (when running as root by default it spawns it)
54 | 09:56 < cow_2001> i don't want to run as root
55 | 09:56 < cow_2001> too scary
56 | 09:56 < gloe-ih> so follow the doc ;)
57 | 09:56 < cow_2001> i'm reading on configuration of the cjdroute.conf
58 | 09:57 < cow_2001> i've set up a tun thing for the cjdns user
59 | 09:57 < gloe-ih> you'll have to add addresses / routes manually
60 | ```
61 |
--------------------------------------------------------------------------------
/bugs/santa.md:
--------------------------------------------------------------------------------
1 | ## The Secret Santa Scenario
2 |
3 | This is a possible routing issue that may be related to the **black hole routing bug**. I (ansuz) decided to give it a distinct name because it may be an entirely different problem with the routing behaviour. More distinctive names are more likely to get remembered, and ∴ they are more likely to be _reported_. At least, that was my reasoning.
4 |
5 | ## The Expectation
6 |
7 | **cjdns** distributes a network's routing table across its constituent nodes. Individual nodes decide which other nodes they should keep track of by a combination of two main metrics:
8 |
9 | + a **logical** proximity metric (in which nodes which are a small number of hops away are considered close)
10 | + a **key-wise** proximity metric (in which nodes with similar addresses (by a xor metric) are considered close)
11 |
12 | The idea is that nodes should know which peers are logically proximal, for obvious reasons, but they should also track a number of distant peers which are chosen randomly. Rather than using continuous random functions, nodes capitalize on the assumption that private-key generation (upon which each node's ipv6 address is dependent) should be random. As such, we expect ipv6 addresses to be distributed without any predictable correlation to physical proximity.
13 |
14 | If a node **A** goes looking for a node **M**, **A** first checks if **M** is a logically proximal peer, then falls back to asking peers with similar keys if they know of a path to **M**. We expect that any node should be able to find any other node in `log(n)` lookups, where `n` is equal to the size of the network.
15 |
16 | ## The problem
17 |
18 | This method of distributing paths among nodes (aka constructing a Distributed Hash Table (**DHT**)), is based upon **[Kademlia](https://en.wikipedia.org/wiki/Kademlia)**. There may be a problem with this (this is the part where I bring Santa into it).
19 |
20 | Many of the world's nations have a holiday practice sometimes referred to as a [Secret Santa gift exchange](https://en.wikipedia.org/wiki/Secret_Santa). The premise is that some group of people (often the employees of some organization) each put their name into a receptacle. Once each member has inserted their name, they take turns removing a name (drawing again if they draw their own name). Once every member has received a name, they give gifts to their random recipient. When it goes well, everyone receives a gift.
21 |
22 | The assumption is that even if they do not know their chosen recipient well, they have enough common acquaintances that they can learn enough about them to deliver a suitable gift. Furthermore, it should go without saying that they should have the capacity to deliver this gift. The Kademlia method is generally implemented as a dynamic overlay network. Its member are assumed to have a path to one another.
23 |
24 | This is not the case with **cjdns**, as it is intended to be used to form a **[pseudonymous](https://en.wikipedia.org/wiki/Pseudonymity)** network. In other words, it is not guaranteed that there already exists a path to the their target node (or gift recipient, to return to the metaphor).
25 |
26 | ## Relying on chaos
27 |
28 | Suppose I need to find a node: I ask my peers, they ask their peers, and so on. Since their is not necessarily a common mode of communication shared between all nodes, there are edge cases in which we will never find the node in question. Despite the assurances that our random distribution **should** be even, it is possible that we are only able to see four hops away, and the nearest node which happens to have a path to the target node is 7 hops away. Nodes which are three hops from us **should** be able to see as far as we are able to (four hops), but in reality the directions in which they are able to see may not be in the right direction. They may be able to see further into one part of the network than another (like a car's blind spot, or in the eye of an individual afflicted with cataracts).
29 |
30 | To put this in human terms:
31 |
32 | * Our work is organizing a secret santa gift exchange.
33 | * We work for a multinational corporation.
34 | * We receive a name we aren't familiar with.
35 | * We ask around, nobody knows the individual in question.
36 | * We ask the human resources department, and they inform us they can't give away that information (it's private).
37 | * That person never gets a gift.
38 | * This happens through the company, and lots of people don't get gifts.
39 | * Bummer.
40 |
--------------------------------------------------------------------------------
/cjdns/changelog.md:
--------------------------------------------------------------------------------
1 | # Changelog for cjdns
2 |
3 | crashey is for development, master is rolling release
4 |
5 | A few words about Version.h
6 |
7 | Current state: 5fa245c - remove check code (Tue Feb 3 23:25:10 2015 +0100)
8 |
9 | ## v15 -- January 2015
10 |
11 | crashey since: 74e7b71 - Configurator should attempt a ping before beginning to setup the core (might fix startup errors for some people) (Fri Jan 23 23:45:04 2015 +0100)
12 |
13 | master since: 97161a5 - shitfuck missed a line (Thu Jan 29 19:25:39 2015 +0100)
14 |
15 | - The configurator now tries to ping the core process before starting to configure it.
16 | This might fix a possible race condition during cjdroute startup.
17 | - A bug with ETHInterface auto-peering has been fixed.
18 | - A segfault in peerStats has been fixed.
19 | - The `-O` cflag for build-time optimization has been fixed. It can now be set as
20 | `-O2` to optimize for performance, or `-Os` to optimize for disk space usage.
21 | - We now try to remember and use the last known route to a node.
22 | - Short-form IPv6 addresses are now supported.
23 | - The tools in `contrib/nodejs/tools/` have moved to `tools/`.
24 | - The sessionStats tool has been added; ping and traceroute tools can now resolve DNS domains.
25 | - The search tool has been added, and DHT searches are now available in the
26 | Admin API as `SearchRunner_search()`.
27 | - The ping and search tools now allow a `-c` option for setting the number searches
28 | or pings.
29 | - The Admin API functions `NodeStore_nodeForAddr()` and `NodeStore_getLink()` no
30 | longer require authentication.
31 |
32 | ## v14 -- January 2015
33 |
34 | crashey since: 670b047 - Fixed bug in getPeers which caused it to return the same peers every time (Sun Jan 18 17:13:53 2015 +0100)
35 |
36 | master since: 601b6cd - Oops, lets bump the version while we're at it (Fri Jan 23 07:47:05 2015 +0100)
37 |
38 | - The Hidden Peers bug has been fixed; it manifested in flapping peerings because
39 | of dropped pings on the switch layer.
40 | - A bug in NodeStore_getPeers() has been fixed, which caused it to always return
41 | the same peers.
42 | - `ETHInterface` can now bind to `all` network interfaces, and auto-peer on all
43 | of them, being more resistant against interface going down or up during runtime.
44 | - `ETHInterface` now also brings the respective interfaces up when starting.
45 | - A crash related to the bit alignment of switch ping error responses has been fixed.
46 | - The ping and pingAll tools have been improved, pingAll now performs both
47 | router and switch pings.
48 | - `InterfaceController` has been rewritten to allow for easier development of
49 | custom interfaces.
50 | - Documentation for debugging using traffic analysis has been added.
51 |
52 | ## v13 -- January 2015
53 |
54 | crashey since: bb06b63 - Added 2 new command line tools, traceroute and cjdnslog (Thu Jan 1 17:10:39 2015 +0100)
55 |
56 | master since: 185fe28 - Nodes trying to ping themselves causing crashes (Fri Jan 2 09:37:32 2015 +0100)
57 |
58 | - Nodes running v11 or below are not supported any longer. They can still
59 | establish peering to every other node (also v13), but from v13 on, their
60 | traffic won't be switched any longer. They also won't make it into v13 nodes'
61 | routing tables.
62 | - The ETHInterface wire protocol now includes the payload length. A few ethernet
63 | adapters don't strip the checksum which is appended to the packet by the
64 | sender, and thus confuse the decrypter.
65 | - `NodeStore_getBest()` no longer takes DHT k-buckets into accounts -- the
66 | respective code has been commented out. From the code comments:
67 |
68 | > The network is small enough that a per-bucket lookup is inefficient
69 | > Basically, the first bucket is likely to route through an "edge" node
70 | > In theory, it scales better if the network is large.
71 |
72 | - The Admin API function `InterfaceController_peerStats()` now includes the peer's
73 | `protocolVersion`, and doesn't require authentication any longer.
74 | - `cjdroute --genconf` now has an `--eth` switch which enables the ETHInterface
75 | and auto-peering.
76 | - There is now a script which adds peering passwords to both the config file and
77 | the running process, avoiding the otherwise neccessary restart:
78 | `contrib/bash/peers.sh user user@example.net `
79 | - Minor Fixes for Android
80 | - It's now possible to cross-compile for ARM, on an OSX host.
81 | - Documentation, and scripts in `contrib/` have been improved.
82 |
--------------------------------------------------------------------------------
/network-services.md:
--------------------------------------------------------------------------------
1 | # Self-check your network services
2 |
3 | Once your node is running, you are now a newly minted IPv6 host. Your operating
4 | system may automatically reconfigure network services to use this new address.
5 | Take control of the services your host is offering as described below.
6 |
7 | ## 1: Obtain IP address.
8 |
9 | Use `ifconfig -a` to find the IPv6 address of your TUN device. (Assigned by
10 | cjdroute.)
11 |
12 | ## 2: Scan for open services.
13 |
14 | Run `nmap` to discover which services are accessible from this address.
15 | For example, to scan the address fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe:
16 |
17 | nmap -6 -n -r -v -p1-65535 -sT fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe
18 |
19 | This should result in an output like the following.
20 |
21 | Starting Nmap 5.61TEST2 ( http://nmap.org ) at 2011-12-29 20:40 EST
22 | Initiating Connect Scan at 20:40
23 | Scanning fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe [65535 ports]
24 | Completed Connect Scan at 20:40, 4.38s elapsed (65535 total ports)
25 | Nmap scan report for fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe
26 | Host is up (0.00073s latency).
27 | All 65535 scanned ports on fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe are closed
28 |
29 | Read data files from: /usr/local/bin/../share/nmap
30 | Nmap done: 1 IP address (1 host up) scanned in 4.60 seconds
31 | Raw packets sent: 0 (0B) | Rcvd: 0 (0B)
32 |
33 | If you have open ports, you might see something more like this.
34 |
35 | Starting Nmap 6.47 ( http://nmap.org ) at 2015-06-04 09:52 UTC
36 | Initiating Ping Scan at 09:52
37 | Scanning fcde:c974:bde5:a226:b8a9:bd8:3e8:7df5 [2 ports]
38 | Completed Ping Scan at 09:52, 0.00s elapsed (1 total hosts)
39 | Initiating Connect Scan at 09:52
40 | Scanning fcde:c974:bde5:a226:b8a9:bd8:3e8:7df5 [65535 ports]
41 | Discovered open port 40499/tcp on fcde:c974:bde5:a226:b8a9:bd8:3e8:7df5
42 | Discovered open port 53529/tcp on fcde:c974:bde5:a226:b8a9:bd8:3e8:7df5
43 | Completed Connect Scan at 09:52, 4.66s elapsed (65535 total ports)
44 | Nmap scan report for fcde:c974:bde5:a226:b8a9:bd8:3e8:7df5
45 | Host is up (0.00079s latency).
46 | Not shown: 65533 closed ports
47 | PORT STATE SERVICE
48 | 40499/tcp open unknown
49 | 53529/tcp open unknown
50 |
51 | If port 22 were open, you could probably guess that SSH is responsible.
52 | But what the heck is using 40499? Here's how you figure that out.
53 | First, install `netstat` (`pacman -S net-tools` on Arch, for example).
54 | Second, run the following netcat command and read the lines that
55 | reference those ports.
56 |
57 | netstat -tulpn
58 |
59 | ## 3: If you see anything open, fix it.
60 |
61 | Examples for SSH and Samba are below.
62 |
63 | ### SSH
64 |
65 | Edit `/etc/ssh/sshd_config`:
66 |
67 | ListenAddress 192.168.1.1
68 |
69 | ^ Replace `192.168.1.1` in the example above
70 | with your STATIC IP (or map DHCP via MAC).
71 |
72 | ### Samba
73 |
74 | Edit `/etc/samba/smb.conf`:
75 |
76 | [global]
77 | interfaces = eth0
78 | bind interfaces only = Yes
79 |
80 | ^ This will cause Samba to not bind to `tun0`
81 | (or whichever TUN device you are using).
82 |
83 | ### Apache
84 |
85 | You will have to find the `Listen` directive in your Apache configuration,
86 | which is located in different files depending on your distribution and platform.
87 | Many distributions make Apache listen to all interfaces, IPv4 as well as IPv6:
88 |
89 | Listen 80
90 |
91 | You can change this to:
92 |
93 | Listen 192.168.1.1:80
94 |
95 | For example, to force Apache onto IPv4 addresses only for all of its hosts.
96 | If you wish to mix and match virtual hosts, exposing some via IPv6 and others
97 | only via IPv4, you can configure each virtual host separately:
98 |
99 |
100 | # configuration goes here
101 |
102 |
103 | Versus a virtual host in IPv4:
104 |
105 |
106 | # configuration goes here
107 |
108 |
109 | If you keep listening on all IP versions, make sure your default `DocumentRoot`
110 | points to something useful and not something sensitive, since Apache will fall
111 | back to that `DocumentRoot` if none of your virtual hosts matches an incoming
112 | request.
113 |
114 |
115 | ### Lighttpd
116 |
117 | Comment out the following line in `/etc/lighttpd/lighttpd.conf`:
118 |
119 | include_shell "/usr/share/lighttpd/use-ipv6.pl"
120 |
121 | Thats it for now! Got More? Tell us on IRC.
122 |
--------------------------------------------------------------------------------
/config/network-services.md:
--------------------------------------------------------------------------------
1 | # Self-check your network services
2 |
3 | Once your node is running, you are now a newly minted IPv6 host. Your operating
4 | system may automatically reconfigure network services to use this new address.
5 | Take control of the services your host is offering as described below.
6 |
7 | ## 1: Obtain IP address.
8 |
9 | Use `ifconfig -a` to find the IPv6 address of your TUN device. (Assigned by
10 | cjdroute.)
11 |
12 | ## 2: Scan for open services.
13 |
14 | Run `nmap` to discover which services are accessible from this address.
15 | For example, to scan the address fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe:
16 |
17 | nmap -6 -n -r -v -p1-65535 -sT fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe
18 |
19 | This should result in an output like the following.
20 |
21 | Starting Nmap 5.61TEST2 ( http://nmap.org ) at 2011-12-29 20:40 EST
22 | Initiating Connect Scan at 20:40
23 | Scanning fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe [65535 ports]
24 | Completed Connect Scan at 20:40, 4.38s elapsed (65535 total ports)
25 | Nmap scan report for fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe
26 | Host is up (0.00073s latency).
27 | All 65535 scanned ports on fcf7:75f0:82e3:327c:7112:b9ab:d1f9:bbbe are closed
28 |
29 | Read data files from: /usr/local/bin/../share/nmap
30 | Nmap done: 1 IP address (1 host up) scanned in 4.60 seconds
31 | Raw packets sent: 0 (0B) | Rcvd: 0 (0B)
32 |
33 | If you have open ports, you might see something more like this.
34 |
35 | Starting Nmap 6.47 ( http://nmap.org ) at 2015-06-04 09:52 UTC
36 | Initiating Ping Scan at 09:52
37 | Scanning fcde:c974:bde5:a226:b8a9:bd8:3e8:7df5 [2 ports]
38 | Completed Ping Scan at 09:52, 0.00s elapsed (1 total hosts)
39 | Initiating Connect Scan at 09:52
40 | Scanning fcde:c974:bde5:a226:b8a9:bd8:3e8:7df5 [65535 ports]
41 | Discovered open port 40499/tcp on fcde:c974:bde5:a226:b8a9:bd8:3e8:7df5
42 | Discovered open port 53529/tcp on fcde:c974:bde5:a226:b8a9:bd8:3e8:7df5
43 | Completed Connect Scan at 09:52, 4.66s elapsed (65535 total ports)
44 | Nmap scan report for fcde:c974:bde5:a226:b8a9:bd8:3e8:7df5
45 | Host is up (0.00079s latency).
46 | Not shown: 65533 closed ports
47 | PORT STATE SERVICE
48 | 40499/tcp open unknown
49 | 53529/tcp open unknown
50 |
51 | If port 22 were open, you could probably guess that SSH is responsible.
52 | But what the heck is using 40499? Here's how you figure that out.
53 | First, install `netstat` (`pacman -S net-tools` on Arch, for example).
54 | Second, run the following netcat command and read the lines that
55 | reference those ports.
56 |
57 | netstat -tulpn
58 |
59 | ## 3: If you see anything open, fix it.
60 |
61 | Examples for SSH and Samba are below.
62 |
63 | ### SSH
64 |
65 | Edit `/etc/ssh/sshd_config`:
66 |
67 | ListenAddress 192.168.1.1
68 |
69 | ^ Replace `192.168.1.1` in the example above
70 | with your STATIC IP (or map DHCP via MAC).
71 |
72 | ### Samba
73 |
74 | Edit `/etc/samba/smb.conf`:
75 |
76 | [global]
77 | interfaces = eth0
78 | bind interfaces only = Yes
79 |
80 | ^ This will cause Samba to not bind to `tun0`
81 | (or whichever TUN device you are using).
82 |
83 | ### Apache
84 |
85 | You will have to find the `Listen` directive in your Apache configuration,
86 | which is located in different files depending on your distribution and platform.
87 | Many distributions make Apache listen to all interfaces, IPv4 as well as IPv6:
88 |
89 | Listen 80
90 |
91 | You can change this to:
92 |
93 | Listen 192.168.1.1:80
94 |
95 | For example, to force Apache onto IPv4 addresses only for all of its hosts.
96 | If you wish to mix and match virtual hosts, exposing some via IPv6 and others
97 | only via IPv4, you can configure each virtual host separately:
98 |
99 |
100 | # configuration goes here
101 |
102 |
103 | Versus a virtual host in IPv4:
104 |
105 |
106 | # configuration goes here
107 |
108 |
109 | If you keep listening on all IP versions, make sure your default `DocumentRoot`
110 | points to something useful and not something sensitive, since Apache will fall
111 | back to that `DocumentRoot` if none of your virtual hosts matches an incoming
112 | request.
113 |
114 |
115 | ### Lighttpd
116 |
117 | Comment out the following line in `/etc/lighttpd/lighttpd.conf`:
118 |
119 | include_shell "/usr/share/lighttpd/use-ipv6.pl"
120 |
121 | Thats it for now! Got More? Tell us on IRC.
122 |
--------------------------------------------------------------------------------
/shorewall_and_vpn_gateway_howto.md:
--------------------------------------------------------------------------------
1 | # Shorewall and VPN gateway
2 | Tutorial for setting up an IP tunnel gateway from cjdns to clearnet, using a VPN and Shorewall.
3 |
4 | * From: https://wiki.projectmeshnet.org/Gateway_server_howto
5 |
6 | ##General
7 | * Close any open ports also on IPv6, e.g.:
8 | `ip6tables -A INPUT -i tun0 -p tcp --destination-port 22 -j REJECT`
9 |
10 | ##VPN
11 | Connect to a VPN provider (I used mullvad.net). Make sure you can pay with bitcoins. Recommended connection: openvpn.
12 |
13 | ##Firewall (shorewall)
14 | ###Interfaces
15 | ```
16 | #ZONE INTERFACE BROADCAST OPTIONS
17 | net eth0 detect routefilter,dhcp,tcpflags,logmartians,nosmurfs
18 | cjdns tun0 detect routefilter,dhcp,tcpflags,logmartians,nosmurfs
19 | vpn tun1 detect routefilter,dhcp,tcpflags,logmartians,nosmurfs
20 | ```
21 | ###Zones
22 | ```
23 | #ZONE TYPE OPTIONS IN OUT
24 | # OPTIONS OPTIONS
25 | fw firewall
26 | net ipv4
27 | cjdns ipv4
28 | vpn ipv4
29 | ```
30 | ###Policy
31 | ```
32 | #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
33 | $FW net ACCEPT
34 | $FW vpn ACCEPT
35 | cjdns vpn ACCEPT
36 | vpn cjdns DROP info
37 | net $FW DROP info
38 | vpn $FW DROP info
39 | cjdns $FW DROP info
40 | $FW cjdns DROP info
41 | net all DROP info
42 | # The FOLLOWING POLICY MUST BE LAST
43 | all all REJECT info
44 | ```
45 | ###Rules
46 | ```
47 | #ACTION SOURCE DEST PROTO DEST
48 | # PORT
49 | # Cjdns over vpn:
50 | ACCEPT vpn $FW udp 31777
51 | # ping
52 | ACCEPT net $FW icmp 8
53 | # Reject Ping from the "bad" net zone.. and prevent your log from being flooded..
54 | Ping/REJECT net $FW
55 | # Permit all ICMP traffic FROM the firewall TO the net zone
56 | ACCEPT $FW net icmp
57 | ACCEPT $FW cjdns icmp
58 | ACCEPT cjdns $FW icmp
59 | ```
60 | ##Networking
61 | Give an IPV4 address to the server side of the cjdns tunnel:
62 |
63 | `ip addr add 10.42.0.3/32 dev tun0`
64 |
65 | Add route to each client side of the cjdns tunnel:
66 |
67 | `ip route add 10.42.42.42 via 10.42.0.3 dev tun0`
68 |
69 | Set forwarding on:
70 |
71 | `echo 1 > /proc/sys/net/ipv4/conf/all/forwarding`
72 |
73 | Add vpn address:
74 |
75 | `route add $VPN_ENTRY_ADDRESS gateway $SERVER_REAL_ADDRESS`
76 |
77 | The default gw for the clients (to vpn):
78 |
79 | `ip addr add 10.42.0.1/32 dev tun1`
80 |
81 | Masqurading (NAT):
82 |
83 | `iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE`
84 |
85 | Remove original gateway:
86 | ```
87 | GW=`route -n | grep ^0.0.0.0 | awk -F ' ' '{ print $2 }'`
88 | route del default gw $GW
89 | ```
90 | Use DNS server from VPN provider to avoid leaks:
91 | `cp /etc/resolv.conf.vpn /etc/resolv.conf`
92 |
93 | ##Add user
94 |
95 |
96 | For convenience, I check the last 20 characters of the public key (not including .k) e.g.:
97 | ```
98 | publicKey="lsvf85b3bg9fwy74sdlbqyhlt5n7w32s4m1mwsxggjx5kfzfk120.k"
99 | NODE=${publicKey: -22:22}
100 | echo $NODE
101 | 4m1mwsxggjx5kfzfk120.k
102 | ```
103 | And I use it as part of the password added to cjdroute.conf under "authorizedPasswords":
104 | `{"password":"4m1mwsxggjx5kfzfk120.k.foobarpassword"},`
105 |
106 | And under `ipTunnel` `allowedConnections`:
107 | ```
108 | {
109 | "publicKey": "lsvf85b3bg9fwy74sdlbqyhlt5n7w32s4m1mwsxggjx5kfzfk120.k",
110 | "ip4Address": "10.42.something.else",
111 | },
112 | ```
113 | ##Quota
114 |
115 | Add a user
116 | ```
117 | # Check if chain exists
118 | iptables -L | grep $NODE && exit 0
119 | # Add the user
120 | iptables -N $NODE
121 | iptables -I cjdns2vpn 1 -s $IP -j $NODE
122 | iptables -I vpn2cjdns 1 -d $IP -j $NODE
123 | iptables -I $NODE 1 -j DROP
124 | iptables -I $NODE 1 -m quota --quota $QUOTA -j ACCEPT
125 | ```
126 | Delete a user:
127 | ```
128 | # Check if chain exists
129 | iptables -L | grep $NODE || exit 0
130 | # Delete the user
131 | iptables -D $NODE -j DROP
132 | iptables -D $NODE -m quota --quota $QUOTA -j ACCEPT
133 | iptables -D cjdns2vpn -s $IP -j $NODE
134 | iptables -D vpn2cjdns -d $IP -j $NODE
135 | iptables -X $NODE
136 | ```
137 | Reset user's quota:
138 | `iptables -R $NODE 1 -m quota --quota $QUOTA -j ACCEPT`
139 |
--------------------------------------------------------------------------------
/config/shorewall-and-vpn-gateway-howto.md:
--------------------------------------------------------------------------------
1 | # Shorewall and VPN gateway
2 | Tutorial for setting up an IP tunnel gateway from cjdns to clearnet, using a VPN and Shorewall.
3 |
4 | * From: https://wiki.projectmeshnet.org/Gateway_server_howto
5 |
6 | ##General
7 | * Close any open ports also on IPv6, e.g.:
8 | `ip6tables -A INPUT -i tun0 -p tcp --destination-port 22 -j REJECT`
9 |
10 | ##VPN
11 | Connect to a VPN provider (I used mullvad.net). Make sure you can pay with bitcoins. Recommended connection: openvpn.
12 |
13 | ##Firewall (shorewall)
14 | ###Interfaces
15 | ```
16 | #ZONE INTERFACE BROADCAST OPTIONS
17 | net eth0 detect routefilter,dhcp,tcpflags,logmartians,nosmurfs
18 | cjdns tun0 detect routefilter,dhcp,tcpflags,logmartians,nosmurfs
19 | vpn tun1 detect routefilter,dhcp,tcpflags,logmartians,nosmurfs
20 | ```
21 | ###Zones
22 | ```
23 | #ZONE TYPE OPTIONS IN OUT
24 | # OPTIONS OPTIONS
25 | fw firewall
26 | net ipv4
27 | cjdns ipv4
28 | vpn ipv4
29 | ```
30 | ###Policy
31 | ```
32 | #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
33 | $FW net ACCEPT
34 | $FW vpn ACCEPT
35 | cjdns vpn ACCEPT
36 | vpn cjdns DROP info
37 | net $FW DROP info
38 | vpn $FW DROP info
39 | cjdns $FW DROP info
40 | $FW cjdns DROP info
41 | net all DROP info
42 | # The FOLLOWING POLICY MUST BE LAST
43 | all all REJECT info
44 | ```
45 | ###Rules
46 | ```
47 | #ACTION SOURCE DEST PROTO DEST
48 | # PORT
49 | # Cjdns over vpn:
50 | ACCEPT vpn $FW udp 31777
51 | # ping
52 | ACCEPT net $FW icmp 8
53 | # Reject Ping from the "bad" net zone.. and prevent your log from being flooded..
54 | Ping/REJECT net $FW
55 | # Permit all ICMP traffic FROM the firewall TO the net zone
56 | ACCEPT $FW net icmp
57 | ACCEPT $FW cjdns icmp
58 | ACCEPT cjdns $FW icmp
59 | ```
60 | ##Networking
61 | Give an IPV4 address to the server side of the cjdns tunnel:
62 |
63 | `ip addr add 10.42.0.3/32 dev tun0`
64 |
65 | Add route to each client side of the cjdns tunnel:
66 |
67 | `ip route add 10.42.42.42 via 10.42.0.3 dev tun0`
68 |
69 | Set forwarding on:
70 |
71 | `echo 1 > /proc/sys/net/ipv4/conf/all/forwarding`
72 |
73 | Add vpn address:
74 |
75 | `route add $VPN_ENTRY_ADDRESS gateway $SERVER_REAL_ADDRESS`
76 |
77 | The default gw for the clients (to vpn):
78 |
79 | `ip addr add 10.42.0.1/32 dev tun1`
80 |
81 | Masqurading (NAT):
82 |
83 | `iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE`
84 |
85 | Remove original gateway:
86 | ```
87 | GW=`route -n | grep ^0.0.0.0 | awk -F ' ' '{ print $2 }'`
88 | route del default gw $GW
89 | ```
90 | Use DNS server from VPN provider to avoid leaks:
91 | `cp /etc/resolv.conf.vpn /etc/resolv.conf`
92 |
93 | ##Add user
94 |
95 |
96 | For convenience, I check the last 20 characters of the public key (not including .k) e.g.:
97 | ```
98 | publicKey="lsvf85b3bg9fwy74sdlbqyhlt5n7w32s4m1mwsxggjx5kfzfk120.k"
99 | NODE=${publicKey: -22:22}
100 | echo $NODE
101 | 4m1mwsxggjx5kfzfk120.k
102 | ```
103 | And I use it as part of the password added to cjdroute.conf under "authorizedPasswords":
104 | `{"password":"4m1mwsxggjx5kfzfk120.k.foobarpassword"},`
105 |
106 | And under `ipTunnel` `allowedConnections`:
107 | ```
108 | {
109 | "publicKey": "lsvf85b3bg9fwy74sdlbqyhlt5n7w32s4m1mwsxggjx5kfzfk120.k",
110 | "ip4Address": "10.42.something.else",
111 | },
112 | ```
113 | ##Quota
114 |
115 | Add a user
116 | ```
117 | # Check if chain exists
118 | iptables -L | grep $NODE && exit 0
119 | # Add the user
120 | iptables -N $NODE
121 | iptables -I cjdns2vpn 1 -s $IP -j $NODE
122 | iptables -I vpn2cjdns 1 -d $IP -j $NODE
123 | iptables -I $NODE 1 -j DROP
124 | iptables -I $NODE 1 -m quota --quota $QUOTA -j ACCEPT
125 | ```
126 | Delete a user:
127 | ```
128 | # Check if chain exists
129 | iptables -L | grep $NODE || exit 0
130 | # Delete the user
131 | iptables -D $NODE -j DROP
132 | iptables -D $NODE -m quota --quota $QUOTA -j ACCEPT
133 | iptables -D cjdns2vpn -s $IP -j $NODE
134 | iptables -D vpn2cjdns -d $IP -j $NODE
135 | iptables -X $NODE
136 | ```
137 | Reset user's quota:
138 | `iptables -R $NODE 1 -m quota --quota $QUOTA -j ACCEPT`
139 |
--------------------------------------------------------------------------------
/djc-layer-model.md:
--------------------------------------------------------------------------------
1 | # DJC Layer Model
2 |
3 | Note: This is not implemented yet.
4 |
5 | ## LayerA
6 | Communication between peers, this layer is only of interest to the two peers which are
7 | directly communicating. No information in this layer is directly passed on to the next
8 | peer in the path. This layer is expected to provide packet length information to all
9 | higher layers. Although this layer traditionally contains UDP or Ethernet headers, any
10 | means of framing and point-to-point transport is acceptable.
11 |
12 | Examples of headers which fall in this layer are:
13 |
14 | UDPInterface:
15 |
16 | [ IP ][ UDP ][ CryptoAuth ]
17 |
18 | ETHInterface:
19 |
20 | [ ETH Header ][ CryptoAuth ]
21 |
22 | Direct over phy (future):
23 |
24 | [ SyncMagic ][ Length ][ CryptoAuth ]
25 |
26 |
27 | ## LayerB
28 | Switch Layer, this layer is seen by all switches along a direct path as well as the routers
29 | at the ends of the path but when a router forwards the packet on, headers at this layer are
30 | replaced with new ones just as the Ethernet header is replaced by each IP router.
31 |
32 | This layer contains:
33 |
34 | [ SwitchHeader ]
35 |
36 |
37 | ## LayerC
38 | Inter-Router Layer, this layer is only of interest to the routers which will forward the packet.
39 | No data in this layer is directly forwarded on to the final endpoints or downstream routers
40 | and no data at this layer or below it can be accessed by the switches due to a CryptoAuth header
41 | which begins this layer. Since the width of a CryptoSessionHeader depends on the state of the
42 | CryptoAuth session represented, a router should only forward packets to another router after
43 | the CryptoAuth session with that router has entered into the ESTABLISHED state in order to prevent
44 | fluctuating MTU.
45 |
46 | [ CryptoSessionHeader ]
47 |
48 | ### LayerC Control Packet
49 | In order for switches to send error and other control messages, a branch of *LayerC* exists which
50 | does not contain encrypted data, in place of the CryptoSessionHeader are the four bytes `0xffffffff`
51 | followed by a Control packet (see Control.h for details). The four bytes `0xffffffff` in a
52 | CryptoSessionHeader have a meaning, they indicate intent to begin a CryptoAuth session without
53 | knowing the key of the other end, it is however illegal to begin a session at *LayerC* without
54 | knowing the peer's key so this value is repurposed to indicate presence of a Control packet.
55 |
56 |
57 | ## LayerD
58 | Routing Layer, this layer is of interest both to the routers which will forward the packet
59 | and to the final endpoints. The endpoints can use data placed in this layer to communicate with
60 | the intermediary routers and routers can use it to communicate back to the endpoints.
61 |
62 | This layer contains:
63 |
64 | [ RouteHeader ]
65 |
66 | NOTE: In versions previous to v9, RouteHeader is replaced with an IPv6 header.
67 |
68 |
69 | ## LayerE
70 | Data layer, this layer is only of interest to the sender and the recipient. It it protected by
71 | a CryptoAuth layer which prevents intermediate routers from accessing the data therein.
72 |
73 | This layer contains:
74 |
75 | [ CryptoSessionHeader ][ DataHeader ][ TCP/UDP/other ][ user's data ]
76 |
77 | If the sender is using a direct path (through the switch fabric) to the recipient,
78 | the CryptoSessionHeader is omitted and in it's place are the four bytes `0xfffffffe` in
79 | big endian form. In this case, the identity of the sender is to be determined by examining
80 | the CryptoSessionHeader at *LayerC*.
81 |
82 | Note: In versions previous to v9, the CryptoSessionHeader was replaced with a CryptoAuth
83 | header and the DataHeader was omitted. In the event of a direct path send, as described above,
84 | the CryptoAuth header was omitted with no replacement and the recipient was expected to detect
85 | the state by comparing the source field in the *LayerD* IPv6 header with the identity of the
86 | sending router as determined from the CryptoSessionHeader at *LayerC*.
87 |
88 |
89 | ## CryptoSessionHeader
90 |
91 | As there is no CryptoSessionHeader.h, the nature of the CryptoSessionHeader is explained here.
92 | There are two types of CryptoSessionHeader, one is a setup packet header which is 124 bytes long,
93 | the other is the run packet header, which is 24 bytes long. The type of the individual packet is
94 | determined by the first four bytes.
95 |
96 | If the first 4 bytes as a big endian integer are greater than or equal to 4 and
97 | not equal to `0xffffffff`, the message is a run message and the first 4 bytes are
98 | a handle. Otherwise it is a start message and the first 4 bytes are the
99 | CryptoAuth session state.
100 |
101 |
102 |
103 |
104 | [ IP ] 20
105 | [ UDP ] 8
106 | [ CryptoAuth ] 20
107 | [ SwitchHeader ] 12
108 | [ CryptoSessionHeader ] 24
109 | [ RouteHeader ] 20
110 | [ CryptoSessionHeader ] 24/124
111 | [ DataHeader ] 4
112 | [ TCP/UDP/other ]
113 | [ user's data ]
114 |
--------------------------------------------------------------------------------
/bugs/connectTo-overflow.md:
--------------------------------------------------------------------------------
1 | ## cjdns connectTo buffer overflow bug
2 |
3 | I (and [several others](https://github.com/cjdelisle/cjdns/issues/701)) experienced an issue where cjdroute would fail to launch, with the following error:
4 |
5 | ```
6 | ...
7 | 1423794312 INFO cjdroute2.c:560 Forking angel to background.
8 | 1423794312 DEBUG Pipe.c:135 Buffering a message
9 | 1423794312 DEBUG cjdroute2.c:597 Sent [204] bytes to angel process
10 | 1423794312 DEBUG Pipe.c:232 Pipe [/tmp/cjdns_pipe_client-angel-yubd7j5m8vvjn3fju1nvw47v316g05] established connection
11 | 1423794312 DEBUG Pipe.c:254 Sending buffered message
12 | 1423794312 DEBUG AdminClient.c:333 Connecting to [127.0.0.1:11234]
13 | 1423794312 DEBUG UDPAddrInterface.c:293 Bound to address [0.0.0.0:36018]
14 | 1423794317 CRITICAL Configurator.c:96 Failed to make function call [Timed out waiting for a response], error: [UDPInterface_beginConnection]
15 | 1423794317 CRITICAL Configurator.c:56 enable Log_LEVEL=KEYS to see message content.
16 | 1423794317 CRITICAL Configurator.c:70 Aborting.
17 | ```
18 |
19 | ## The cause
20 |
21 | After some trial and error, I narrowed the cause of the factor down to a particular block in the `connectTo` section of my configuration file.
22 |
23 | ```javascript
24 | "192.168.10.102:6447":
25 | {
26 | "password":"anArbitraryPasswordOfThisLength",
27 | "publicKey":"3kcy5s4fvp6f1tzx2f9llm0dp19y4xz1z9t1rftf45103s2b7670.k",
28 | "operator":"aLargeNumberOfAliasesforAUser",
29 | "contact":"aNodeOperator@anEmail.tld",
30 | "location":"aVerboseDescriptionOfAPhysicalLocation",
31 | "ipv6":"fc00:0000:0000:0000:0000:0000:0000:0000"
32 | }
33 | ```
34 |
35 | At first I commented out the `"ipv6"` line, and suddenly my node was able to launch. Using **pigeon logic**, I figured that perhaps "ipv6" had some special significance in an outgoing connectTo block. I tried making it "IPV6" instead, and padded the ipv6 with missing zeros to bring it up to the standard 39 character representation. Nothing worked.
36 |
37 | At this point, I just commented out the ipv6 field, and relaunched the node. It worked, and for a while I was happy enough with that solution, but I wanted to understand what was happening.
38 |
39 | I asked [cjd](https://github.com/cjdelisle/) and he suggested commenting out a different field instead. Surely enough, commenting out any member of the data structure (other than those that are required by the cjdns angel) was enough to make the configuration file valid.
40 |
41 | So as it turns out, the error occurred as a result of the length of the bencoded packet being sent to the angel exceeding the hard limit of the length of a UDP packet. Again, at **cjd**'s suggestion, I used a commonly available tool to diagnose the issue:
42 |
43 |
44 | ## How to do it yourself
45 |
46 | **excerpted from IRC logs**
47 |
48 | ```
49 | 10:49 <@__cjd__> did you tcpdump lo ?
50 | 10:49 <@__cjd__> tcpdump -A -s0 -i lo
51 | ```
52 |
53 | I personally ran `sudo tcpdump -A -s0 -i lo > connectTo.overflow.log`, then attempted to launch cjdns using my `buggy.conf`.
54 |
55 | ## What the traffic looks like
56 |
57 | ```
58 | E..'..@.@.............+....'d0000006:cookie10:13904808324:hash64:723280ffa58bd47ce5dad1f42199fe3d3ff73c4e9fd6859d342b872f31c848ab1:q4:auth2:aq28:UDPInterface_beginConnection4:argsd7:address19:192.168.10.102:644715:interfaceNumberi0e4:ipv639:fc00:0000:0000:0000:0000:0000:0000:00008:location38:aVerboseDescriptionOfAPhysicalLocation7:contact25:aNodeOperator@anEmail.tld8:operator40:anEspeciallyVerboseListOfAliasesForAUser9:publicKey54:3kcy5s4fvp6f1tzx2f9llm0dp19y4xz1z9t1rftf45103s2b7670.k8:password31:anArbitraryPasswordOfThisLengthe4:txid8:07000000e
59 | 13:32:52.313755 IP localhost.11234 > localhost.34563: UDP, length 28
60 | E..8..@.@...........+....$.7d5:error16:Request too big.e
61 | ```
62 |
63 | ## A successful conf
64 |
65 | I shortened this `connectTo` block one character at a time until `cjdroute` launched successfully. This block is the maximum length that passes.
66 |
67 | ```javascript
68 | "192.168.10.102:6447":
69 | {
70 | "password":"anArbitraryPasswordOfThisLength",
71 | "publicKey":"3kcy5s4fvp6f1tzx2f9llm0dp19y4xz1z9t1rftf45103s2b7670.k",
72 | "operator":"a_ShorterListOfAliasesForAUser",
73 | "contact":"aNodeOperator@anEmail.tld",
74 | "location":"aVerboseDescriptionOfAPhysicalLocation",
75 | "ipv6":"fc00:0000:0000:0000:0000:0000:0000:0000"
76 | }
77 | ```
78 |
79 | The `bencode`d form is displayed below:
80 |
81 | ```
82 | E.....@.@.yS.........X+.....d6:cookie10:13904809584:hash64:7f050f5968df6d94c2cd044625e00b10d066555eee5bb5fbdc5f763e256126891:q4:auth2:aq28:UDPInterface_beginConnection4:argsd7:address19:192.168.10.102:644715:interfaceNumberi0e4:ipv639:fc00:0000:0000:0000:0000:0000:0000:00008:location38:aVerboseDescriptionOfAPhysicalLocation7:contact25:aNodeOperator@anEmail.tld8:operator30:a_ShorterListOfAliasesForAUser9:publicKey54:3kcy5s4fvp6f1tzx2f9llm0dp19y4xz1z9t1rftf45103s2b7670.k8:password31:anArbitraryPasswordOfThisLengthe4:txid8:07000000e
83 | 13:35:01.776419 IP localhost.11234 > localhost.53848: UDP, length 36
84 | E..@..@.@.{)........+..X.,.?d000005:error4:none4:txid8:07000000e
85 | ```
86 |
87 | ## Conclusion
88 |
89 | Keep your connectTo sections short! It's useful to have an ipv6, a contact, and a nick for a user. If you want to add a "location" field, add it in an abbreviated form, like `"location":"Toronto,CA"`.
90 |
--------------------------------------------------------------------------------
/nat-gateway.md:
--------------------------------------------------------------------------------
1 | # CJDNS NAT Gateway
2 |
3 | *Guide courtesy of [hyperboria.name](http://hyperboria.name/gateway) with minor
4 | edits.*
5 |
6 | Configure a host to act as a NAT gateway to provide access to Hyperboria for
7 | devices on your LAN (Windows PC, tablet, smart phone).
8 |
9 | This is a guide to setting up Ubuntu 13.04 to act as an IPv6 router and NAT
10 | gateway for CJDNS. Those who prefer other distros should find it trivial to
11 | adapt these instructions as required. If you do not have a linux server on your
12 | LAN already, consider purchasing a BeagleBone Black (for only $45 dollars!).
13 | You can find instructions [here](http://hyperboria.name/bbb/) on how to set it
14 | up for CJDNS.
15 |
16 | **WARNING**: The built-in security and encryption of CJDNS will **NOT**
17 | carry over past the gateway. Use of a NAT gateway for CJDNS should **ONLY**
18 | be done on a secure and trusted LAN. Any device on the LAN could theoretically
19 | intercept local CJDNS traffic before it reaches the gateway, and all devices
20 | will appear to other CJDNS nodes to *BE* the gateway node. This is intended
21 | to be a temporary solution until more universal compatibility is available for
22 | CJDNS.
23 |
24 | You will need:
25 |
26 | * One device running Ubuntu 13.04 and connected to your LAN
27 |
28 | *OR*
29 |
30 | * One device running the linux of your choice with kernel 3.7 or later and
31 | connected to your LAN
32 | * Sufficient knowledge to adapt this guide to your prefered linux
33 |
34 | ## Update and Configure iptables
35 |
36 | You will find it much easier to do this as root rather then using sudo, so run
37 | `sudo -i` first.
38 |
39 | You will need iptables 1.4.17 or better to properly configure IPv6 NAT with
40 | masqurade. Unfortunately, the latest Ubuntu as of the writing of this guide
41 | (13.04) only has 1.4.12, so you will need to download and install these
42 | packages (in order) before continuing:
43 |
44 | wget http://ftp.us.debian.org/debian/pool/main/libn/libnfnetlink/libnfnetlink0_1.0.1-2_armhf.deb
45 | dpkg -i libnfnetlink0_1.0.1-2_armhf.deb
46 |
47 | wget http://mirrors.kernel.org/debian/pool/main/i/iptables/libxtables10_1.4.18-1_armhf.deb
48 | dpkg -i libxtables10_1.4.18-1_armhf.deb
49 |
50 | wget http://mirrors.kernel.org/debian/pool/main/i/iptables/iptables_1.4.18-1_armhf.deb
51 | dpkg -i iptables_1.4.18-1_armhf.deb
52 |
53 | Obviously this will not be necessary if you already have iptables 1.4.17 or
54 | later installed. You can confirm your version by running the following command:
55 |
56 | iptables --version
57 |
58 | Also note that you will need linux kernel 3.7 or later to have support for IPv6
59 | NAT at all.
60 |
61 | Next you need to enable forwarding for IPv6:
62 |
63 | echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
64 |
65 | Make it permenant by editing `/etc/sysctl.conf` to include the following line:
66 |
67 | net.ipv6.conf.all.forwarding=1
68 |
69 | You will most likely find it in there already, but commented out. Simply remove
70 | the "#".
71 |
72 | Now enter the ip6tables rules:
73 |
74 | ip6tables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
75 | ip6tables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
76 | ip6tables -A FORWARD -i eth1 -o eth0 -j ACCEPT
77 |
78 | Save the rules:
79 |
80 | ip6tables-save > /etc/network/ip6tables.rules
81 |
82 | Create the file `/etc/network/if-pre-up.d/ip6tables` containing the following:
83 |
84 | #!/bin/sh
85 | ip6tables-restore < /etc/network/ip6tables.rules
86 | exit 0
87 |
88 | And make it executable:
89 |
90 | chmod +x /etc/network/if-pre-up.d/ip6tables
91 |
92 | Now iptables is configured as an IP v6 NAT gateway, and the settings will be
93 | preserved through reboots.
94 |
95 | ## Install and Configure radvd
96 |
97 | Install radvd so that your gateway advertises itself on the network:
98 |
99 | apt-get install radvd
100 |
101 | Create (or edit if already present) the file `/etc/radvd.conf` with the
102 | following contents:
103 |
104 | interface eth0
105 | {
106 | AdvSendAdvert on;
107 | prefix fdfc::1/64
108 | {
109 | AdvRouterAddr on;
110 | };
111 | };
112 |
113 | Note that this assumes you will be using the eth0 interface. If your LAN
114 | interface is different, you need to replace eth0 with the correct one.
115 |
116 | Start/restart radvd:
117 |
118 | /etc/init.d/radvd restart
119 |
120 | Now IPv6 capable computers and devices should configure themselves to use your
121 | gateway automatically as soon as they are connected to the network.
122 |
123 | To ensure proper routing, however, the interface needs the right IP assigned to
124 | it. Edit the file `/etc/network/interfaces` to include the following:
125 |
126 | iface eth0 inet6 static
127 | pre-up modprobe ipv6
128 | address fdfc:0000:0000:0000:0000:0000:0000:0001
129 | netmask 64
130 |
131 | Once again, this assumes your LAN interface is eth0. Adjust as required.
132 | At this point, it is recommended that you reboot so you can confirm everything
133 | is still working:
134 |
135 | reboot
136 |
137 | Don't forget to start CJDNS after it's done booting if you haven't set it up to
138 | start automatically. Alternatively, if you do not want to reboot at this time,
139 | you can run the following command to assign the IP address to the interface
140 | manually:
141 |
142 | ip addr add fdfc::1/64 dev eth0
143 |
144 | You may need to disconnect and reconnect some devices to get them to
145 | autoconfigure, but in most cases you should only need to wait a minute or two
146 | for them to work. Other then that, you should be done!
147 |
--------------------------------------------------------------------------------
/config/nat-gateway.md:
--------------------------------------------------------------------------------
1 | # CJDNS NAT Gateway
2 |
3 | *Guide courtesy of [hyperboria.name](http://hyperboria.name/gateway) with minor
4 | edits.*
5 |
6 | Configure a host to act as a NAT gateway to provide access to Hyperboria for
7 | devices on your LAN (Windows PC, tablet, smart phone).
8 |
9 | This is a guide to setting up Ubuntu 13.04 to act as an IPv6 router and NAT
10 | gateway for CJDNS. Those who prefer other distros should find it trivial to
11 | adapt these instructions as required. If you do not have a linux server on your
12 | LAN already, consider purchasing a BeagleBone Black (for only $45 dollars!).
13 | You can find instructions [here](http://hyperboria.name/bbb/) on how to set it
14 | up for CJDNS.
15 |
16 | **WARNING**: The built-in security and encryption of CJDNS will **NOT**
17 | carry over past the gateway. Use of a NAT gateway for CJDNS should **ONLY**
18 | be done on a secure and trusted LAN. Any device on the LAN could theoretically
19 | intercept local CJDNS traffic before it reaches the gateway, and all devices
20 | will appear to other CJDNS nodes to *BE* the gateway node. This is intended
21 | to be a temporary solution until more universal compatibility is available for
22 | CJDNS.
23 |
24 | You will need:
25 |
26 | * One device running Ubuntu 13.04 and connected to your LAN
27 |
28 | *OR*
29 |
30 | * One device running the linux of your choice with kernel 3.7 or later and
31 | connected to your LAN
32 | * Sufficient knowledge to adapt this guide to your prefered linux
33 |
34 | ## Update and Configure iptables
35 |
36 | You will find it much easier to do this as root rather then using sudo, so run
37 | `sudo -i` first.
38 |
39 | You will need iptables 1.4.17 or better to properly configure IPv6 NAT with
40 | masqurade. Unfortunately, the latest Ubuntu as of the writing of this guide
41 | (13.04) only has 1.4.12, so you will need to download and install these
42 | packages (in order) before continuing:
43 |
44 | wget http://ftp.us.debian.org/debian/pool/main/libn/libnfnetlink/libnfnetlink0_1.0.1-2_armhf.deb
45 | dpkg -i libnfnetlink0_1.0.1-2_armhf.deb
46 |
47 | wget http://mirrors.kernel.org/debian/pool/main/i/iptables/libxtables10_1.4.18-1_armhf.deb
48 | dpkg -i libxtables10_1.4.18-1_armhf.deb
49 |
50 | wget http://mirrors.kernel.org/debian/pool/main/i/iptables/iptables_1.4.18-1_armhf.deb
51 | dpkg -i iptables_1.4.18-1_armhf.deb
52 |
53 | Obviously this will not be necessary if you already have iptables 1.4.17 or
54 | later installed. You can confirm your version by running the following command:
55 |
56 | iptables --version
57 |
58 | Also note that you will need linux kernel 3.7 or later to have support for IPv6
59 | NAT at all.
60 |
61 | Next you need to enable forwarding for IPv6:
62 |
63 | echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
64 |
65 | Make it permenant by editing `/etc/sysctl.conf` to include the following line:
66 |
67 | net.ipv6.conf.all.forwarding=1
68 |
69 | You will most likely find it in there already, but commented out. Simply remove
70 | the "#".
71 |
72 | Now enter the ip6tables rules:
73 |
74 | ip6tables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
75 | ip6tables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
76 | ip6tables -A FORWARD -i eth1 -o eth0 -j ACCEPT
77 |
78 | Save the rules:
79 |
80 | ip6tables-save > /etc/network/ip6tables.rules
81 |
82 | Create the file `/etc/network/if-pre-up.d/ip6tables` containing the following:
83 |
84 | #!/bin/sh
85 | ip6tables-restore < /etc/network/ip6tables.rules
86 | exit 0
87 |
88 | And make it executable:
89 |
90 | chmod +x /etc/network/if-pre-up.d/ip6tables
91 |
92 | Now iptables is configured as an IP v6 NAT gateway, and the settings will be
93 | preserved through reboots.
94 |
95 | ## Install and Configure radvd
96 |
97 | Install radvd so that your gateway advertises itself on the network:
98 |
99 | apt-get install radvd
100 |
101 | Create (or edit if already present) the file `/etc/radvd.conf` with the
102 | following contents:
103 |
104 | interface eth0
105 | {
106 | AdvSendAdvert on;
107 | prefix fdfc::1/64
108 | {
109 | AdvRouterAddr on;
110 | };
111 | };
112 |
113 | Note that this assumes you will be using the eth0 interface. If your LAN
114 | interface is different, you need to replace eth0 with the correct one.
115 |
116 | Start/restart radvd:
117 |
118 | /etc/init.d/radvd restart
119 |
120 | Now IPv6 capable computers and devices should configure themselves to use your
121 | gateway automatically as soon as they are connected to the network.
122 |
123 | To ensure proper routing, however, the interface needs the right IP assigned to
124 | it. Edit the file `/etc/network/interfaces` to include the following:
125 |
126 | iface eth0 inet6 static
127 | pre-up modprobe ipv6
128 | address fdfc:0000:0000:0000:0000:0000:0000:0001
129 | netmask 64
130 |
131 | Once again, this assumes your LAN interface is eth0. Adjust as required.
132 | At this point, it is recommended that you reboot so you can confirm everything
133 | is still working:
134 |
135 | reboot
136 |
137 | Don't forget to start CJDNS after it's done booting if you haven't set it up to
138 | start automatically. Alternatively, if you do not want to reboot at this time,
139 | you can run the following command to assign the IP address to the interface
140 | manually:
141 |
142 | ip addr add fdfc::1/64 dev eth0
143 |
144 | You may need to disconnect and reconnect some devices to get them to
145 | autoconfigure, but in most cases you should only need to wait a minute or two
146 | for them to work. Other then that, you should be done!
147 |
--------------------------------------------------------------------------------