| 1 | This file, INSTALL, is a tutorial on how to |
| 2 | * install userv ipif and udptunnel, and |
| 3 | * configure them to create a VPN tunnel between two hosts or networks. |
| 4 | |
| 5 | See README for details of other available documentation. |
| 6 | |
| 7 | |
| 8 | BUILD AND INSTALLATION INSTRUCTIONS |
| 9 | ----------------------------------- |
| 10 | |
| 11 | 1. Install userv, 1.0.1 or later. This is in Debian GNU/Linux. |
| 12 | |
| 13 | 2. Make sure your Linux kernel has SLIP and CSLIP compiled in. |
| 14 | You will need to be using Linux 2.2 (with Unix98-style ptys). |
| 15 | |
| 16 | 3. Obtain a fresh copy of userv-utils, if you haven't already. |
| 17 | cd to ipif, and run `make' and (as root) `make install'. |
| 18 | |
| 19 | After you have done this the software will still not do anything, and |
| 20 | by default userv ipif will not allow anyone (except root) to create |
| 21 | network interfaces. |
| 22 | |
| 23 | The software will probably only work on Linux - in particular, userv |
| 24 | ipif's service program (service.c) uses Linux-specific ways of |
| 25 | setting up SLIP interfaces. It might be possible in principle to |
| 26 | create alternatives for other platforms. |
| 27 | |
| 28 | `slattach' problem: |
| 29 | |
| 30 | There is a problem with some versions of `slattach' on Linux. If you |
| 31 | see a message from it about being unable to open /dev/2 or some such, |
| 32 | then you need to upgrade or patch your `slattach'. In Debian |
| 33 | GNU/Linux it's in the `netbase' package, and the fix is in Debian 2.1 |
| 34 | in 3.16-3 and later; however the bug has regressed, and is known to |
| 35 | be in Debian 2.2's 3.18-4 and earlier. The relevant Debian bug |
| 36 | reports are #45515 (now closed) and #45944. A patch to correct |
| 37 | 3.18-4 is provided here as `slattach.diff', and a fixed binary is |
| 38 | available from the author. |
| 39 | |
| 40 | |
| 41 | |
| 42 | UDPTUNNEL SETUP TUTORIAL |
| 43 | ------------------------ |
| 44 | |
| 45 | |
| 46 | 1. BACKGROUND INFORMATION |
| 47 | |
| 48 | Firstly, note that userv ipif and udptunnel are extremely flexible, |
| 49 | as they aim to be `Lego brick' networking components. Many much more |
| 50 | interesting configurations can be constructed than there is room to |
| 51 | document here. If you want to do something strange, consult the |
| 52 | README to locate the appropriate reference documentation. |
| 53 | |
| 54 | 1.1. About udptunnel |
| 55 | |
| 56 | udptunnel is point-to-point; you need a separate `invocation' for |
| 57 | each pair of machines (or networks) you wish to connect. |
| 58 | |
| 59 | It is `one-shot': it will set up a tunnel and keep it going as long |
| 60 | as it can, and then exit; if you want a permanent tunnel you must |
| 61 | arrange to reinvoke udptunnel. |
| 62 | |
| 63 | It is asymmetric, in that one of the endpoints starts the tunnel, and |
| 64 | the other sits and waits to be contacted. We'll call the active |
| 65 | endpoint `alice' and the passive endpoint `bob'. Usually alice |
| 66 | invokes udptunnel on bob via OpenSSH (`ssh'). |
| 67 | |
| 68 | udptunnel does not need root privilege to run. However, you do need |
| 69 | to configure userv ipif to know that the user who will be running |
| 70 | udptunnel is permitted to use the IP addresses and network ranges |
| 71 | which will be used. So, though most of the configuration can be done |
| 72 | as the normal users who will run udptunnel on each end, a small |
| 73 | amount (editing /etc/userv/ipif-networks) needs to be done as root on |
| 74 | each end - and the information configured as root needs to match up |
| 75 | |
| 76 | This tutorial will explain how to do these things. |
| 77 | |
| 78 | 1.2. About point-to-point tunnelling in general |
| 79 | |
| 80 | A tunnel is an _additional_ (in the case of udptunnel, encrypted) |
| 81 | network link between a pair of machines. Packets are encapsulated at |
| 82 | one end, sent over the real network between them, and decoded again |
| 83 | at the other end. As with any network connection, it is possible to |
| 84 | arrange for networks behind the endpoint machines to be able to |
| 85 | communicate via the tunnel. |
| 86 | |
| 87 | Each endpoint machine will have at least two network interfaces: |
| 88 | Firstly, the real `physical' interface through which the encapsulated |
| 89 | packets will be really sent and received. Secondly, the `virtual' |
| 90 | interface created by the tunnelling software, which represents its |
| 91 | end of the (encrypted) tunnel link. The physical and virtual |
| 92 | interfaces MUST have different addresses. |
| 93 | |
| 94 | Each endpoint machine may also have additional network interfaces; |
| 95 | for example, it may be the router for a network which sits behind it, |
| 96 | which an interface on that network, or it may be the endpoint for |
| 97 | more than one tunnel. It is OK for several tunnels terminating at |
| 98 | the same machine to use the same virtual address (provided that the |
| 99 | tunnels are not `layered' on top of each other but are `in |
| 100 | parallel'), and it is also OK to use as the virtual tunnel address a |
| 101 | router's address on a private network which will be sent via the |
| 102 | tunnel. |
| 103 | |
| 104 | 1.3. Diagram |
| 105 | |
| 106 | ____ ______________ ______________ ____ |
| 107 | __( )__ |ALICE | | BOB| __( )__ |
| 108 | ,' ` ' `. | _ | Tunnel | _ | ,' ` ' `. |
| 109 | | alice | | |\\ ,- - - - - - - - - -. //| | | bob | |
| 110 | `._private _.' | | || | | || | | `._private _.' |
| 111 | | networks |==+--------'|| | Public | ||`--------+==| networks | |
| 112 | | | | alice | Network | bob | | | |
| 113 | `.~ ~.' | virtual +=============+ virtual | `.~ ~.' |
| 114 | (__,'`.__) |______________|alice bob|______________| (__,'`.__) |
| 115 | physical physical |
| 116 | _ |
| 117 | Key: HOSTNAME +===+ Actual Network |\\ Tunnel |
| 118 | Descriptive Text ----- Data Flow | ||Endpoint |
| 119 | host or network number - - - Encrypted Data Flow || |
| 120 | |
| 121 | |
| 122 | 2. SETUP INSTRUCTIONS |
| 123 | |
| 124 | All of these steps can be done using the appropriate normal user |
| 125 | accounts, unless otherwise indicated. |
| 126 | |
| 127 | 2.1. Find out, or choose, private network numbers |
| 128 | |
| 129 | You need to make sure you know what all of the addresses in the above |
| 130 | diagram are going to be. |
| 131 | |
| 132 | Usually you must choose the private and virtual addresses yourself: |
| 133 | hosts on the private networks usually won't communicate with the |
| 134 | global Internet other than through proxies or masquerading firewalls. |
| 135 | |
| 136 | You MUST choose from the reserved ranges in RFC1918, which are: |
| 137 | 172.16.0.0/12 192.168.0.0/16 10.0.0.0/8 |
| 138 | If you do not do so you'll end up reusing someone else's addresses, |
| 139 | which can cause lots of hard-to-diagnose and embarrasing problems. |
| 140 | |
| 141 | You should CHOOSE RANDOMLY ! This makes sure that when you decide to |
| 142 | connect your VPN to someone else's VPN, your network allocation |
| 143 | numbers are unlikely to clash. If you both choose 192.168.0.0/24 |
| 144 | you'll have to renumber (and will look like fools). |
| 145 | |
| 146 | To help with choosing random network numbers from RFC1918 space, the |
| 147 | author maintains a web page at <http://www.ucam.org/cam-grin/>, which |
| 148 | can pick network numbers for you. |
| 149 | |
| 150 | Additionally, there is a database there - people in Cambridge (in |
| 151 | England) are encouraged to register their network address usage |
| 152 | there. Please do not register in the database unless you're likely |
| 153 | to want to connect your VPN to others already listed. |
| 154 | |
| 155 | 2.2. Find out, or choose, public network numbers |
| 156 | |
| 157 | These are usually specified by your ISP, either statically or |
| 158 | dynamically assigned. If the active end (`alice physical') is |
| 159 | dynamically assigned you can use the `Wait' option (see below) to |
| 160 | avoid specifying it, but otherwise you will need to have some kind of |
| 161 | script to find it each time you invoke udptunnel, or use a hostname |
| 162 | which automatically tracks the source host using dynamic DNS. |
| 163 | |
| 164 | In some situations you may find yourself using a `public network' |
| 165 | which is not actually the public Internet - for example, you may want |
| 166 | to run one tunnel `through' another, or your `public network' is |
| 167 | actually a private radio LAN. In this case you'll have to choose the |
| 168 | addresses to use from RFC1918-space, as above. |
| 169 | |
| 170 | 2.3. Decide which user account(s) on alice and bob you will use |
| 171 | |
| 172 | These user accounts will see the plaintext for all network packets |
| 173 | going over the tunnel and if compromised will be able steal or forge |
| 174 | tunnel traffic. So, they should be reasonably secure. |
| 175 | |
| 176 | Let us assume that the account on alice is called Tbob, and the |
| 177 | account on bob is called Talice. (NB that your system may not |
| 178 | correctly handle usernames containing uppercase.) |
| 179 | |
| 180 | Each account should be in a group of its own, which will be used for |
| 181 | the userv ipif access control. |
| 182 | |
| 183 | Arrange that Tbob@alice can ssh to Talice@bob without needing a |
| 184 | passphrase or other user interaction. |
| 185 | |
| 186 | (Obviously, if you need to create accounts, edit groups, or change |
| 187 | the sshd configuratioon, you may need to be root.) |
| 188 | |
| 189 | 2.3. Configure the private network numbers in /etc/userv/ipif-networks |
| 190 | |
| 191 | (This step needs to be done as root.) |
| 192 | |
| 193 | On alice, in /etc/userv/ipif-networks, put |
| 194 | <Tbob-gid>,=<alice-virt-addr>/32, <Tbob-group>, <comment> |
| 195 | <Tbob-gid>,<bob-virt-addr>/32, <Tbob-group>, <comment> |
| 196 | and for each of bob's private networks |
| 197 | <Tbob-gid>,<network>/<prefix-len>, <Tbob-group>, <comment> |
| 198 | You can leave out the <bob-virt-addr>/32 line if bob's virtual |
| 199 | address is in one of bob's private networks. |
| 200 | |
| 201 | On bob, do the corresponding. In /etc/userv/ipif-networks, put |
| 202 | <Talice-gid>,=<bob-virt-addr>/32, <Talice-group>, <comment> |
| 203 | <Talice-gid>,<alice-virt-addr>/32, <Talice-group>, <comment> |
| 204 | and for each of alice's private networks |
| 205 | <Talice-gid>,<network>/<prefix-len>, <Talice-group>, <comment> |
| 206 | Again, you can leave out <alice-virt-addr> if one of the virtual |
| 207 | networks covers it. |
| 208 | |
| 209 | All the specifications in /etc/userv/ipif-networks must be numerical |
| 210 | addresses - hostnames are not allowed. Also, the /32 indicating a |
| 211 | specific host cannot be omitted. |
| 212 | |
| 213 | Note the use of `=' for each host's own virtual address, which |
| 214 | indicates to userv ipif that it's OK for that gid to create a local |
| 215 | interface with that address, but the address may not be assigned to a |
| 216 | remote host or route. |
| 217 | |
| 218 | 2.4. Construct the udptunnel invocation (on alice) |
| 219 | |
| 220 | udptunnel has a long and complicated command line, rather than a |
| 221 | configuration file. The best way to deal with this is to create a |
| 222 | shell script which runs udptunnel with the right options. This |
| 223 | script will live on alice in ~Tbob, and be run by Tbob. Let us call |
| 224 | it `udptunnel-invoke-bob'. |
| 225 | |
| 226 | For the most basic setup, it should look something like this: |
| 227 | |
| 228 | #!/bin/sh |
| 229 | set -e |
| 230 | set -x |
| 231 | |
| 232 | udptunnel \ |
| 233 | -e nonce -e timestamp/10/30 \ |
| 234 | -e pkcs5/8 -e blowfish-cbcmac/128 -e blowfish-cbc/128 \ |
| 235 | <alice-physical-hostname>,Any \ |
| 236 | <bob-physical-hostname>,Command \ |
| 237 | <alice-virtual>,<bob-virtual>,1000,cslip \ |
| 238 | 30,130,1800 \ |
| 239 | <bob-private-nets> <alice-private-nets> \ |
| 240 | ssh -o 'BatchMode yes' \ |
| 241 | -v <Talice>@<bob-physical-hostname> \ |
| 242 | udptunnel |
| 243 | |
| 244 | You have to fill in the right values for things in angle brackets. |
| 245 | (See also section 6. for a moderately complex example, below.) |
| 246 | |
| 247 | 2.4.1. Syntax of <alice-private-nets> and <bob-private-nets> |
| 248 | |
| 249 | These arguments to udptunnel are the network address ranges at each |
| 250 | end which are to be connected via the tunnel. Let us consider just |
| 251 | <alice-private-nets>; <bob-private-nets> is just the same, but for |
| 252 | bob's end. |
| 253 | |
| 254 | <alice-private-nets> is a comma-separated list of networks specified |
| 255 | as <network>/<prefix-len>. The network address must be numerical, |
| 256 | and the prefix length must always be specified. |
| 257 | |
| 258 | If there are no private networks `behind' alice, ie the tunnel is |
| 259 | just to connect alice to bob and things at bob's end, then specify |
| 260 | `-' for <alice-private-nets>. |
| 261 | |
| 262 | 2.4.2. IP masquerading (NAT) at alice's end |
| 263 | |
| 264 | If alice is behind a masquerading (NAT) firewall, you can still get |
| 265 | it to work. You need to add an option `-m' before the other |
| 266 | arguments. This will make udptunnel on alice tell udptunnel on bob |
| 267 | to wait for alice's first encapsulated packet before deciding what |
| 268 | alice's physcial address and port number are, as seen by bob. That |
| 269 | way alice doesn't need to know what port number the NAT proxy will |
| 270 | use. |
| 271 | |
| 272 | 2.4.3. Using fixed UDP port numbers (eg to make firewally happy) |
| 273 | |
| 274 | If alice is behind a firewall which will not allow incoming UDP to |
| 275 | arbitrary ports, even when sent in reply to packets of alice's, you |
| 276 | have to arrange for alice to use a fixed port number. Change |
| 277 | <alice-physical-hostname>,Any \ |
| 278 | to |
| 279 | <alice-physical-hostname>,<alice-physical-port> \ |
| 280 | |
| 281 | udptunnel will need to be able to bind to the relevant port, so you |
| 282 | must either (i) choose a port number over 1024, which risks other |
| 283 | processes on alice accidentally using that port, (ii) run udptunnel |
| 284 | as root on alice, or (iii) use authbind (authbind is a utility, |
| 285 | included in Debian, which can allow non-root programs to bind to low |
| 286 | ports in a controlled way). |
| 287 | |
| 288 | If bob is behind such a firewall too, you can replace |
| 289 | <bob-physical-hostname>,Command \ |
| 290 | with |
| 291 | <bob-physical-hostname>,<bob-physical-port> \ |
| 292 | |
| 293 | 2.4.4. Clock skew and excessive delay |
| 294 | |
| 295 | The default configuration given above, which includes this |
| 296 | -e nonce -e timestamp/10/30 \ |
| 297 | will not work if there is more than 10s of clock skew between alice |
| 298 | and bob's system clocks, or if the lag in either direction is more |
| 299 | than 30s. It is best if your systems run with synchronised clocks |
| 300 | (you can run NTP over the tunnel if necessary) and don't have such |
| 301 | bad lag, of course. |
| 302 | |
| 303 | However, you can increase these parameters if you really want. To |
| 304 | increase the tolerance to clock skew to some amount, make sure that |
| 305 | both numbers are at least the amount of clock skew you're willing to |
| 306 | tolerate. To increase the tolerance to delay it's only necessary to |
| 307 | increase the second number. |
| 308 | |
| 309 | Warning: if you increase these numbers too much there is a risk that |
| 310 | packets delayed or repeated by an attacker will be treated as genuine |
| 311 | and cause communication or security problems. I would not recommend |
| 312 | using a value more than 120 (2 minutes). |
| 313 | |
| 314 | If you really can't get reasonable clock synch at all, you can use |
| 315 | sequence number replay detection instead of clock-based replay |
| 316 | detection. Replace |
| 317 | -e nonce -e timestamp/10/30 \ |
| 318 | with |
| 319 | -e sequence \ |
| 320 | |
| 321 | 2.4.5. Other things to tweak (it's usually safe to ignore this part) |
| 322 | |
| 323 | Do not mess with the `-e' parameters and arguments except as |
| 324 | explained above, unless you are a cryptographer. |
| 325 | |
| 326 | 30,130,1800 are timeouts which control the `dead tunnel detection'. |
| 327 | The first is the keepalive interval: when one end hasn't sent |
| 328 | anything for that many seconds, it will send an empty keepalive |
| 329 | packet. The second is the dead tunnel timeout: when one end hasn't |
| 330 | received anything for that many seconds, it assumes the tunnel is |
| 331 | dead and dies (the other end will then usually die shortly if it |
| 332 | hasn't already). The third is the status reporting interval - at |
| 333 | intervals of that many seconds each end will report (to udptunnel's |
| 334 | stdout) that the tunnel is still open and give some statistics; these |
| 335 | diagnostics also prevent the controlling ssh connection's entry in |
| 336 | masquerading and firewall tables from timing out. |
| 337 | |
| 338 | 1000 (in ...,...,1000,cslip) is the MTU - the maximum size of packet |
| 339 | which will be sent through the tunnel. It is best if this number is |
| 340 | a certain amount smaller than the path MTU over the physical network, |
| 341 | so that encapsulated packets do not get fragmented. (Each packet |
| 342 | will be increased in size by 24 bytes + the size of a UDP and IP |
| 343 | header + the effects of SLIP duplication of certain bytes.) |
| 344 | |
| 345 | |
| 346 | 3. Test your udptunnel invocation script |
| 347 | |
| 348 | 3.1. Invocation |
| 349 | |
| 350 | Log into alice as Tbob, and run ./udptunnel-invoke-bob. |
| 351 | A great deal of diagnostic output will ensue. |
| 352 | |
| 353 | If all is well you will see two messages looking something like this |
| 354 | udptunnel-forwarder: bob: tunnel open with peer 127.0.0.3:76543 |
| 355 | udptunnel-forwarder: alice: tunnel open |
| 356 | and the session will just sit there. Go to 3.2. |
| 357 | |
| 358 | If it didn't say that, here are some debugging tips: |
| 359 | |
| 360 | * If it just sits there for a minute or two and then udptunnel times |
| 361 | out, the physical packets aren't getting back and forth. Use |
| 362 | tcpdump, check your firewall and routing (as below), and consult the |
| 363 | sections above about NAT and firewalls. |
| 364 | |
| 365 | * If it bombed out, look for an error message in the diagnostics. |
| 366 | There will be lots of `subprocess somethingorother exited with |
| 367 | nonzero exit status 47', `no details received from remote' and the |
| 368 | like, but these are probably not the ones you want to look at, |
| 369 | because they're usually just consequences of some other failure. |
| 370 | |
| 371 | Permission denied. |
| 372 | udptunnel - alice: fatal error: remote command failed (code ...) |
| 373 | Tbob had trouble ssh'ing to Talice@bob. Check that the ssh |
| 374 | configuration is set up, and test it separately. |
| 375 | |
| 376 | userv-ipif service: access denied for ...., .... |
| 377 | udptunnel - alice: subprocess local command failed with code 2048 |
| 378 | The arguments to udptunnel don't correspond to |
| 379 | /etc/userv/ipif-networks on alice. Either the arguments to |
| 380 | udptunnel or the ipif-networks file is wrong. (Or, if the message |
| 381 | about `local command failed' mentions bob, look on bob.) |
| 382 | |
| 383 | udptunnel - alice: subprocess forwarder failed with code 14 |
| 384 | The tunnel timed out - no packets were successfully received for |
| 385 | 130 seconds. See 2.4.5 above for details of the timeout |
| 386 | parameters. (NB, applies to `code 14' only.) |
| 387 | |
| 388 | usage errors from udptunnel or ssh, or sh: ...: unknown command |
| 389 | Perhaps you dropped a \ from the udptunnel-invoke-bob script ? |
| 390 | |
| 391 | udptunnel not found, udptunnel-forwarder not found |
| 392 | Check that the PATH includes /usr/local/bin. Noninteractive `ssh' |
| 393 | invocations (ie, ones with a command specified) often have a |
| 394 | different PATH. |
| 395 | |
| 396 | slattach cannot open /dev/2 (or similar messages) |
| 397 | Your slattach is buggy. See under `slattach problem' in the build |
| 398 | and installation instructions, above. |
| 399 | |
| 400 | slattach cannot change line discipline (or some other weird message) |
| 401 | Check whether your kernel is compiled with SLIP and/or CSLIP |
| 402 | support. |
| 403 | |
| 404 | * Other messages: |
| 405 | |
| 406 | udptunnel-forwarder: alice: bad packet: blowfish-cbcmac: verify failed |
| 407 | This can be caused by actual packet corruption on the physical |
| 408 | network (or even by an actual hostile attack), but when using |
| 409 | fixed port numbers these messages are common after the tunnel has |
| 410 | died and been restarted: they correspond to packets from the |
| 411 | previous invocation (which is usung different keys) being rejected |
| 412 | because their checksums don't match. In this case they should go |
| 413 | away in a minute or two. |
| 414 | |
| 415 | 3.2. Testing, once the tunnel claims to be working |
| 416 | |
| 417 | In another session on alice, you should be able to ping bob's virtual |
| 418 | interface. If this works, test pinging between hosts on the private |
| 419 | networks behind alice and bob. If all is well, go onto step 4. |
| 420 | |
| 421 | If not, here are some troubleshooting hints: |
| 422 | |
| 423 | * Use numerical addresses when testing. This eliminates DNS problems |
| 424 | from your test strategy. |
| 425 | |
| 426 | * Use `ifconfig' and `route -n' on alice and bob to check that the |
| 427 | interfaces and routes all look right. The tunnel will show up as a |
| 428 | `sl<n>' for some <n>. |
| 429 | |
| 430 | * Use `tcpdump -n -i <interface>' to watch the traffic go across some |
| 431 | interface, to try to figure out where the traffic is going. Look |
| 432 | both for the private traffic before it goes into the tunnel, and the |
| 433 | physical traffic, to try to find out where it disappears. The |
| 434 | diagnostics will tell you which physical ports it's using, something |
| 435 | like this: |
| 436 | udptunnel - alice: debug: using remote Wait,Wait local 131.111.232.108,1422 |
| 437 | udptunnel - bob: debug: using remote 131.111.232.108,1422 local 195.224.38.6,2413 |
| 438 | |
| 439 | * alice and bob can see each other but the private networks can't ? |
| 440 | Make sure alice and bob both have IP forwarding enabled. |
| 441 | |
| 442 | * Check your firewalls, if you have them. It's most helpful if your |
| 443 | firewall configuration arranges to log rejected packets - without |
| 444 | that, they can be a complete pain to debug. |
| 445 | |
| 446 | |
| 447 | 4. Configure the tunnel to run automatically |
| 448 | |
| 449 | Now that the tunnel works if you invoke it by hand, it is time to |
| 450 | arrange to run it automatically. |
| 451 | |
| 452 | If you want the tunnel to run over a dialup link only when the dialup |
| 453 | link is up, then I'm afraid you'll have to arrange to start and kill |
| 454 | it yourself, probably. I haven't set up such a configuration. More |
| 455 | information about this for this document, if you manage to do it, |
| 456 | would be good. |
| 457 | |
| 458 | So, I shall assume that you want the tunnel to be up all of the time |
| 459 | (or at least, as much as possible). The best way to do this is to |
| 460 | run it from `init', by setting it up in inittab. |
| 461 | |
| 462 | For example, you could put something like this in your inittab: |
| 463 | t0:23:respawn:su Tbob -c ./udptunnel-invoke-bob 2>&1 | logger -p local2.info -t tunnel-bob |
| 464 | (Note that if you have more than one tunnel the `id' field, at the |
| 465 | start of the inittab line, must be different for each one.) |
| 466 | |
| 467 | This would use `su' to become bob and run the actual tunnelling |
| 468 | software, and arrange for the diagnostic output to be sent to syslog |
| 469 | with facility `local2' and priority `info', tagged with `tunnel-bob'. |
| 470 | With an appropriate line in /etc/syslog.conf, such as |
| 471 | local2.* /var/log/local2-all.log |
| 472 | (remember that you have to use tabs in syslog.conf) this will |
| 473 | produce, in /var/log/local2-all.log, all the diagnostics, including |
| 474 | reassuring messages like this: |
| 475 | Sep 18 00:27:48 alice tunnel-bob: udptunnel-forwarder: alice: tunnel still open: received 5262 packets, 5262 bytes |
| 476 | Sep 18 00:28:44 alice tunnel-bob: udptunnel-forwarder: bob: tunnel still open: received 5280 packets, 5280 bytes |
| 477 | |
| 478 | |
| 479 | 5. DNS, firewall, mail, etc. |
| 480 | |
| 481 | Now you have IP level connectivity between your two networks. You |
| 482 | must now arrange for: |
| 483 | |
| 484 | * An appropriate firewall on each tunnel endpoint (to stop attacks |
| 485 | from one network to another) and also at all the borders of each |
| 486 | network (to stop traffic that is going to, or looks like it came |
| 487 | from, the private networks). |
| 488 | |
| 489 | * DNS configuration so that hosts on both sides of the tunnel can see |
| 490 | each other's names, addresses and other information. |
| 491 | |
| 492 | * Mail, news and other application protocols may need to be |
| 493 | configured to use the private tunnel connectivity, rather than |
| 494 | treating the other private network's names as being `elsewhere' and |
| 495 | using unencrypted connectivity via the global Internet. |
| 496 | |
| 497 | How to do these things is beyond the scope of this document. |
| 498 | |
| 499 | |
| 500 | 6. Example |
| 501 | |
| 502 | This example is the tunnel between chiark and Relativity. I'll quote |
| 503 | it and explain the details, below. See also the comment at the top of |
| 504 | udptunnel. |
| 505 | |
| 506 | authbind udptunnel \ |
| 507 | -m \ |
| 508 | -e nonce -e timestamp/10/30 -e pkcs5/8 \ |
| 509 | -e blowfish-cbcmac/128 -e blowfish-cbc/128 \ |
| 510 | davenant-external,410 \ |
| 511 | chiark-public,Command \ |
| 512 | 172.31.80.6,172.31.80.9,1000,cslip \ |
| 513 | 30,120,1800 \ |
| 514 | - 172.18.45.0/24 \ |
| 515 | ssh -o 'ForwardAgent no' -o 'ForwardX11 no' \ |
| 516 | -o 'BatchMode yes' \ |
| 517 | -i ~ian/.ssh/identity -l ian \ |
| 518 | -v chiark.greenend.org.uk \ |
| 519 | udptunnel |
| 520 | |
| 521 | Because at Relativity the tunnel endpoint has to not be our firewall, |
| 522 | because the firewall is a 386SX/16 and so not powerful enough, |
| 523 | Relativity practically has to be the active partner in any tunnels it |
| 524 | is involved in. This also necessitates the use of the `-m' option and |
| 525 | various other things. |
| 526 | |
| 527 | Exposition of the example udptunnel invocation: |
| 528 | |
| 529 | > authbind udptunnel \ |
| 530 | |
| 531 | `authbind' is used because at Relativity the tunnel endpoint address |
| 532 | has to be on a fixed port because our tunnel endpoint is not on the |
| 533 | firewall system (if it's not on a fixed port we can't write a good |
| 534 | firewall rule to let it through). |
| 535 | |
| 536 | The port we are using is port 410, a low port to prevent other |
| 537 | processes `stealing' it, so root privilege or authbind is needed. |
| 538 | |
| 539 | > -m \ |
| 540 | |
| 541 | -m tells this invocation of udptunnel that its endpoint address and |
| 542 | port (for encapsulated packets) are going to be NATted before the far |
| 543 | end sees them. The effect is that instead of supplying this |
| 544 | information to the far end, the far end is told to `wait and see'. |
| 545 | |
| 546 | This should not usually be used in other circumstances. (For full |
| 547 | details see the comment at the top of udptunnel.) |
| 548 | |
| 549 | > -e nonce -e timestamp/10/30 -e pkcs5/8 \ |
| 550 | > -e blowfish-cbcmac/128 -e blowfish-cbc/128 \ |
| 551 | |
| 552 | This is the crypto configuration. |
| 553 | |
| 554 | > davenant-external,410 \ |
| 555 | |
| 556 | This is the local physical address and port. davenant is the tunnel |
| 557 | endpoint, and davenant-external is its public address (we run two |
| 558 | networks on the wire at Relativity, an internal one and a public |
| 559 | one). |
| 560 | |
| 561 | > chiark-public,Command \ |
| 562 | |
| 563 | This is the physical remote address and port. `Command' means find |
| 564 | out the remote physical address or port by having udptunnel at the |
| 565 | far end print its address and port when they have been allocated. |
| 566 | |
| 567 | Another possibility here is to use a fixed remote port number. |
| 568 | |
| 569 | The DNS at GR is configured so that just `chiark' means chiark via |
| 570 | the tunnel, so we have to use chiark-public which means its public |
| 571 | IP address. |
| 572 | |
| 573 | > 172.31.80.6,172.31.80.9,1000,cslip \ |
| 574 | |
| 575 | 172.31.80.6 is davenant's virtual address. |
| 576 | 172.31.80.9 is chiark's virtual address for the Relativity tunnel. |
| 577 | |
| 578 | > 30,130,1800 \ |
| 579 | |
| 580 | These are the timing parameters. |
| 581 | |
| 582 | > - 172.18.45.0/24 \ |
| 583 | |
| 584 | No remote virtual networks are reachable via chiark. 172.18.45.0/24 |
| 585 | is the Relativity house ethernet, which is to be reachable via the |
| 586 | tunnel from chiark. |
| 587 | |
| 588 | > ssh -o 'ForwardAgent no' -o 'ForwardX11 no' \ |
| 589 | > -o 'BatchMode yes' \ |
| 590 | > -i ~ian/.ssh/identity -l ian \ |
| 591 | > -v chiark.greenend.org.uk \ |
| 592 | > udptunnel |
| 593 | |
| 594 | This is the ssh invocation to run udptunnel at the far end. |
| 595 | |
| 596 | At Relativity we put the udptunnel invocation in a file and run it |
| 597 | out of inittab, like this: |
| 598 | |
| 599 | t0:235:respawn:/usr/local/sbin/really -u ian /usr/local/sbin/udptunnel-invoke 2>&1 | logger -p local2.info -t tunnel-chiark |
| 600 | |
| 601 | |
| 602 | 7. Copyright notice |
| 603 | |
| 604 | Copyright (C) 1999-2000 Ian Jackson |
| 605 | |
| 606 | This is free software; you can redistribute it and/or modify it |
| 607 | under the terms of the GNU General Public License as published by |
| 608 | the Free Software Foundation; either version 2 of the License, or |
| 609 | (at your option) any later version. |
| 610 | |
| 611 | This program is distributed in the hope that it will be useful, but |
| 612 | WITHOUT ANY WARRANTY; without even the implied warranty of |
| 613 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
| 614 | General Public License for more details. |
| 615 | |
| 616 | You should have received a copy of the GNU General Public License |
| 617 | along with userv-utils; if not, write to the Free Software |
| 618 | Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. |
| 619 | |
| 620 | |
| 621 | $Id: INSTALL,v 1.4 2000/09/18 00:31:11 ian Exp $ |