ipsec.html

FreeBSD安装说明概述 FreeBSD 提供了一个以文字为主

<p>Configuring the tunnel is a two step process. First the tunnel must be told what the
outside (or public) IP addresses are, using <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">gifconfig</span>(8)</span>. Then the private IP addresses must be
configured using <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">ifconfig</span>(8)</span>.</p>

<p>On the gateway machine on network #1 you would run the following two commands to
configure the tunnel.</p>

<pre class="PROGRAMLISTING">
gifconfig gif0 A.B.C.D W.X.Y.Z
ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff
     
</pre>

<p>On the other gateway machine you run the same commands, but with the order of the IP
addresses reversed.</p>

<pre class="PROGRAMLISTING">
gifconfig gif0 W.X.Y.Z A.B.C.D
ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff
     
</pre>

<p>You can then run:</p>

<pre class="PROGRAMLISTING">
gifconfig gif0
</pre>

<p>to see the configuration. For example, on the network #1 gateway, you would see
this:</p>

<pre class="SCREEN">
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">gifconfig gif0</kbd>
gif0: flags=8011&lt;UP,POINTTOPOINT,MULTICAST&gt; mtu 1280
inet 192.168.1.1 --&gt; 192.168.2.1 netmask 0xffffffff
physical address inet A.B.C.D --&gt; W.X.Y.Z
     
</pre>

<p>As you can see, a tunnel has been created between the physical addresses <tt
class="HOSTID">A.B.C.D</tt> and <tt class="HOSTID">W.X.Y.Z</tt>, and the traffic allowed
through the tunnel is that between <tt class="HOSTID">192.168.1.1</tt> and <tt
class="HOSTID">192.168.2.1</tt>.</p>

<p>This will also have added an entry to the routing table on both machines, which you
can examine with the command <tt class="COMMAND">netstat -rn</tt>. This output is from
the gateway host on network #1.</p>

<pre class="SCREEN">
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">netstat -rn</kbd>
Routing tables

Internet:
Destination      Gateway       Flags    Refs    Use    Netif  Expire
...
192.168.2.1      192.168.1.1   UH        0        0    gif0
...
     
</pre>

<p>As the ``Flags'' value indicates, this is a host route, which means that each gateway
knows how to reach the other gateway, but they do not know how to reach the rest of their
respective networks. That problem will be fixed shortly.</p>

<p>It is likely that you are running a firewall on both machines. This will need to be
circumvented for your VPN traffic. You might want to allow all traffic between both
networks, or you might want to include firewall rules that protect both ends of the VPN
from one another.</p>

<p>It greatly simplifies testing if you configure the firewall to allow all traffic
through the VPN. You can always tighten things up later. If you are using <span
class="CITEREFENTRY"><span class="REFENTRYTITLE">ipfw</span>(8)</span> on the gateway
machines then a command like</p>

<pre class="PROGRAMLISTING">
ipfw add 1 allow ip from any to any via gif0
</pre>

<p>will allow all traffic between the two end points of the VPN, without affecting your
other firewall rules. Obviously you will need to run this command on both gateway
hosts.</p>

<p>This is sufficient to allow each gateway machine to ping the other. On <tt
class="HOSTID">192.168.1.1</tt>, you should be able to run</p>

<pre class="PROGRAMLISTING">
ping 192.168.2.1
</pre>

<p>and get a response, and you should be able to do the same thing on the other gateway
machine.</p>

<p>However, you will not be able to reach internal machines on either network yet. This
is because of the routing -- although the gateway machines know how to reach one another,
they do not know how to reach the network behind each one.</p>

<p>To solve this problem you must add a static route on each gateway machine. The command
to do this on the first gateway would be:</p>

<pre class="PROGRAMLISTING">
route add 192.168.2.0 192.168.2.1 netmask 0xffffff00
     
</pre>

<p>This says ``In order to reach the hosts on the network <tt
class="HOSTID">192.168.2.0</tt>, send the packets to the host <tt
class="HOSTID">192.168.2.1</tt>''. You will need to run a similar command on the other
gateway, but with the <tt class="HOSTID">192.168.1.x</tt> addresses instead.</p>

<p>IP traffic from hosts on one network will now be able to reach hosts on the other
network.</p>

<p>That has now created two thirds of a VPN between the two networks, in as much as it is
``virtual'' and it is a ``network''. It is not private yet. You can test this using <span
class="CITEREFENTRY"><span class="REFENTRYTITLE">ping</span>(8)</span> and <span
class="CITEREFENTRY"><span class="REFENTRYTITLE">tcpdump</span>(1)</span>. Log in to the
gateway host and run</p>

<pre class="PROGRAMLISTING">
tcpdump dst host 192.168.2.1
</pre>

<p>In another log in session on the same host run</p>

<pre class="PROGRAMLISTING">
ping 192.168.2.1
</pre>

<p>You will see output that looks something like this:</p>

<pre class="PROGRAMLISTING">
16:10:24.018080 192.168.1.1 &gt; 192.168.2.1: icmp: echo request
16:10:24.018109 192.168.1.1 &gt; 192.168.2.1: icmp: echo reply
16:10:25.018814 192.168.1.1 &gt; 192.168.2.1: icmp: echo request
16:10:25.018847 192.168.1.1 &gt; 192.168.2.1: icmp: echo reply
16:10:26.028896 192.168.1.1 &gt; 192.168.2.1: icmp: echo request
16:10:26.029112 192.168.1.1 &gt; 192.168.2.1: icmp: echo reply
     
</pre>

<p>As you can see, the ICMP messages are going back and forth unencrypted. If you had
used the <var class="OPTION">-s</var> parameter to <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">tcpdump</span>(1)</span> to grab more bytes of data from the
packets you would see more information.</p>

