lug-bg: Re: lug-bg: IPsec esp Linux(racoon) - O penBSD(isakpmd) [ДЪЛГО]

2006-10-18 Thread Danail Petrov

Здрасти,
никога не съм конфигурирал IPSec на линукс машини , но ето моето мнение.
Според мен грешката е вярна :)
До колкото разбирам , искаш да изградиш ESP тунел между 2 машини 
посредством ISAKMP/IKE (или както там се казва).
Няколко основни фази , който протичат в изграждането на една ipsec 
свързаност:


1. *организиране на интересен трафик*
2. IKE Фаза 1 (dh key exchange)
3. IKE Фаза 2 (остановяване на така наречените SA за вход/изход)
4. Изграждане на криптиран канал за пренос

или накратко казано , за да работи криптото , трябва да си определил 
интересния трафик който да бъде криптиран. Което ще рече че при теб 
ситуацията е работеща , след като имаш пинг от 192.168.1.1 (който ти 
влиза в интересния трафик) до дестинация 10.0.0.89. Всичко останало 
което НЕ си описал като интересен трафик за криптото , няма да ти се 
криптира , съответно и няма да премине през ЕСП тунела (освен ако не си 
оказал изрично  че искаш трафика който не е интересен да минава през 
тунела БЕЗ да се криптира) Както се вижда по-долу , IKE-то успешно е 
изградило SA's и би трябвало всичко да е наред.


Това е според мен разбира се , има вероятност да не съм разбрал правилно 
въпроса ти и/или да пропускам нещо!



Поздрави,
Данаил Петров




Alexander Iliev wrote:

Добър вечер.

Първо искам да се извиня за дългото писмо.

Сега за проблема - опитвам се да пусна ESP тунел между Fedora Core 4
и OpenBSD 3.9.

Ситуацията е следната - Linux-а е зад SNAT, OpenBSD-то е с публичен
адрес. Адреса на Linux-а от NAT-натата мрежа е 10.0.0.89. От другата
страна също има вътрешна мрежа - 192.168.1/24. Имам малко притеснение,
понеже се опитвам да пусна тунела м/у именно тези две мрежи - 10.0/16
и 192.168.1/24. Притеснението ми е, че от страната на Fedora-та адреса
е част от мрежата, която се опитвам да прекарам през самия тунел. Не
знам дали изобщо се прави така, ако може някой да ме осветли? :)

Проблемът с тунела е, че от машините от 192.168.1/24 няма достъп до
10.0/16 мрежата, с изключение на IPsec gateway-а (OpenBSD-то). Т.е.
при 'ping 10.0.0.89' от произволна машина от 192.168.1/16 няма отговор,
при 'ping -I 192.168.1.1 10.0.0.89' от машината с OpenBSD няма проблем
(192.168.1.1 е адреса на OpenBSD машината от вътрешната мрежа).

От другата страна няма проблем, т.е. ако от 10.0.0.89 пусна пинг до
коя да е машина от 192.168.1/16 си връща отговори.

Конфигурацията е с pre-shared keys, ето подробностите:

 racoon.conf 
path include /etc/racoon;
path pre_shared_key /etc/racoon/psk.txt;

sainfo anonymous
{
pfs_group 2;
lifetime time 1 hour ;
encryption_algorithm 3des, blowfish 448, rijndael ;
authentication_algorithm hmac_sha1, hmac_md5 ;
compression_algorithm deflate ;
}

remote anonymous
{
exchange_mode main;
my_identifier address;
nat_traversal on;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
}
 /racoon.conf 

 setkey.conf 
#! /sbin/setkey -f

flush;
spdflush;

spdadd 192.168.1.0/24 10.0.0.0/16 any -P in ipsec
esp/tunnel/W.Z.Y.Z-10.0.0.89/require;
spdadd 10.0.0.0/16 192.168.1.0/24 any -P out ipsec
esp/tunnel/10.0.0.89-W.X.Y.Z/require;
 /setkey.conf 

 isakmpd.conf 
