ipsec.html

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

<p>That is, the public IP address of the remote end, and the same secret key. <tt
class="FILENAME">psk.txt</tt> must be mode <var class="LITERAL">0600</var> (i.e., only
read/write to <tt class="USERNAME">root</tt>) before racoon will run.</p>

<p>You must run racoon on both gateway machines. You will also need to add some firewall
rules to allow the IKE traffic, which is carried over UDP to the ISAKMP (Internet
Security Association Key Management Protocol) port. Again, this should be fairly early in
your firewall ruleset.</p>

<pre class="PROGRAMLISTING">
ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
      
</pre>

<p>Once racoon is running you can try pinging one gateway host from the other. The
connection is still not encrypted, but racoon will then set up the security associations
between the two hosts -- this might take a moment, and you may see this as a short delay
before the ping commands start responding.</p>

<p>Once the security association has been set up you can view it using <span
class="CITEREFENTRY"><span class="REFENTRYTITLE">setkey</span>(8)</span>. Run</p>

<pre class="PROGRAMLISTING">
setkey -D
</pre>

<p>on either host to view the security association information.</p>

<p>That's one half of the problem. They other half is setting your security policies.</p>

<p>To create a sensible security policy, let's review what's been set up so far. This
discussions hold for both ends of the link.</p>

<p>Each IP packet that you send out has a header that contains data about the packet. The
header includes the IP addresses of both the source and destination. As we already know,
private IP addresses, such as the <tt class="HOSTID">192.168.x.y</tt> range are not
supposed to appear on the public Internet. Instead, they must first be encapsulated
inside another packet. This packet must have the public source and destination IP
addresses substituted for the private addresses.</p>

<p>So if your outgoing packet started looking like this:</p>

<p><img src="security/ipsec-out-pkt.png" align="CENTER" /></p>

<p>Then it will be encapsulated inside another packet, looking something like this:</p>

<p><img src="security/ipsec-encap-pkt.png" align="CENTER" /></p>

<p>This encapsulation is carried out by the <tt class="DEVICENAME">gif</tt> device. As
you can see, the packet now has real IP addresses on the outside, and our original packet
has been wrapped up as data inside the packet that will be put out on the Internet.</p>

<p>Obviously, we want all traffic between the VPNs to be encrypted. You might try putting
this in to words, as:</p>

<p>``If a packet leaves from <tt class="HOSTID">A.B.C.D</tt>, and it is destined for <tt
class="HOSTID">W.X.Y.Z</tt>, then encrypt it, using the necessary security
associations.''</p>

<p>``If a packet arrives from <tt class="HOSTID">W.X.Y.Z</tt>, and it is destined for <tt
class="HOSTID">A.B.C.D</tt>, then decrypt it, using the necessary security
associations.''</p>

<p>That's close, but not quite right. If you did this, all traffic to and from <tt
class="HOSTID">W.X.Y.Z</tt>, even traffic that was not part of the VPN, would be
encrypted. That's not quite what you want. The correct policy is as follows</p>

<p>``If a packet leaves from <tt class="HOSTID">A.B.C.D</tt>, and that packet is
encapsulating another packet, and it is destined for <tt class="HOSTID">W.X.Y.Z</tt>,
then encrypt it, using the necessary security associations.''</p>

<p>``If a packet arrives from <tt class="HOSTID">W.X.Y.Z</tt>, and that packet is
encapsulating another packet, and it is destined for <tt class="HOSTID">A.B.C.D</tt>,
then encrypt it, using the necessary security associations.''</p>

<p>A subtle change, but a necessary one.</p>

<p>Security policies are also set using <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">setkey</span>(8)</span>. <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">setkey</span>(8)</span> features a configuration language for
defining the policy. You can either enter configuration instructions via stdin, or you
can use the <var class="OPTION">-f</var> option to specify a filename that contains
configuration instructions.</p>

<p>The configuration on gateway host #1 (which has the public IP address <tt
class="HOSTID">A.B.C.D</tt>) to force all outbound traffic to <tt
class="HOSTID">W.X.Y.Z</tt> to be encrypted is:</p>

<pre class="PROGRAMLISTING">
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;
      
</pre>

<p>Put these commands in a file (e.g., <tt class="FILENAME">/etc/ipsec.conf</tt>) and
then run</p>

<pre class="SCREEN">
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">setkey -f /etc/ipsec.conf</kbd>
</pre>

<p><var class="OPTION">spdadd</var> tells <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">setkey</span>(8)</span> that we want to add a rule to the secure
policy database. The rest of this line specifies which packets will match this policy.
<tt class="HOSTID">A.B.C.D/32</tt> and <tt class="HOSTID">W.X.Y.Z/32</tt> are the IP
addresses and netmasks that identify the network or hosts that this policy will apply to.
In this case, we want it to apply to traffic between these two hosts. <var
class="OPTION">ipencap</var> tells the kernel that this policy should only apply to
packets that encapsulate other packets. <var class="OPTION">-P out</var> says that this
policy applies to outgoing packets, and <var class="OPTION">ipsec</var> says that the
packet will be secured.</p>

<p>The second line specifies how this packet will be encrypted. <var
class="OPTION">esp</var> is the protocol that will be used, while <var
class="OPTION">tunnel</var> indicates that the packet will be further encapsulated in an
IPsec packet. The repeated use of <tt class="HOSTID">A.B.C.D</tt> and <tt
class="HOSTID">W.X.Y.Z</tt> is used to select the security association to use, and the
final <var class="OPTION">require</var> mandates that packets must be encrypted if they
match this rule.</p>

<p>This rule only matches outgoing packets. You will need a similar rule to match
incoming packets.</p>

<pre class="PROGRAMLISTING">
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
</pre>

<p>Note the <var class="OPTION">in</var> instead of <var class="OPTION">out</var> in this
case, and the necessary reversal of the IP addresses.</p>

<p>The other gateway host (which has the public IP address <tt
class="HOSTID">W.X.Y.Z</tt>) will need similar rules.</p>

<pre class="PROGRAMLISTING">
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
       spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;
</pre>

<p>Finally, you need to add firewall rules to allow ESP and IPENCAP packets back and
forth. These rules will need to be added to both hosts.</p>

<pre class="PROGRAMLISTING">
ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
      
</pre>

<p>Because the rules are symmetric you can use the same rules on each gateway host.</p>

<p>Outgoing packets will now look something like this:</p>

<p><img src="security/ipsec-crypt-pkt.png" align="CENTER" /></p>

<p>When they are received by the far end of the VPN they will first be decrypted (using
the security associations that have been negotiated by racoon). Then they will enter the
<tt class="DEVICENAME">gif</tt> interface, which will unwrap the second layer, until you
are left with the innermost packet, which can then travel in to the inner network.</p>

<p>You can check the security using the same <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">ping</span>(8)</span> test from earlier. First, log in to the <tt
class="HOSTID">A.B.C.D</tt> gateway machine, 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>This time you should see output like the following:</p>

<pre class="PROGRAMLISTING">
XXX tcpdump output
</pre>

<p>Now, as you can see, <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">tcpdump</span>(1)</span> shows the ESP packets. If you try to
examine them with the <var class="OPTION">-s</var> option you will see (apparently)
gibberish, because of the encryption.</p>

<p>Congratulations. You have just set up a VPN between two remote sites.</p>

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

<ul>
<li>
<p>Configure both kernels with:</p>

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

<li>
<p>Install <a
href="http://www.FreeBSD.org/cgi/url.cgi?ports/security/racoon/pkg-descr"><tt
class="FILENAME">security/racoon</tt></a>. Edit <tt
class="FILENAME">${PREFIX}/etc/racoon/psk.txt</tt> on both gateway hosts, adding an entry
for the remote host's IP address and a secret key that they both know. Make sure this
file is mode 0600.</p>
</li>

<li>
<p>Add the following lines to <tt class="FILENAME">/etc/rc.conf</tt> on each host:</p>

<pre class="PROGRAMLISTING">
ipsec_enable="YES"
ipsec_file="/etc/ipsec.conf"
         
</pre>
</li>

<li>
<p>Create an <tt class="FILENAME">/etc/ipsec.conf</tt> on each host that contains the
necessary spdadd lines. On gateway host #1 this would be:</p>

<pre class="PROGRAMLISTING">
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec
  esp/tunnel/A.B.C.D-W.X.Y.Z/require;
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec
  esp/tunnel/W.X.Y.Z-A.B.C.D/require;
</pre>

<p>On gateway host #2 this would be:</p>

<pre class="PROGRAMLISTING">
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec
  esp/tunnel/W.X.Y.Z-A.B.C.D/require;
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec
  esp/tunnel/A.B.C.D-W.X.Y.Z/require;
</pre>
</li>

<li>
<p>Add firewall rules to allow IKE, ESP, and IPENCAP traffic to both hosts:</p>

<pre class="PROGRAMLISTING">
ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
         
</pre>
</li>
</ul>

<p>The previous two steps should suffice to get the VPN up and running. Machines on each
network will be able to refer to one another using IP addresses, and all traffic across
the link will be automatically and securely encrypted.</p>
</div>
</div>
</div>

<div class="NAVFOOTER">
<hr align="LEFT" width="100%" />
<table summary="Footer navigation table" width="100%" border="0" cellpadding="0"
cellspacing="0">
<tr>
<td width="33%" align="left" valign="top"><a href="openssl.html"
accesskey="P">Prev</a></td>
<td width="34%" align="center" valign="top"><a href="index.html"
accesskey="H">Home</a></td>
<td width="33%" align="right" valign="top"><a href="openssh.html"
accesskey="N">Next</a></td>
</tr>

<tr>
<td width="33%" align="left" valign="top">OpenSSL</td>
<td width="34%" align="center" valign="top"><a href="security.html"
accesskey="U">Up</a></td>
<td width="33%" align="right" valign="top">OpenSSH</td>
</tr>
</table>
</div>
</body>
</html>