| 1 |
neysx 07/05/23 08:50:13 |
| 2 |
|
| 3 |
Added: vpnc-howto.xml |
| 4 |
Log: |
| 5 |
#97760 updated and moved to /doc/en/ |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/doc/en/vpnc-howto.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/vpnc-howto.xml?rev=1.1&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/doc/en/vpnc-howto.xml?rev=1.1&content-type=text/plain |
| 12 |
|
| 13 |
Index: vpnc-howto.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version='1.0' encoding='UTF-8'?> |
| 16 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/vpnc-howto.xml,v 1.1 2007/05/23 08:50:13 neysx Exp $ --> |
| 17 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 18 |
|
| 19 |
<guide link="/doc/en/vpnc-howto.xml" disclaimer="draft"> |
| 20 |
|
| 21 |
<title>Gentoo vpnc HOWTO</title> |
| 22 |
|
| 23 |
<author title="Author"> |
| 24 |
<mail link="dhaskew@×××××××××.net">David H. Askew</mail> |
| 25 |
</author> |
| 26 |
<author title="Contributor"> |
| 27 |
<mail link="swift@g.o">Sven Vermeulen</mail> |
| 28 |
</author> |
| 29 |
<author title="Contributor"> |
| 30 |
<mail link="opfer@g.o">Christian Faulhammer</mail> |
| 31 |
</author> |
| 32 |
|
| 33 |
<abstract> |
| 34 |
This document details how to connect your workstation to a Cisco VPN |
| 35 |
concentrator utilizing vpnc to manage the connection. |
| 36 |
</abstract> |
| 37 |
|
| 38 |
<!-- The content of this document is licensed under the CC-BY-SA license --> |
| 39 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 40 |
<license/> |
| 41 |
|
| 42 |
<version>0.14</version> |
| 43 |
<date>2007-05-23</date> |
| 44 |
|
| 45 |
<chapter> |
| 46 |
<title>Introduction</title> |
| 47 |
<section> |
| 48 |
<body> |
| 49 |
|
| 50 |
<p> |
| 51 |
If you're reading this, then you likely need to connect to your office network |
| 52 |
from home or during travel. Many companies utilize Cisco 3000 VPN concentrators |
| 53 |
for their VPN needs, and I am willing to bet that most Linux newbies think that |
| 54 |
they are forced to use Windows to connect to them. Well this document informs |
| 55 |
you that connecting to a Cisco VPN is very possible and will hopefully enable |
| 56 |
you to setup a working tunnel using your Gentoo workstation or laptop. |
| 57 |
</p> |
| 58 |
|
| 59 |
</body> |
| 60 |
</section> |
| 61 |
<section> |
| 62 |
<title>What this document is</title> |
| 63 |
<body> |
| 64 |
|
| 65 |
<ul> |
| 66 |
<li>A guide to the basic workings of <c>vpnc</c></li> |
| 67 |
<li>A discussion of DNS and routing issues that relate to VPNs</li> |
| 68 |
<li>Examples of managing VPN sessions</li> |
| 69 |
<li>Useful tips and tricks (hopefully)</li> |
| 70 |
</ul> |
| 71 |
|
| 72 |
</body> |
| 73 |
</section> |
| 74 |
<section> |
| 75 |
<title>What this document is not</title> |
| 76 |
<body> |
| 77 |
|
| 78 |
<ul> |
| 79 |
<li>An in-depth guide to VPN/encryption technologies</li> |
| 80 |
<li>A feature by feature explanation of <c>vpnc</c></li> |
| 81 |
</ul> |
| 82 |
|
| 83 |
</body> |
| 84 |
</section> |
| 85 |
<section> |
| 86 |
<title>Assumptions</title> |
| 87 |
<body> |
| 88 |
|
| 89 |
<p> |
| 90 |
The assumptions made at this point are: |
| 91 |
</p> |
| 92 |
|
| 93 |
<ul> |
| 94 |
<li>You have Gentoo installed</li> |
| 95 |
<li>You have Internet access</li> |
| 96 |
<li>You want to connect to a Cisco 3000 VPN concentrator</li> |
| 97 |
<li>You know how to configure, build and install a new kernel</li> |
| 98 |
</ul> |
| 99 |
|
| 100 |
</body> |
| 101 |
</section> |
| 102 |
</chapter> |
| 103 |
|
| 104 |
<chapter> |
| 105 |
<title>Kernel Configuration</title> |
| 106 |
<section> |
| 107 |
<body> |
| 108 |
|
| 109 |
<p> |
| 110 |
In order for Linux to be able to open a VPN connection <e>Universal TUN/TAP |
| 111 |
device driver support</e> must be enabled in the kernel. What is it and why do |
| 112 |
you need it? Below is a relatively straight forward explanation from the kernel |
| 113 |
configuration dialog: |
| 114 |
</p> |
| 115 |
|
| 116 |
<pre caption="CONFIG_TUN"> |
| 117 |
TUN/TAP provides packet reception and transmission for user space |
| 118 |
programs. It can be viewed as a simple Point-to-Point or Ethernet |
| 119 |
device, which instead of receiving packets from a physical media, |
| 120 |
receives them from user space program and instead of sending packets |
| 121 |
via physical media writes them to the user space program. |
| 122 |
|
| 123 |
When a program opens /dev/net/tun, driver creates and registers |
| 124 |
corresponding net device tunX or tapX. After a program closed above |
| 125 |
devices, driver will automatically delete tunXX or tapXX device and |
| 126 |
all routes corresponding to it. |
| 127 |
</pre> |
| 128 |
|
| 129 |
<p> |
| 130 |
>From the vpnc ebuild 0.4.0-r1 on, it is tested wether TUN/TAP support is |
| 131 |
enabled. If not, enable it in your kernel config either as module or built-in, |
| 132 |
recompile and reboot. |
| 133 |
</p> |
| 134 |
|
| 135 |
<p> |
| 136 |
You can verify yourself if your kernel has TUN/TAP support with the following |
| 137 |
command: |
| 138 |
</p> |
| 139 |
|
| 140 |
<pre caption="Checking the kernel config"> |
| 141 |
# <i> grep "TUN" /usr/src/linux/.config</i> |
| 142 |
CONFIG_INET_TUNNEL=m |
| 143 |
# CONFIG_INET6_TUNNEL is not set |
| 144 |
# CONFIG_IPV6_TUNNEL is not set |
| 145 |
<comment>(TUN/TAP enabled as a module)</comment> |
| 146 |
CONFIG_TUN=m |
| 147 |
# CONFIG_8139TOO_TUNE_TWISTER is not set |
| 148 |
</pre> |
| 149 |
|
| 150 |
<p> |
| 151 |
As you can see above, <c>CONFIG_TUN=m</c> is compiled as a module. If it is |
| 152 |
disabled in your setup, enable it in your kernel of choice, rebuild, install, |
| 153 |
reboot and return to this document before continuing with the next steps. |
| 154 |
</p> |
| 155 |
|
| 156 |
<pre caption="Configuration location in the kernel configuration dialog"> |
| 157 |
Device Drivers ---> |
| 158 |
Networking support ---> |
| 159 |
[*] Universal TUN/TAP device driver support |
| 160 |
</pre> |
| 161 |
|
| 162 |
<p> |
| 163 |
If you built TUN/TAP support directly into the kernel, you should see |
| 164 |
information from <c>dmesg</c> output like the following: |
| 165 |
</p> |
| 166 |
|
| 167 |
<pre caption="Checking dmesg output"> |
| 168 |
# <i>dmesg | grep TUN</i> |
| 169 |
Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky |
| 170 |
</pre> |
| 171 |
|
| 172 |
<p> |
| 173 |
If you build TUN/TAP support as a module, you first must load the <c>tun</c> |
| 174 |
module: |
| 175 |
</p> |
| 176 |
|
| 177 |
<pre caption="Load tun module"> |
| 178 |
# <i>modprobe tun</i> |
| 179 |
# <i>lsmod</i> |
| 180 |
Module Size Used by |
| 181 |
tun 7296 0 |
| 182 |
nvidia 4050204 12 |
| 183 |
</pre> |
| 184 |
|
| 185 |
<p> |
| 186 |
Now that the <c>tun</c> module is loaded, check <c>dmesg</c> output. You should |
| 187 |
see something like the following: |
| 188 |
</p> |
| 189 |
|
| 190 |
<pre caption="Checking dmesg output"> |
| 191 |
# <i>dmesg | grep TUN</i> |
| 192 |
Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky |
| 193 |
</pre> |
| 194 |
|
| 195 |
</body> |
| 196 |
</section> |
| 197 |
</chapter> |
| 198 |
|
| 199 |
<chapter> |
| 200 |
<title>Install Needed Software</title> |
| 201 |
<section> |
| 202 |
<body> |
| 203 |
|
| 204 |
<p> |
| 205 |
Now that you have a working kernel setup, you need to install |
| 206 |
<c>net-misc/vpnc</c>: |
| 207 |
</p> |
| 208 |
|
| 209 |
<pre caption="Installing vpnc"> |
| 210 |
# <i>emerge -av net-misc/vpnc</i> |
| 211 |
</pre> |
| 212 |
|
| 213 |
</body> |
| 214 |
</section> |
| 215 |
</chapter> |
| 216 |
|
| 217 |
<chapter> |
| 218 |
<title>Example Setup</title> |
| 219 |
<section> |
| 220 |
<body> |
| 221 |
|
| 222 |
<p> |
| 223 |
In order to make the following sections more clear, we need an example setup to |
| 224 |
work from. For the purposes of this exercise, we will assume that you have a |
| 225 |
home network of several computers. All computers are on the 192.168.0.0 / |
| 226 |
255.255.255.0 network. The LAN in question is run by a Gentoo box using an |
| 227 |
iptables firewall, DHCP, caching DNS, etc ... and it masquerades the LAN behind |
| 228 |
the public IP address it receives from an ISP. You also have a workstation on |
| 229 |
the LAN from which you want to be able to VPN into your office with. |
| 230 |
</p> |
| 231 |
|
| 232 |
<p> |
| 233 |
Our example workstation configuration looks like the following: |
| 234 |
</p> |
| 235 |
|
| 236 |
<pre caption="Our workstation configuration"> |
| 237 |
<comment>(Name server configuration)</comment> |
| 238 |
# <i>cat /etc/resolv.conf</i> |
| 239 |
nameserver 192.168.0.1 |
| 240 |
|
| 241 |
<comment>(Network configuration)</comment> |
| 242 |
# <i>cat /etc/hosts</i> |
| 243 |
127.0.0.1 desktop localhost |
| 244 |
192.168.0.1 router |
| 245 |
192.168.2.2 mediacenter |
| 246 |
|
| 247 |
<comment>(Interface configuration)</comment> |
| 248 |
# <i>ifconfig -a</i> |
| 249 |
eth0 Link encap:Ethernet HWaddr 00:11:2F:8D:08:08 |
| 250 |
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 |
| 251 |
inet6 addr: fe80::211:2fff:fe8d:808/64 Scope:Link |
| 252 |
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 |
| 253 |
RX packets:3657889 errors:0 dropped:0 overruns:0 frame:0 |
| 254 |
TX packets:2305893 errors:0 dropped:0 overruns:0 carrier:0 |
| 255 |
collisions:0 txqueuelen:1000 |
| 256 |
RX bytes:2193722103 (2092.0 Mb) TX bytes:1415104432 (1349.5 Mb) |
| 257 |
Interrupt:185 Memory:fac00000-0 |
| 258 |
|
| 259 |
lo Link encap:Local Loopback |
| 260 |
inet addr:127.0.0.1 Mask:255.0.0.0 |
| 261 |
inet6 addr: ::1/128 Scope:Host |
| 262 |
UP LOOPBACK RUNNING MTU:16436 Metric:1 |
| 263 |
RX packets:35510 errors:0 dropped:0 overruns:0 frame:0 |
| 264 |
TX packets:35510 errors:0 dropped:0 overruns:0 carrier:0 |
| 265 |
collisions:0 txqueuelen:0 |
| 266 |
RX bytes:16023838 (15.2 Mb) TX bytes:16023838 (15.2 Mb) |
| 267 |
|
| 268 |
<comment>(Routing information)</comment> |
| 269 |
# <i>netstat -r</i> |
| 270 |
Kernel IP routing table |
| 271 |
Destination Gateway Genmask Flags MSS Window irtt Iface |
| 272 |
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 |
| 273 |
loopback desktop 255.0.0.0 UG 0 0 0 lo |
| 274 |
default router 0.0.0.0 UG 0 0 0 eth0 |
| 275 |
</pre> |
| 276 |
|
| 277 |
</body> |
| 278 |
</section> |
| 279 |
</chapter> |
| 280 |
|
| 281 |
<chapter> |
| 282 |
<title>Configuring vpnc</title> |
| 283 |
<section> |
| 284 |
<body> |
| 285 |
|
| 286 |
<p> |
| 287 |
Now that you have <c>vpnc</c> installed and we have an example to work from, |
| 288 |
let's discuss the basics of setting up <c>vpnc</c>. The configuration file for |
| 289 |
<c>vpnc</c> connection settings can be located in a couple places, depending on |
| 290 |
how many profiles you want to setup. By default, <c>vpnc</c> looks first for |
| 291 |
<path>/etc/vpnc/default.conf</path> for its connection settings. If it doesn't |
| 292 |
find that file, then it looks for <path>/etc/vpnc.conf</path>. This setup will |
| 293 |
only address a single profile example and will use the configuration file |
| 294 |
location <path>/etc/vpnc.conf</path>. Make sure you do not have a |
| 295 |
<path>/etc/vpnc/default.conf</path> file. |
| 296 |
</p> |
| 297 |
|
| 298 |
<pre caption="Example /etc/vpnc.conf file"> |
| 299 |
IPSec gateway vpngateway.domain.org |
| 300 |
IPSec ID group_id |
| 301 |
IPSec secret group_password |
| 302 |
Xauth username network_signon |
| 303 |
Xauth password network_password |
| 304 |
</pre> |
| 305 |
|
| 306 |
<p> |
| 307 |
The configuration file example above should be modified to reflect the |
| 308 |
appropriate values for your setup. The gateway option |
| 309 |
<c>vpngateway.domain.org</c> can be a fully qualified domain name or an IP |
| 310 |
address. The ID and secret options should be given to you by a network |
| 311 |
administrator. If they are hesitant about giving you this info and you |
| 312 |
currently have a working setup on a Windows box which utilizes the official |
| 313 |
Cisco VPN client, then all you have to do is export your profile. The user name |
| 314 |
and password options are for your normal network sign-on, such as a Windows NT |
| 315 |
domain account. |
| 316 |
</p> |
| 317 |
|
| 318 |
<p> |
| 319 |
If you are forced to export your profile from a Windows machine, then what you |
| 320 |
will likely have is a file ending in <path>.pcf</path>. This file will have all |
| 321 |
the information you need. Below is an example: |
| 322 |
</p> |
| 323 |
|
| 324 |
<pre caption="Example profile.pcf file"> |
| 325 |
[main] |
| 326 |
Description= |
| 327 |
Host=VPNGATEWAY.DOMAIN.ORG |
| 328 |
AuthType=1 |
| 329 |
GroupName=group_id |
| 330 |
GroupPwd= |
| 331 |
enc_GroupPwd=F3256220AA200A1D532556024F4F314B0388D48B0FBF2DB12 |
| 332 |
EnableISPConnect=0 |
| 333 |
ISPConnectType=0 |
| 334 |
ISPConnect=FOOBAR |
| 335 |
ISPCommand= |
| 336 |
Username= |
| 337 |
SaveUserPassword=0 |
| 338 |
UserPassword= |
| 339 |
enc_UserPassword= |
| 340 |
NTDomain= |
| 341 |
EnableBackup=0 |
| 342 |
BackupServer= |
| 343 |
EnableMSLogon=1 |
| 344 |
MSLogonType=0 |
| 345 |
EnableNat=1 |
| 346 |
TunnelingMode=0 |
| 347 |
TcpTunnelingPort=10000 |
| 348 |
CertStore=0 |
| 349 |
CertName= |
| 350 |
CertPath= |
| 351 |
CertSubjectName= |
| 352 |
CertSerialHash=00000000000000000000000000000000 |
| 353 |
SendCertChain=0 |
| 354 |
VerifyCertDN= |
| 355 |
DHGroup=2 |
| 356 |
ForceKeepAlives=0 |
| 357 |
PeerTimeout=90 |
| 358 |
EnableLocalLAN=0 |
| 359 |
EnableSplitDNS=1 |
| 360 |
ForceNetLogin=0 |
| 361 |
</pre> |
| 362 |
|
| 363 |
<p> |
| 364 |
In the above example, we can see entries for <c>Host</c>, <c>GroupName</c> and |
| 365 |
<c>enc_GroupPwd</c>. Your <c>Username</c> and <c>UserPassword</c> may or may |
| 366 |
not be exported depending on the setup. To generate a working vpnc |
| 367 |
configuration out of it, you can use <c>pcf2vpnc</c>, included with vpnc. |
| 368 |
</p> |
| 369 |
|
| 370 |
<note> |
| 371 |
You can decrypt the password with the help from the <c>cisco-decrypt</c> |
| 372 |
program, shipped with the latest vpnc. |
| 373 |
</note> |
| 374 |
|
| 375 |
</body> |
| 376 |
</section> |
| 377 |
<section> |
| 378 |
<title>Testing your setup</title> |
| 379 |
<body> |
| 380 |
|
| 381 |
<p> |
| 382 |
Now that you have a configuration in place, it's time to test your setup. To |
| 383 |
start <c>vpnc</c> you do the following: |
| 384 |
</p> |
| 385 |
|
| 386 |
<pre caption="Example vpnc usage"> |
| 387 |
# <i>vpnc</i> |
| 388 |
Enter password for username@×××××××××××××××××.org: |
| 389 |
VPNC started in background (pid: 14788)... |
| 390 |
</pre> |
| 391 |
|
| 392 |
<p> |
| 393 |
As you can see from the above command output, once you type <c>vpnc</c> (as |
| 394 |
root), you are prompted for your password. After entering your password, which |
| 395 |
will not be echoed back to you, the <c>vpnc</c> process will automatically |
| 396 |
become a background process. |
| 397 |
</p> |
| 398 |
|
| 399 |
<note> |
| 400 |
If you specified the <c>Xauth password</c> option in your <c>vpnc</c> config |
| 401 |
file, then you will not be prompted for your password at <c>vpnc</c> startup. |
| 402 |
Additionally, if <c>vpnc</c> needs some extra options not specified in the |
| 403 |
configuration file, or if you have forgotten something, don't worry, it will |
| 404 |
ask you for it. |
| 405 |
</note> |
| 406 |
|
| 407 |
<pre caption="Sample interface configuration changes made by vpnc"> |
| 408 |
# <i> ifconfig -a</i> |
| 409 |
eth1 Link encap:Ethernet HWaddr 00:11:2F:8D:08:08 |
| 410 |
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0 |
| 411 |
inet6 addr: fe80::211:2fff:fe8d:808/64 Scope:Link |
| 412 |
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 |
| 413 |
RX packets:2101119 errors:0 dropped:0 overruns:0 frame:0 |
| 414 |
TX packets:1577559 errors:0 dropped:0 overruns:0 carrier:0 |
| 415 |
collisions:0 txqueuelen:1000 |
| 416 |
RX bytes:1757862627 (1676.4 Mb) TX bytes:732200131 (698.2 Mb) |
| 417 |
Interrupt:177 Memory:faa00000-0 |
| 418 |
|
| 419 |
sit0 Link encap:IPv6-in-IPv4 |
| 420 |
NOARP MTU:1480 Metric:1 |
| 421 |
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 |
| 422 |
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 |
| 423 |
collisions:0 txqueuelen:0 |
| 424 |
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) |
| 425 |
|
| 426 |
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 |
| 427 |
inet addr:192.168.160.42 P-t-P:192.168.160.42 Mask:255.255.255.255 |
| 428 |
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1412 Metric:1 |
| 429 |
RX packets:1 errors:0 dropped:0 overruns:0 frame:0 |
| 430 |
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 |
| 431 |
collisions:0 txqueuelen:500 |
| 432 |
RX bytes:60 (60.0 b) TX bytes:616 (616.0 b) |
| 433 |
|
| 434 |
</pre> |
| 435 |
|
| 436 |
<pre caption="Sample routing modifications made by vpnc"> |
| 437 |
# <i>netstat -r</i> |
| 438 |
Kernel IP routing table |
| 439 |
Destination Gateway Genmask Flags MSS Window irtt Iface |
| 440 |
vpn01.domain.or router 255.255.255.255 UGH 1500 0 0 eth1 |
| 441 |
192.168.0.0 * 255.255.255.0 U 0 0 0 eth1 |
| 442 |
loopback desktop 255.0.0.0 UG 0 0 0 lo |
| 443 |
default * 0.0.0.0 U 0 0 0 tun0 |
| 444 |
</pre> |
| 445 |
|
| 446 |
<p> |
| 447 |
As you can see from the above command output(s), <c>vpnc</c> has done the |
| 448 |
following: |
| 449 |
</p> |
| 450 |
|
| 451 |
<ul> |
| 452 |
<li> |
| 453 |
Created the tun0 network interface, a virtual interface to handle |
| 454 |
the traffic across your VPN tunnel |
| 455 |
</li> |
| 456 |
<li>Obtained the IP address for the tun0 device from your VPN provider</li> |
| 457 |
<li>Set the default route to your VPN gateway</li> |
| 458 |
</ul> |
| 459 |
|
| 460 |
<p> |
| 461 |
At this point, your workstation is capable of communicating with hosts via the |
| 462 |
VPN, but only by IP address. As you might have noticed, <c>vpnc</c> did not |
| 463 |
alter your <path>/etc/resolv.conf</path>, thus not setting up DNS services for |
| 464 |
the virtual link. Also, because <c>vpnc</c> sets your default route to your VPN |
| 465 |
gateway, all network traffic will travel across the VPN, even if it destined |
| 466 |
for the Internet or elsewhere not specifically specified by additional routes. |
| 467 |
For some, this basic type of connection may be satisfactory, but for most, |
| 468 |
additional steps need to be taken. |
| 469 |
</p> |
| 470 |
|
| 471 |
<p> |
| 472 |
Additional things you might want to have: |
| 473 |
</p> |
| 474 |
|
| 475 |
<ul> |
| 476 |
<li>DNS for the VPN</li> |
| 477 |
<li> |
| 478 |
A routing setup that will only send traffic destined for the VPN down the |
| 479 |
virtual tunnel. This way, you can browse the Internet while connected to |
| 480 |
the VPN, without your personal web/p2p etc ... traffic going across the |
| 481 |
tunnel. |
| 482 |
</li> |
| 483 |
<li> |
| 484 |
A script to manage all this, because <c>vpnc</c> just doesn't do enough by |
| 485 |
default. |
| 486 |
</li> |
| 487 |
</ul> |
| 488 |
|
| 489 |
<p> |
| 490 |
When you are ready to end the VPN session, execute <c>vpnc-disconnect</c>. An |
| 491 |
example is shown below. |
| 492 |
</p> |
| 493 |
|
| 494 |
<note> |
| 495 |
Don't disconnect yet, because we have additional things to test. The example |
| 496 |
below is just for informational purposes. |
| 497 |
</note> |
| 498 |
|
| 499 |
<pre caption="vpnc-disconnect"> |
| 500 |
# <i>vpnc-disconnect</i> |
| 501 |
Terminating vpnc daemon (pid: 26250) |
| 502 |
</pre> |
| 503 |
|
| 504 |
</body> |
| 505 |
</section> |
| 506 |
</chapter> |
| 507 |
|
| 508 |
<chapter> |
| 509 |
<title>Set up DNS</title> |
| 510 |
<section> |
| 511 |
<body> |
| 512 |
|
| 513 |
<p> |
| 514 |
Unfortunately, <c>vpnc</c> doesn't handle the setup and management of DNS for |
| 515 |
your newly established tunnel. The user is left to decide how DNS should be |
| 516 |
handled. You could just overwrite <path>/etc/resolv.conf</path> when you |
| 517 |
connect, but that would utilize your VPN DNS for all DNS queries regardless of |
| 518 |
whether or not the traffic is destined for your VPN tunnel. This is a very |
| 519 |
functional solution and if you simply need to connect to the tunnel, do your |
| 520 |
work, and then disconnect, read no further. But, if you want to be able to |
| 521 |
leave your tunnel connected for lengthy periods of time and don't want your |
| 522 |
work DNS servers handling requests for your personal traffic, read on. |
| 523 |
</p> |
| 524 |
|
| 525 |
<p> |
| 526 |
The ideal setup would allow you to separate your DNS queries into two |
| 527 |
categories: VPN-related and other. Under this setup, all VPN-related DNS |
| 528 |
queries would be answered by DNS servers located at the other end of your VPN |
| 529 |
tunnel and all other queries would continue to be answered by local or ISP |
| 530 |
supplied DNS servers. This is the setup that will be demonstrated here. |
| 531 |
</p> |
| 532 |
|
| 533 |
<note> |
| 534 |
We will consider VPN-related DNS queries to be any query belonging to the |
| 535 |
example.org domain, such as host1.example.org or server1.example.org. |
| 536 |
</note> |
| 537 |
|
| 538 |
<p> |
| 539 |
So how do you set things up, so that only requests made to hosts on the |
| 540 |
example.org domain get sent to VPN supplied DNS servers? Well, you're going to |
| 541 |
need to install a local DNS server, but don't worry, it's much easier than you |
| 542 |
think. There are several software packages that can handle the type of setup we |
| 543 |
desire, but for the purposes of this demonstration, <c>dnsmasq</c> will be |
| 544 |
utilized. Let's emerge it now: |
| 545 |
</p> |
| 546 |
|
| 547 |
<note> |
| 548 |
This DNS server software will not be available to the network, and will only |
| 549 |
answer requests from localhost, <c>127.0.0.1</c>. |
| 550 |
</note> |
| 551 |
|
| 552 |
<pre caption="Install dnsmasq"> |
| 553 |
# <i> emerge dnsmasq</i> |
| 554 |
</pre> |
| 555 |
|
| 556 |
<p> |
| 557 |
Now you need to add an option to your <c>dnsmasq</c> startup options. Edit the |
| 558 |
following option to suit your needs. Substitute .example.org with the |
| 559 |
appropriate domain and the IP address with a valid DNS server that belongs to |
| 560 |
the VPN tunnel. |
| 561 |
</p> |
| 562 |
|
| 563 |
<pre caption="/etc/conf.d/dnsmasq"> |
| 564 |
Config file for /etc/init.d/dnsmasq |
| 565 |
|
| 566 |
# See the dnsmasq(8) man page for possible options to put here. |
| 567 |
DNSMASQ_OPTS="-S /.example.org/192.168.125.10" |
| 568 |
</pre> |
| 569 |
|
| 570 |
<p> |
| 571 |
Next, make sure that the first entry in <path>/etc/resolv.conf</path> is your |
| 572 |
local host <c>127.0.0.1</c>, followed by the location of the backup DNS servers |
| 573 |
that should handle the DNS traffic in case dnsmasq fails to start, or if it |
| 574 |
needs to forward a DNS query it doesn't currently have in its cache. An example |
| 575 |
<path>/etc/resolv.conf</path> is shown below. |
| 576 |
</p> |
| 577 |
|
| 578 |
<pre caption="/etc/resolv.conf"> |
| 579 |
nameserver 127.0.0.1 |
| 580 |
nameserver 192.168.0.1 |
| 581 |
</pre> |
| 582 |
|
| 583 |
<p> |
| 584 |
Now that you have setup a rule for your VPN tunnel DNS, you need to start |
| 585 |
<c>dnsmasq</c>. |
| 586 |
</p> |
| 587 |
|
| 588 |
<pre caption="Starting up dnsmasq"> |
| 589 |
# <i>/etc/init.d/dnsmasq start</i> |
| 590 |
# <i>rc-update add dnsmasq default</i> |
| 591 |
</pre> |
| 592 |
|
| 593 |
</body> |
| 594 |
</section> |
| 595 |
</chapter> |
| 596 |
|
| 597 |
<chapter> |
| 598 |
<title>Configuring the routing table</title> |
| 599 |
<section> |
| 600 |
<body> |
| 601 |
|
| 602 |
<p> |
| 603 |
The ideal scenario would be if only the traffic destined for VPN tunnel would |
| 604 |
travel across the link. At this point, you have a VPN tunnel setup and all |
| 605 |
traffic will travel across the tunnel, unless you specify additional routes. In |
| 606 |
order to fix this situation you need to know what networks are available to you |
| 607 |
on your VPN. The easiest way to find out the needed information is to ask a |
| 608 |
network administrator, but sometimes they are reluctant to answer such |
| 609 |
questions. If your local network admin wont provide the needed information, |
| 610 |
some trial and error experiments will be required. |
| 611 |
</p> |
| 612 |
|
| 613 |
<p> |
| 614 |
When the VPN tunnel was started, <c>vpnc</c> set the default route to the |
| 615 |
tunnel. So you must set your default route back to normal, so that things work |
| 616 |
as expected. |
| 617 |
</p> |
| 618 |
|
| 619 |
<pre caption="Resetting your default route"> |
| 620 |
# <i>route add default gw 192.168.0.1</i> |
| 621 |
</pre> |
| 622 |
|
| 623 |
<p> |
| 624 |
Earlier, when DNS services were being configured for your VPN, you specified a |
| 625 |
DNS server to handle your example.org domain. You need to add a route for the |
| 626 |
192.168.125.0 subnet so that DNS queries will work. |
| 627 |
</p> |
| 628 |
|
| 629 |
<pre caption="Adding a route for dns"> |
| 630 |
# <i>route add -net 192.168.160.0 netmask 255.255.255.0 dev tun0</i> |
| 631 |
</pre> |
| 632 |
|
| 633 |
<p> |
| 634 |
At this point, you should add any additional routes for known networks. If your |
| 635 |
friendly network administrator gave you the required info, great. Otherwise, |
| 636 |
you might need to ping hosts you will be connecting to frequently, to give |
| 637 |
yourself an idea about what your routing table should look like. |
| 638 |
</p> |
| 639 |
|
| 640 |
<note> |
| 641 |
Due to your setup, when using VPN network services by name, you must specify |
| 642 |
the fully qualified domain name, for instance: webserver1.example.org |
| 643 |
</note> |
| 644 |
|
| 645 |
<pre caption="Ping example"> |
| 646 |
# <i>ping intranet1.example.org</i> |
| 647 |
PING intranet1.example.org (172.25.230.29) 56(84) bytes of data. |
| 648 |
|
| 649 |
|
| 650 |
--- intranet.example.org ping statistics --- |
| 651 |
18 packets transmitted, 0 received, 100% packet loss, time 16997ms |
| 652 |
</pre> |
| 653 |
|
| 654 |
<p> |
| 655 |
As you can see from the above example, the ping probes to |
| 656 |
<c>intranet1.example.org</c> were unsuccessful. So we need to add a route for |
| 657 |
that subnet. |
| 658 |
</p> |
| 659 |
|
| 660 |
<pre caption="another route command example"> |
| 661 |
# <i>route add -net 172.25.230.0 netmask 255.255.255.0 dev tun0</i> |
| 662 |
</pre> |
| 663 |
|
| 664 |
<p> |
| 665 |
A few ping and route commands later, you should be well on your way to a well |
| 666 |
working routing table. |
| 667 |
</p> |
| 668 |
|
| 669 |
</body> |
| 670 |
</section> |
| 671 |
</chapter> |
| 672 |
|
| 673 |
<chapter> |
| 674 |
<title>Manage the connection</title> |
| 675 |
<section> |
| 676 |
<title>Calling vpnc when needed</title> |
| 677 |
<body> |
| 678 |
|
| 679 |
<p> |
| 680 |
Next is an example script to manage the VPN connection. You could execute it |
| 681 |
(as root) from an xterm to start a connection to your VPN. Then all you have to |
| 682 |
do is press return to disconnect the VPN. Obviously you will need to modify |
| 683 |
this for your setup, remembering to add all the additional routes that you may |
| 684 |
need. |
| 685 |
</p> |
| 686 |
|
| 687 |
<pre caption="Example session management script"> |
| 688 |
#!/bin/bash |
| 689 |
|
| 690 |
source /sbin/functions.sh |
| 691 |
|
| 692 |
ebegin "Connecting to the VPN" |
| 693 |
vpnc |
| 694 |
eend |
| 695 |
|
| 696 |
ebegin "Modifying the routing table" |
| 697 |
route add default gw 192.168.0.1 |
| 698 |
route add -net 172.25.230.0 netmask 255.255.255.0 dev tun0 |
| 699 |
route add -net 192.168.160.0 netmask 255.255.255.0 dev tun0 |
| 700 |
route add -net 192.168.125.0 netmask 255.255.255.0 dev tun0 |
| 701 |
eend |
| 702 |
|
| 703 |
einfo "Press any key to disconnect ..." |
| 704 |
|
| 705 |
read $disconnect |
| 706 |
|
| 707 |
ebegin "Disconnecting from the VPN" |
| 708 |
vpnc-disconnect |
| 709 |
eend |
| 710 |
ebegin "Reconfiguring the default routing table" |
| 711 |
route add default gw 192.168.0.1 |
| 712 |
eend |
| 713 |
|
| 714 |
einfo "VPN should now be disconnected" |
| 715 |
</pre> |
| 716 |
|
| 717 |
</body> |
| 718 |
</section> |
| 719 |
<section> |
| 720 |
<title>Start vpnc on boot</title> |
| 721 |
<body> |
| 722 |
|
| 723 |
<p> |
| 724 |
Version 0.4.0-r1 of vpnc brings an init file for Gentoo which even can handle |
| 725 |
multiple configurations. You will find a file <path>/etc/init.d/vpnc</path> |
| 726 |
which can be handled by the usual means of init scripts. The default looks for |
| 727 |
<path>/etc/vpnc/vpnc.conf</path>, the scheme is sketched in the following |
| 728 |
table. |
| 729 |
</p> |
| 730 |
|
| 731 |
<table> |
| 732 |
<tr> |
| 733 |
<th>init script name</th> |
| 734 |
<th>needed configuration file</th> |
| 735 |
</tr> |
| 736 |
<tr> |
| 737 |
<ti>/etc/init.d/vpnc</ti> |
| 738 |
<ti>/etc/vpnc/vpnc.conf</ti> |
| 739 |
</tr> |
| 740 |
<tr> |
| 741 |
<ti>/etc/init.d/vpnc.work</ti> |
| 742 |
<ti>/etc/vpnc/work.conf</ti> |
| 743 |
</tr> |
| 744 |
</table> |
| 745 |
|
| 746 |
<p> |
| 747 |
Add vpnc to default runlevel with the following commands (in this case for the |
| 748 |
standard configuration). Don't forget to add the tun module (if you have built |
| 749 |
it that way) to the kernels autoload mechanism at startup. |
| 750 |
</p> |
| 751 |
|
| 752 |
<pre caption="Adding vpnc to startup scripts"> |
| 753 |
# <i>rc-update add vpnc default</i> |
| 754 |
</pre> |
| 755 |
|
| 756 |
<note> |
| 757 |
The init scripts don't handle DNS separation. |
| 758 |
</note> |
| 759 |
|
| 760 |
</body> |
| 761 |
</section> |
| 762 |
</chapter> |
| 763 |
|
| 764 |
<chapter> |
| 765 |
<title>Tips and Tricks</title> |
| 766 |
<section> |
| 767 |
<body> |
| 768 |
|
| 769 |
<p> |
| 770 |
If you are looking for a linux application that supports RDP (Remote Desktop |
| 771 |
Protocol) then give <c>grdesktop</c> a try. It's a GUI app written in Gtk that |
| 772 |
fits in well with a gnome desktop, but doesn't require it. If you don't want |
| 773 |
the GUI configuration dialogs that grdesktop provides, then just install |
| 774 |
<c>rdesktop</c>. Ultimately, grdesktop is just a frontend for rdesktop. |
| 775 |
</p> |
| 776 |
|
| 777 |
<p> |
| 778 |
If you are a KDE user, you might want to try <c>kvpnc</c>. It a appears to be a |
| 779 |
very mature VPN management GUI. |
| 780 |
</p> |
| 781 |
|
| 782 |
<p> |
| 783 |
If you need to connect to a windows machine which doesn't have a DNS entry, and |
| 784 |
you know the address of an available WINS server, you can use a tool called |
| 785 |
<c>nmblookup</c> to query the WINS server for the host name of the machine you |
| 786 |
want to connect to. Unfortunately, you have to install samba to get it, but if |
| 787 |
you are going to be working with boxes running Windows you might as well want |
| 788 |
to install samba, because it includes several other useful tools. |
| 789 |
</p> |
| 790 |
|
| 791 |
<pre caption="Installing samba"> |
| 792 |
# <i>emerge -av samba</i> |
| 793 |
</pre> |
| 794 |
|
| 795 |
<p> |
| 796 |
When you have samba and its tools installed, test <c>nmblookup</c> by asking |
| 797 |
the WINS server at IP address 192.168.125.11 about a host named wintelbox1. |
| 798 |
</p> |
| 799 |
|
| 800 |
<pre caption="nmblookup example"> |
| 801 |
# <i>nmblookup -U 192.168.125.11 -R 'wintelbox1'</i> |
| 802 |
querying wintelbox1 on 192.168.125.11 |
| 803 |
172.25.230.76 wintelbox1 |
| 804 |
</pre> |
| 805 |
|
| 806 |
</body> |
| 807 |
</section> |
| 808 |
</chapter> |
| 809 |
|
| 810 |
<chapter> |
| 811 |
<title>Useful Links</title> |
| 812 |
<section> |
| 813 |
<body> |
| 814 |
|
| 815 |
<ul> |
| 816 |
<li> |
| 817 |
<uri link="http://www.unix-ag.uni-kl.de/~massar/vpnc/">vpnc homepage</uri> |
| 818 |
</li> |
| 819 |
<li> |
| 820 |
<uri link="http://home.gna.org/kvpnc/en/index.html">kvpnc homepage</uri> |
| 821 |
</li> |
| 822 |
<li> |
| 823 |
<uri link="http://www.nongnu.org/grdesktop/">grdesktop homepage</uri> |
| 824 |
</li> |
| 825 |
</ul> |
| 826 |
|
| 827 |
</body> |
| 828 |
</section> |
| 829 |
</chapter> |
| 830 |
|
| 831 |
<chapter> |
| 832 |
<title>Final Notes</title> |
| 833 |
<section> |
| 834 |
<body> |
| 835 |
|
| 836 |
<p> |
| 837 |
Hopefully by now you have been able to connect to your VPN of choice and are |
| 838 |
well on your way to remote office work. Feel free to file a bug at <uri |
| 839 |
link="http://bugs.gentoo.org">bugs.gentoo.org</uri> should you find a mistake |
| 840 |
or wish to make an addition or recommendation regarding this document. |
| 841 |
</p> |
| 842 |
|
| 843 |
</body> |
| 844 |
</section> |
| 845 |
</chapter> |
| 846 |
</guide> |
| 847 |
|
| 848 |
|
| 849 |
|
| 850 |
-- |
| 851 |
gentoo-doc-cvs@g.o mailing list |
Archives