[General]
Listen-On=  W.X.Y.Z

[Phase 1]
P.Q.R.S=peer-machine

[Phase 2]
Passive-connections=VPN

[peer-machine]
Phase=  1
Transport=  udp
Address=P.Q.R.S
Configuration=  Default-main-mode
Authentication= secret

[VPN]
Phase=  2
ISAKMP-peer=peer-machine
Configuration=  Default-quick-mode
Local-ID=   local-internal-network
Remote-ID=  remote-internal-network

[local-internal-network]
ID-type=IPV4_ADDR_SUBNET
Network=192.168.1.0
Netmask=255.255.255.0

[remote-internal-network]
ID-type=IPV4_ADDR_SUBNET
Network=10.0.0.0
Netmask=255.255.0.0

[Default-main-mode]
DOI=IPSEC
EXCHANGE_TYPE=  ID_PROT
Transforms= 3DES-SHA,BLF-SHA

[Default-quick-mode]
DOI=IPSEC
EXCHANGE_TYPE=  QUICK_MODE
Suites= QM-ESP-3DES-SHA-SUITE
 /isakmpd.conf 

 isakmpd.policy 
Keynote-version: 2
Authorizer: POLICY
Conditions: app_domain == IPsec policy 
esp_present == yes 
esp_enc_alg != null - true;
 /isakmpd.policy 

W.X.Y.Z е публичният адрес на OpenBSD машината,
P.Q.R.S е адресът, с който излиза 10.0.0.89 към интернет.

В допълнение само да кажа, че имам 'no nat' правило за пакетите
от 192.168.1/16, пускам всичко на enc0 и пускам udp/500 и udp/4500
на външния интерфейс на OpenBSD машината.

Много благодаря на всички, които благоволят да прочетат наистина
дългото обяснение. :)

Поздрави,
  


--
Danail Petrov
Network Administrator
Evolink, Sofia
+359(2)9691650
www.evolink.com
icq uin 989677



smime.p7s
Description: S/MIME Cryptographic Signature


lug-bg: Re: lug-bg: IPsec esp Linux(racoon) - O penBSD(isakpmd) [ДЪЛГО]

2006-10-17 Thread Georgi Chorbadzhiyski

Alexander Iliev wrote:

Добър вечер.

Първо искам да се извиня за дългото писмо.

Сега за проблема - опитвам се да пусна ESP тунел между Fedora Core 4
и OpenBSD 3.9.

Ситуацията е следната - Linux-а е зад SNAT, OpenBSD-то е с публичен
адрес. Адреса на Linux-а от NAT-натата мрежа е 10.0.0.89. От другата
страна също има вътрешна мрежа - 192.168.1/24. Имам малко притеснение,
понеже се опитвам да пусна тунела м/у именно тези две мрежи - 10.0/16
и 192.168.1/24. Притеснението ми е, че от страната на Fedora-та адреса
е част от мрежата, която се опитвам да прекарам през самия тунел. Не
знам дали изобщо се прави така, ако може някой да ме осветли? :)

Проблемът с тунела е, че от машините от 192.168.1/24 няма достъп до
10.0/16 мрежата, с изключение на IPsec gateway-а (OpenBSD-то). Т.е.


Без да съм спец по IPSEC ми се струва, че проблема е че нямаш рутиране
на OpenBSD машината за мрежата от другата страна. На OpenBSD -то (или
може би някъде в настройките на racoon-а) укажи да добави рутинг за
10.0/16 през тунела.


при 'ping 10.0.0.89' от произволна машина от 192.168.1/16 няма отговор,
при 'ping -I 192.168.1.1 10.0.0.89' от машината с OpenBSD няма проблем
(192.168.1.1 е адреса на OpenBSD машината от вътрешната мрежа).

От другата страна няма проблем, т.е. ако от 10.0.0.89 пусна пинг до
коя да е машина от 192.168.1/16 си връща отговори.


...

--
Georgi Chorbadzhiyski
http://georgi.unixsol.org/