| … | |
… | |
| 10 | The first part of this document describes the transport protocols which |
10 | The first part of this document describes the transport protocols which |
| 11 | are used by GVPE to send it's data packets over the network. |
11 | are used by GVPE to send it's data packets over the network. |
| 12 | |
12 | |
| 13 | =head1 PART 1: Tansport protocols |
13 | =head1 PART 1: Tansport protocols |
| 14 | |
14 | |
|
|
15 | GVPE offers a range of transport protocols that can be used to interchange |
|
|
16 | data between nodes. Protocols differ in their overhead, speed, |
|
|
17 | reliability, and robustness. |
|
|
18 | |
|
|
19 | The following sections describe each transport protocol in more |
|
|
20 | detail. They are sorted by overhead/efficiency, the most efficient |
|
|
21 | transprot is listed first: |
|
|
22 | |
| 15 | =head2 RAW IP |
23 | =head2 RAW IP |
| 16 | |
24 | |
|
|
25 | This protocol is the best choice, performance-wise, as the minimum |
|
|
26 | overhead per packet is only 38 bytes. |
|
|
27 | |
|
|
28 | It works by sending the VPN payload using raw ip frames (using the |
|
|
29 | protocol set by C<ip-proto>). |
|
|
30 | |
|
|
31 | Using raw ip frames has the drawback that many firewalls block "unknown" |
|
|
32 | protocols, so this transport only works if you have full IP connectivity |
|
|
33 | between nodes. |
|
|
34 | |
| 17 | =head2 ICMP |
35 | =head2 ICMP |
| 18 | |
36 | |
|
|
37 | This protocol offers very low overhead (minimum 42 bytes), and can |
|
|
38 | sometimes tunnel through firewalls when other protocols cannot. |
|
|
39 | |
|
|
40 | It works by prepending a ICMP header with type C<icmp-type> and a code |
|
|
41 | of C<255>. The default C<icmp-type> is C<echo-reply>, so the resulting |
|
|
42 | packets look like echo replies, which looks rather strange to network |
|
|
43 | admins. |
|
|
44 | |
|
|
45 | This transport should only be used if other transports (i.e. raw ip) are |
|
|
46 | not available or undesirable (due to their overhead). |
|
|
47 | |
| 19 | =head2 UDP |
48 | =head2 UDP |
| 20 | |
49 | |
|
|
50 | This is a good general choice for the transport protocol as UDP packets |
|
|
51 | tunnel well through most firewalls and routers, and the overhead per |
|
|
52 | packet is moderate (minimum 58 bytes). |
|
|
53 | |
|
|
54 | It should be used if RAW IP is not available. |
|
|
55 | |
| 21 | =head2 TCP |
56 | =head2 TCP |
| 22 | |
57 | |
|
|
58 | This protocol is a very bad choice, as it not only has high overhead (more |
|
|
59 | than 60 bytes), but the transport also retries on it's own, which leads |
|
|
60 | to congestion when the link has moderate packet loss (as both the TCP |
|
|
61 | transport and the tunneled traffic will retry, increasing congestion more |
|
|
62 | and more). It also has high latency and is quite inefficient. |
|
|
63 | |
|
|
64 | It's only useful when tunneling through firewalls that block better |
|
|
65 | protocols. If a node doesn't have direct internet access but a HTTP proxy |
|
|
66 | that supports the CONNECT method it can be used to tunnel through a web |
|
|
67 | proxy. For this to work, the C<tcp-port> should be C<443> (C<https>), as |
|
|
68 | most proxies do not allow connections to other ports. |
|
|
69 | |
|
|
70 | It is an abuse of the usage a proxy was designed for, so make sure you are |
|
|
71 | allowed to use it for GVPE. |
|
|
72 | |
|
|
73 | This protocol also has server and client sides. If the C<tcp-port> is set |
|
|
74 | to zero, other nodes cannot connect to this node directly (and C<tcp-port> |
|
|
75 | zero cannot be used). If the C<tcp-port> is non-zero, the node can act |
|
|
76 | both as a client as well as a server. |
|
|
77 | |
| 23 | =head2 DNS |
78 | =head2 DNS |
|
|
79 | |
|
|
80 | B<WARNING:> Parsing and generating DNS packets is rather tricky. The code |
|
|
81 | almost certainly contains buffer overflows and other, likely exploitable, |
|
|
82 | bugs. You have been warned. |
|
|
83 | |
|
|
84 | This is the worst choice of transport protocol with respect to overhead |
|
|
85 | (overhead can be 2-3 times higher than the transferred data), and latency |
|
|
86 | (which can be many seconds). Some DNS servers might not be prepared to |
|
|
87 | handle the traffic and drop or corrupt packets. The client also has to |
|
|
88 | constantly poll the server for data, so the client will constantly create |
|
|
89 | traffic even if it doesn't need to transport packets. |
|
|
90 | |
|
|
91 | In addition, the same problems as the TCP transport also plague this |
|
|
92 | protocol. |
|
|
93 | |
|
|
94 | Most configuration needs to be done by editing C<src/vpn_dns.C> directly. |
|
|
95 | |
|
|
96 | It's only use is to tunnel through firewalls that do not allow direct |
|
|
97 | internet access. Similar to using a HTTP proxy (as the TCP transport |
|
|
98 | does), it uses a local DNS server/forwarder (given by the C<dns-forw-host> |
|
|
99 | configuration value) as a proxy to send and receive data as a client, |
|
|
100 | and a C<NS> record pointing to the GVPE server (as given by the |
|
|
101 | C<dns-hostname> directive). |
|
|
102 | |
|
|
103 | The only good side of this protocol is that it can tunnel through most |
|
|
104 | firewalls undetected, iff the local DNS server/forwarder is sane (which is |
|
|
105 | true for most routers, wlan gateways and nameservers). |
| 24 | |
106 | |
| 25 | =head1 PART 2: The GNU VPE protocol |
107 | =head1 PART 2: The GNU VPE protocol |
| 26 | |
108 | |
| 27 | This section, unfortunately, is not yet finished, although the protocol |
109 | This section, unfortunately, is not yet finished, although the protocol |
| 28 | is stable (until bugs in the cryptography are found, which will likely |
110 | is stable (until bugs in the cryptography are found, which will likely |