<p>Obviously this is unacceptable. The next section will discuss securing the link
between the two networks so that it all traffic is automatically encrypted.</p>

<p><b>Summary:</b></p>

<ul>
<li>
<p>Configure both kernels with ``pseudo-device gif''.</p>
</li>

<li>
<p>Edit <tt class="FILENAME">/etc/rc.conf</tt> on gateway host #1 and add the following
lines (replacing IP addresses as necessary).</p>

<pre class="PROGRAMLISTING">
gifconfig_gif0="A.B.C.D W.X.Y.Z"
ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff"
static_routes="vpn"
route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00"
         
</pre>
</li>

<li>
<p>Edit your firewall script (<tt class="FILENAME">/etc/rc.firewall</tt>, or similar) on
both hosts, and add</p>

<pre class="PROGRAMLISTING">
ipfw add 1 allow ip from any to any via gif0
</pre>
</li>

<li>
<p>Make similar changes to <tt class="FILENAME">/etc/rc.conf</tt> on gateway host #2,
reversing the order of IP addresses.</p>
</li>
</ul>
</div>

<div class="SECT3">
<h3 class="SECT3"><a id="AEN12779" name="AEN12779">10.10.3.2. Step 2: Securing the
link</a></h3>

<p>To secure the link we will be using IPsec. IPsec provides a mechanism for two hosts to
agree on an encryption key, and to then use this key in order to encrypt data between the
two hosts.</p>

<p>The are two areas of configuration to be considered here.</p>

<ol type="1">
<li>
<p>There must be a mechanism for two hosts to agree on the encryption mechanism to use.
Once two hosts have agreed on this mechanism there is said to be a ``security
association'' between them.</p>
</li>

<li>
<p>There must be a mechanism for specifying which traffic should be encrypted. Obviously,
you don't want to encrypt all your outgoing traffic -- you only want to encrypt the
traffic that is part of the VPN. The rules that you put in place to determine what
traffic will be encrypted are called ``security policies''.</p>
</li>
</ol>

<p>Security associations and security policies are both maintained by the kernel, and can
be modified by userland programs. However, before you can do this you must configure the
kernel to support IPsec and the Encapsulated Security Payload (ESP) protocol. This is
done by configuring a kernel with:</p>

<pre class="PROGRAMLISTING">
options IPSEC
options IPSEC_ESP
      
</pre>

<p>and recompiling, reinstalling, and rebooting. As before you will need to do this to
the kernels on both of the gateway hosts.</p>

<p>You have two choices when it comes to setting up security associations. You can
configure them by hand between two hosts, which entails choosing the encryption
algorithm, encryption keys, and so forth, or you can use daemons that implement the
Internet Key Exchange protocol (IKE) to do this for you.</p>

<p>I recommend the latter. Apart from anything else, it is easier to set up.</p>

<p>Editing and displaying security policies is carried out using <span
class="CITEREFENTRY"><span class="REFENTRYTITLE">setkey</span>(8)</span>. By analogy, <tt
class="COMMAND">setkey</tt> is to the kernel's security policy tables as <span
class="CITEREFENTRY"><span class="REFENTRYTITLE">route</span>(8)</span> is to the
kernel's routing tables. <tt class="COMMAND">setkey</tt> can also display the current
security associations, and to continue the analogy further, is akin to <tt
class="COMMAND">netstat -r</tt> in that respect.</p>

<p>There are a number of choices for daemons to manage security associations with
FreeBSD. This article will describe how to use one of these, racoon. racoon is in the
FreeBSD ports collection, in the security/ category, and is installed in the usual
way.</p>

<p>racoon must be run on both gateway hosts. On each host it is configured with the IP
address of the other end of the VPN, and a secret key (which you choose, and must be the
same on both gateways).</p>

<p>The two daemons then contact one another, confirm that they are who they say they are
(by using the secret key that you configured). The daemons then generate a new secret
key, and use this to encrypt the traffic over the VPN. They periodically change this
secret, so that even if an attacker were to crack one of the keys (which is as
theoretically close to unfeasible as it gets) it won't do them much good -- by the time
they've cracked the key the two daemons have chosen another one.</p>

<p>racoon's configuration is stored in <tt class="FILENAME">${PREFIX}/etc/racoon</tt>.
You should find a configuration file there, which should not need to be changed too much.
The other component of racoon's configuration, which you will need to change, is the
``pre-shared key''.</p>

<p>The default racoon configuration expects to find this in the file <tt
class="FILENAME">${PREFIX}/etc/racoon/psk.txt</tt>. It is important to note that the
pre-shared key is <span class="emphasis"><i class="EMPHASIS">not</i></span> the key that
will be used to encrypt your traffic across the VPN link, it is simply a token that
allows the key management daemons to trust one another.</p>

<p><tt class="FILENAME">psk.txt</tt> contains a line for each remote site you are dealing
with. In this example, where there are two sites, each <tt class="FILENAME">psk.txt</tt>
file will contain one line (because each end of the VPN is only dealing with one other
end).</p>

<p>On gateway host #1 this line should look like this:</p>

<pre class="PROGRAMLISTING">
W.X.Y.Z            secret
</pre>

<p>That is, the <span class="emphasis"><i class="EMPHASIS">public</i></span> IP address
of the remote end, whitespace, and a text string that provides the secret. Obviously, you
shouldn't use ``secret'' as your key -- the normal rules for choosing a password
apply.</p>

<p>On gateway host #2 the line would look like this</p>

<pre class="PROGRAMLISTING">
A.B.C.D            secret
</pre>