“UbuntuHelp:IPSecHowTo”的版本间的差异
来自Ubuntu中文
小 |
小 |
||
| （未显示2个用户的6个中间版本） | |||
| 第1行： | 第1行： | ||
{{From|https://help.ubuntu.com/community/IPSecHowTo}} | {{From|https://help.ubuntu.com/community/IPSecHowTo}} | ||
{{Languages|UbuntuHelp:IPSecHowTo}} | {{Languages|UbuntuHelp:IPSecHowTo}} | ||
| − | [mailto:[email protected] Matthew Caron] | + | <<Include(Tag/StyleCleanup)>> |
| − | + | [[UbuntuHelp:mailto:[email protected]|Matthew Caron]] | |
This howto is primarily taken from [http://www.ipsec-howto.org/x299.html IPSec - Linux Kernel 2.6 using KAME-tools]; the native IPSec stack in the 2.6 kernel series. | This howto is primarily taken from [http://www.ipsec-howto.org/x299.html IPSec - Linux Kernel 2.6 using KAME-tools]; the native IPSec stack in the 2.6 kernel series. | ||
| − | |||
This covers using manually-keyed connections, and is geared toward very small or primarily star toplogy networks (an NIS server and all it's clients, for example). Larger networks (if all the NIS clients want to talk to each other in an encrypted fashion) would benefit from the use of an automated keying agent, such as <code><nowiki>racoon</nowiki></code>. Discussion of such agents is outside the scope of this draft of this document (maybe later). | This covers using manually-keyed connections, and is geared toward very small or primarily star toplogy networks (an NIS server and all it's clients, for example). Larger networks (if all the NIS clients want to talk to each other in an encrypted fashion) would benefit from the use of an automated keying agent, such as <code><nowiki>racoon</nowiki></code>. Discussion of such agents is outside the scope of this draft of this document (maybe later). | ||
| + | 1. Install the tools: | ||
| − | |||
<pre><nowiki> | <pre><nowiki> | ||
sudo apt-get install ipsec-tools | sudo apt-get install ipsec-tools | ||
</nowiki></pre> | </nowiki></pre> | ||
| + | 2. Edit /etc/ipsec-tools.conf file. This file should be of the general form: | ||
| − | |||
<pre><nowiki> | <pre><nowiki> | ||
| + | #!/usr/sbin/setkey -f | ||
| + | # Configuration for 192.168.1.100 | ||
| + | # Flush the SAD and SPD | ||
flush; | flush; | ||
spdflush; | spdflush; | ||
| + | # Attention: Use this keys only for testing purposes! | ||
| + | # Generate your own keys! | ||
| + | # AH SAs using 128 bit long keys | ||
add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5 | add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5 | ||
0xc0291ff014dccdd03874d9e8e4cdf3e6; | 0xc0291ff014dccdd03874d9e8e4cdf3e6; | ||
| 第25行： | 第30行： | ||
0x96358c90783bbfa3d7b196ceabe0536b; | 0x96358c90783bbfa3d7b196ceabe0536b; | ||
| + | # ESP SAs using 192 bit long keys (168 + 24 parity) | ||
add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc | add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc | ||
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831; | 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831; | ||
| 第30行： | 第36行： | ||
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df; | 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df; | ||
| + | # Security policies | ||
spdadd 192.168.1.100 192.168.2.100 any -P out ipsec | spdadd 192.168.1.100 192.168.2.100 any -P out ipsec | ||
esp/transport//require | esp/transport//require | ||
| 第40行： | 第47行： | ||
It is important to understand this, so let me break it down: | It is important to understand this, so let me break it down: | ||
<pre><nowiki> | <pre><nowiki> | ||
| + | # AH SAs using 128 bit long keys | ||
add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5 | add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5 | ||
0xc0291ff014dccdd03874d9e8e4cdf3e6; | 0xc0291ff014dccdd03874d9e8e4cdf3e6; | ||
| 第46行： | 第54行： | ||
</nowiki></pre> | </nowiki></pre> | ||
This section lists the 128 bit keys for the 192.168.2.100 and 192.168.1.100 connection. Each IP pair has 2 keys - one for each direction (in and out). Each pair of machines needs to know the this information. So, this means that, for each pair of IP's, you need to generate a new key (hence why this works for small networks, but anything major probably wants a daemon to handle this. Maybe if I feel ambitious, I'll set mine up to use it and update this with that info). | This section lists the 128 bit keys for the 192.168.2.100 and 192.168.1.100 connection. Each IP pair has 2 keys - one for each direction (in and out). Each pair of machines needs to know the this information. So, this means that, for each pair of IP's, you need to generate a new key (hence why this works for small networks, but anything major probably wants a daemon to handle this. Maybe if I feel ambitious, I'll set mine up to use it and update this with that info). | ||
| − | |||
Also, note the number right after the 'ah' for each of these keys. This number needs to be unique for each 'add' statement. These keys are generated as follows: | Also, note the number right after the 'ah' for each of these keys. This number needs to be unique for each 'add' statement. These keys are generated as follows: | ||
<pre><nowiki> | <pre><nowiki> | ||
| 第52行： | 第59行： | ||
</nowiki></pre> | </nowiki></pre> | ||
Don't forget to add the 0x in front of it. | Don't forget to add the 0x in front of it. | ||
| − | |||
Similarly, this section: | Similarly, this section: | ||
<pre><nowiki> | <pre><nowiki> | ||
| + | # ESP SAs using 192 bit long keys (168 + 24 parity) | ||
add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc | add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc | ||
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831; | 0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831; | ||
| 第65行： | 第72行： | ||
</nowiki></pre> | </nowiki></pre> | ||
Again, don't forget to add the 0x in front of it. | Again, don't forget to add the 0x in front of it. | ||
| − | |||
So, these top two sections should list keys for all the IP addresses that the machine cares about. These sections do not change when moving the file amongst machines on either side of a connection. That brings us to the next section: | So, these top two sections should list keys for all the IP addresses that the machine cares about. These sections do not change when moving the file amongst machines on either side of a connection. That brings us to the next section: | ||
<pre><nowiki> | <pre><nowiki> | ||
| + | # Security policies | ||
spdadd 192.168.1.100 192.168.2.100 any -P out ipsec | spdadd 192.168.1.100 192.168.2.100 any -P out ipsec | ||
esp/transport//require | esp/transport//require | ||
| 第78行： | 第85行： | ||
This sets up the policies for in and out communications. So, the above version will work for 192.168.1.100, because all '''outgoing''' communication to 192.168.2.100 and all '''incoming''' communication from 192.168.2.100 will be encrypted. To use this on the other machine (192.168.2.100), flip the in and out directives, as follows: | This sets up the policies for in and out communications. So, the above version will work for 192.168.1.100, because all '''outgoing''' communication to 192.168.2.100 and all '''incoming''' communication from 192.168.2.100 will be encrypted. To use this on the other machine (192.168.2.100), flip the in and out directives, as follows: | ||
<pre><nowiki> | <pre><nowiki> | ||
| + | # Security policies | ||
spdadd 192.168.1.100 192.168.2.100 any -P in ipsec | spdadd 192.168.1.100 192.168.2.100 any -P in ipsec | ||
esp/transport//require | esp/transport//require | ||
| 第86行： | 第94行： | ||
ah/transport//require; | ah/transport//require; | ||
</nowiki></pre> | </nowiki></pre> | ||
| + | 3. Make the conf file not readable to the world: | ||
| − | |||
<pre><nowiki> | <pre><nowiki> | ||
sudo chmod 750 ipsec-tools.conf | sudo chmod 750 ipsec-tools.conf | ||
</nowiki></pre> | </nowiki></pre> | ||
| − | |||
Okay, do both sides of the connection have an ipsec-tools.conf? Everyone set? Good, now it gets easy. | Okay, do both sides of the connection have an ipsec-tools.conf? Everyone set? Good, now it gets easy. | ||
| − | |||
4. It will be started at boot by default on systems, so you don't have to worry about that. | 4. It will be started at boot by default on systems, so you don't have to worry about that. | ||
| + | 5. Also, starting it wouldn't hurt either (make sure to do this on both sides of the connection before trying to have them talk to each other; you could also reboot): | ||
| − | |||
<pre><nowiki> | <pre><nowiki> | ||
sudo /etc/init.d/setkey start | sudo /etc/init.d/setkey start | ||
</nowiki></pre> | </nowiki></pre> | ||
| − | + | ---- | |
| − | [[category: | + | [[category:CategoryNetworking]] |
[[category:UbuntuHelp]] | [[category:UbuntuHelp]] | ||
2010年5月19日 (三) 22:58的最新版本
 |
点击翻译: |
English |
请不要直接编辑翻译本页，本页将定期与来源同步。 |
<<Include(Tag/StyleCleanup)>>
Matthew Caron
This howto is primarily taken from IPSec - Linux Kernel 2.6 using KAME-tools; the native IPSec stack in the 2.6 kernel series.
This covers using manually-keyed connections, and is geared toward very small or primarily star toplogy networks (an NIS server and all it's clients, for example). Larger networks (if all the NIS clients want to talk to each other in an encrypted fashion) would benefit from the use of an automated keying agent, such as racoon. Discussion of such agents is outside the scope of this draft of this document (maybe later).
1. Install the tools:
sudo apt-get install ipsec-tools
2. Edit /etc/ipsec-tools.conf file. This file should be of the general form:
#!/usr/sbin/setkey -f
# Configuration for 192.168.1.100
# Flush the SAD and SPD
flush;
spdflush;
# Attention: Use this keys only for testing purposes!
# Generate your own keys!
# AH SAs using 128 bit long keys
add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5
0xc0291ff014dccdd03874d9e8e4cdf3e6;
add 192.168.2.100 192.168.1.100 ah 0x300 -A hmac-md5
0x96358c90783bbfa3d7b196ceabe0536b;
# ESP SAs using 192 bit long keys (168 + 24 parity)
add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
add 192.168.2.100 192.168.1.100 esp 0x301 -E 3des-cbc
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;
# Security policies
spdadd 192.168.1.100 192.168.2.100 any -P out ipsec
esp/transport//require
ah/transport//require;
spdadd 192.168.2.100 192.168.1.100 any -P in ipsec
esp/transport//require
ah/transport//require;
It is important to understand this, so let me break it down:
# AH SAs using 128 bit long keys
add 192.168.1.100 192.168.2.100 ah 0x200 -A hmac-md5
0xc0291ff014dccdd03874d9e8e4cdf3e6;
add 192.168.2.100 192.168.1.100 ah 0x300 -A hmac-md5
0x96358c90783bbfa3d7b196ceabe0536b;
This section lists the 128 bit keys for the 192.168.2.100 and 192.168.1.100 connection. Each IP pair has 2 keys - one for each direction (in and out). Each pair of machines needs to know the this information. So, this means that, for each pair of IP's, you need to generate a new key (hence why this works for small networks, but anything major probably wants a daemon to handle this. Maybe if I feel ambitious, I'll set mine up to use it and update this with that info). Also, note the number right after the 'ah' for each of these keys. This number needs to be unique for each 'add' statement. These keys are generated as follows:
dd if=/dev/random count=16 bs=1| xxd -ps
Don't forget to add the 0x in front of it. Similarly, this section:
# ESP SAs using 192 bit long keys (168 + 24 parity)
add 192.168.1.100 192.168.2.100 esp 0x201 -E 3des-cbc
0x7aeaca3f87d060a12f4a4487d5a5c3355920fae69a96c831;
add 192.168.2.100 192.168.1.100 esp 0x301 -E 3des-cbc
0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df;
This works just like the AH keys, except that they are longer. Again, the number after 'esp' must be unique. These keys are generated as follows:
dd if=/dev/random count=24 bs=1| xxd -ps
Again, don't forget to add the 0x in front of it. So, these top two sections should list keys for all the IP addresses that the machine cares about. These sections do not change when moving the file amongst machines on either side of a connection. That brings us to the next section:
# Security policies
spdadd 192.168.1.100 192.168.2.100 any -P out ipsec
esp/transport//require
ah/transport//require;
spdadd 192.168.2.100 192.168.1.100 any -P in ipsec
esp/transport//require
ah/transport//require;
This sets up the policies for in and out communications. So, the above version will work for 192.168.1.100, because all outgoing communication to 192.168.2.100 and all incoming communication from 192.168.2.100 will be encrypted. To use this on the other machine (192.168.2.100), flip the in and out directives, as follows:
# Security policies
spdadd 192.168.1.100 192.168.2.100 any -P in ipsec
esp/transport//require
ah/transport//require;
spdadd 192.168.2.100 192.168.1.100 any -P out ipsec
esp/transport//require
ah/transport//require;
3. Make the conf file not readable to the world:
sudo chmod 750 ipsec-tools.conf
Okay, do both sides of the connection have an ipsec-tools.conf? Everyone set? Good, now it gets easy. 4. It will be started at boot by default on systems, so you don't have to worry about that. 5. Also, starting it wouldn't hurt either (make sure to do this on both sides of the connection before trying to have them talk to each other; you could also reboot):
sudo /etc/init.d/setkey start
