当前位置: 首页 > 工具软件 > IPsec Tools > 使用案例 >

3. ipsec-tools on ubuntu14.04

朱兴运
2023-12-01
3. ipsec-tools on ubuntu14.04

Automatic keyed connections using racoon

The KAME IKE daemon racoon has also been ported to Linux. This daemon is able to setup automatically keyed IPsec connections. Racoon supports the authentication using preshared keys, X.509 certificates and Kerberos. The daemon can use main mode, aggressive mode and base mode in phase one of IKE. This chapter will show the configuration of racoon in main mode using preshared keys and X.509 certificates (ToDo: Kerberos). At the end the configuration of a roadwarrior scenario will be briefly explained.

Remember: If you are using the Linux kernel 2.6.10 (or a heavily patched 2.6.9 by your distribution) you need the ipsec-tools 0.5.
Preshared Keys

The easiest way to authenticate using racoon is the usage of preshared keys. These keys have to be defined in a file /etc/psk.txt. This file should not be read by unprivileged users (chmod 400 /etc/psk.txt) and has the following syntax:

# IPv4 Adressen
192.168.2.100          simple psk
5.0.0.1                0xe10bd52b0529b54aac97db63462850f3
# USER_FQDN
ralf@spenneberg.net    This is a psk for an email address
# FQDN
www.spenneberg.net     This is a psk
    

This file is organized in columns. The first column holds the identity of the peer authenticated by the psk. Everything starting in the second column is the PSK.

The configuration of racoon is straightforward. The following listing shows a typical /etc/racoon.conf configuration file:

path pre_shared_key "/etc/psk.txt";

remote 192.168.2.100 {
        exchange_mode main;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm md5;
                authentication_method pre_shared_key;
                dh_group modp1024;
        }
}

sainfo address 172.16.1.0/24 any address 172.16.2.0/24 any {
        pfs_group modp768;
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5;
        compression_algorithm deflate;
}
    

This configuration file first defines where racoon may find the preshared keys. It then defines a peer 192.168.2.100 and the parameters to use for the phase one of the IKE negotiation. The second paragraph specifies the parameters which may be used for the setup of the security associations. This definition may be specific for defined IP addresses or general using anonymous instead of the IP addresses. Here the encryption, authentication and compression algorithms to use for the SA are defined. All three need to be defined to avoid an error during the startup of racoon.

The IKE daemon racoon does not start the tunnel negotiation immediately when started. Rather racoon waits until the tunnel is needed. For this notification to occur the kernel needs to know when to notify racoon. To achieve this, the administrator needs to define security policies without the appropiate security associations. Whenever the Linux kernel needs to protect a packet according to the security policies and when no security association is available, the Linux kernel calls racoon and asks for the required security associations. Racoon will then start the IKE negotiations and will create the SAs when finished. The Linux kernel can then send the packets.

For the assumed setup the following policies are needed on 192.168.1.100:

#!/usr/sbin/setkey -f
#
# Flush SAD and SPD
flush;
spdflush;

# Create policies for racoon
spdadd 172.16.1.0/24 172.16.2.0/24 any -P out ipsec
           esp/tunnel/192.168.1.100-192.168.2.100/require;

spdadd 172.16.2.0/24 172.16.1.0/24 any -P in ipsec
           esp/tunnel/192.168.2.100-192.168.1.100/require;
    

Once the policies are loaded using setkey -f /etc/setkey.conf racoon may be started. For testing purposes racoon should be started using racoon -F -f /etc/racoon.conf. Again the configuration of the other peer has to be modified to reflect the different direction. The IP addresses in the files /etc/psk.txt, /etc/setkey.conf and /etc/racoon.conf must be exchanged.

The initiation of the tunnel can then be followed in the logs:

2003-02-21 18:11:17: INFO: main.c:170:main(): @(#)racoon 20001216 20001216
 sakane@kame.net
2003-02-21 18:11:17: INFO: main.c:171:main(): @(#)This product linked Open
SSL 0.9.6b [engine] 9 Jul 2001 (http://www.openssl.org/)
2003-02-21 18:11:17: INFO: isakmp.c:1365:isakmp_open(): 127.0.0.1[500] use
d as isakmp port (fd=7)
2003-02-21 18:11:17: INFO: isakmp.c:1365:isakmp_open(): 192.168.1.100[500]
 used as isakmp port (fd=9)
2003-02-21 18:11:37: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA r
equest for 192.168.2.100 queued due to no phase1 found.
2003-02-21 18:11:37: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new
phase 1 negotiation: 192.168.1.100[500]<=>192.168.2.100[500]
2003-02-21 18:11:37: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Identit
y Protection mode.
2003-02-21 18:11:37: INFO: vendorid.c:128:check_vendorid(): received Vendor
 ID: KAME/racoon
2003-02-21 18:11:37: INFO: vendorid.c:128:check_vendorid(): received Vendor
 ID: KAME/racoon
2003-02-21 18:11:38: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA es
tablished 192.168.1.100[500]-192.168.2.100[500] spi:6a01ea039be7bac2:bd288f
f60eed54d0
2003-02-21 18:11:39: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new p
hase 2 negotiation: 192.168.1.100[0]<=>192.168.2.100[0]
2003-02-21 18:11:39: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA establish
ed: ESP/Tunnel 192.168.2.100->192.168.1.100 spi=68291959(0x4120d77)
2003-02-21 18:11:39: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established:
 ESP/Tunnel 192.168.1.100->192.168.2.100 spi=223693870(0xd554c2e)
   
 类似资料: