LINUX.ORG.RU

Проблема с игнорированием SA в IPSec


0

1

Всем привет. Необходимо поднять IPSec туннель между двумя офисами, при следующей конфигурации:

LAN1 (192.168.1.0/24)
|
FreeBSD 8.2 (192.168.1.2) + ipfw NAT over PPTP(X.X.X.X)
|
|
internet
|
|
ZyXEL ZyWALL USG50 (192.168.10.1) + NAT over PPTP (Y.Y.Y.Y)
|
LAN2 (192.168.10.0/24)

Туннель поднимается, трафик между двумя VPN-гейтами с белыми адресами X.X.X.X и Y.Y.Y.Y успешно инкапсулруется, шифруется и в снифере виден как пакеты с ESP-заголовками. Добавил два статических роута на шлюзах в частные сети. Но при попытке пинга с клиентской машины в LAN1 гейта ZyXEL LAN2 вижу в снифере (на фряхе) следующую картину:

19:33:42.506971 IP X.X.X.X > Y.Y.Y.Y : IP 192.168.1.102 > 192.168.10.1: ICMP echo request, id 13941, seq 4, length 64 (ipip-proto-4)

То есть по каким-то причинам пакет, пройдя первый этап инкапсуляции на gif-интерфейсе, далее не икапсулируется при помощи ipsec-tools и идет нешифрованным в обход политик безопасности и установленных SA:

192.168.10.0/24[any] 192.168.1.0/24[any] any
        in ipsec
        esp/tunnel/Y.Y.Y.Y-X.X.X.X/use
        spid=6 seq=1 pid=23533
        refcnt=1
192.168.1.0/24[any] 192.168.10.0/24[any] any
        out ipsec
        esp/tunnel/X.X.X.X-Y.Y.Y.Y/use
        spid=5 seq=0 pid=23533
        refcnt=1

Пожалуйста помогите понять, в чем тут проблема. Одно время думал, что нужно включить NAT-T, но, насколько я понял, он нужен для случая, когда гейт находится за NAT'ом, не имея своего белого адреса, в моем случае как таковой трансляции адреса не происходит, а происходит инкапсуляция, то есть нат тут не участвует. Т.к. SA носят односторонний характер, то можно утверждать, что уже на этапе гейта LAN1 имеем неправильное поведение, поэтому настройки второго гейта можно пока не рассматривать. Насколько я понимаю, трафик от клиентских машин хотя бы в направлении LAN1->LAN2 должен выглядеть следующим образом (т.е. как минимум дважды инкапсулироваться и наверх шифроваться):

21:34:16.486698 IP Y.Y.Y.Y > X.X.X.X: ESP(spi=0x043488c2,seq=0x66), length 116

Выводы команд и конфиги:

[19:00]root@beta:/home/NutipA# cat /usr/local/etc/racoon/setkey.conf
flush;
spdflush;
# To the second office network
spdadd 192.168.1.0/24 192.168.10.0/24 any -P out ipsec esp/tunnel/X.X.X.X-Y.Y.Y.Y/use;
spdadd 192.168.10.0/24 192.168.1.0/24 any -P in ipsec esp/tunnel/Y.Y.Y.Y-X.X.X.X/use;
[19:02]root@beta:/home/NutipA# cat /usr/local/etc/racoon/racoon.conf
path    pre_shared_key  "/usr/local/etc/racoon/psk.txt"; #location of pre-shared key file
log     debug;  #log verbosity setting: set to 'notify' when testing and debugging is complete

padding # options are not to be changed
{
        maximum_length  20;
        randomize       off;
        strict_check    off;
        exclusive_tail  off;
}

timer   # timing options. change as needed
{
        counter         5;
        interval        20 sec;
        persend         1;
#       natt_keepalive  15 sec;
        phase1          30 sec;
        phase2          15 sec;
}

listen  # address [port] that racoon will listening on
{
        isakmp          X.X.X.X [500];
        isakmp_natt     X.X.X.X [4500];
}

remote  Y.Y.Y.Y [500]
{
        exchange_mode   main,aggressive;
        doi             ipsec_doi;
        situation       identity_only;
        my_identifier   address X.X.X.X;
        peers_identifier        address Y.Y.Y.Y;
        lifetime        time 8 hour;
        passive         off;
        proposal_check  obey;
#       nat_traversal   off;
        generate_policy off;

                        proposal {
                                encryption_algorithm    3des;
                                hash_algorithm          md5;
                                authentication_method   pre_shared_key;
                                lifetime time           30 sec;
                                dh_group                1;
                        }
}

sainfo  (address 192.168.1.0/24 any address 192.168.10.0/24 any)    # address $network/$netmask $type address $network/$netmas
{                               # $network must be the two internal networks you are joining.
        pfs_group       1;
        lifetime        time    36000 sec;
        encryption_algorithm    3des,des;
        authentication_algorithm        hmac_md5,hmac_sha1;
        compression_algorithm   deflate;
}
[18:53]root@beta:/home/NutipA# ifconfig
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=2098<VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
        ether 00:17:31:55:a6:07
        inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
<output ommitted>
tun0: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> metric 0 mtu 1400
        options=80000<LINKSTATE>
        inet X.X.X.X --> 81.25.33.1 netmask 0xffffffff 
        Opened by PID 32338
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
        tunnel inet X.X.X.X --> Y.Y.Y.Y
        inet 192.168.1.2 --> 192.168.10.1 netmask 0xffffff00 
        options=1<ACCEPT_REV_ETHIP_VER>
[19:03]root@beta:/home/NutipA# netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            Z.Z.Z.Z         UGS         0    74261   tun0
<output ommitted>
192.168.1.0/24     link#1             U           2  1097106    em0
192.168.1.2        link#1             UHS         0        0    lo0
192.168.10.0/24    192.168.10.1       UGS         0      549   gif0
192.168.10.1       link#8             UH          0     4230   gif0
[18:57]root@beta:/home/NutipA# cat /etc/rc.conf 
zfs_enable="YES"
hostname="beta"
ifconfig_em0="inet 192.168.1.2 netmask 255.255.255.0 -rxcsum -txcsum -tso"
sshd_enable="YES"
ifconfig_vr0="DHCP"
gateway_enable="YES"
firewall_enable="YES"
firewall_nat_enable="YES"
dummynet_enable="YES"
firewall_type="/etc/firewall"

P.S. Да, я в курсе, что FreeBSD это не Linux, но пакет ipsec-tools, который используется для создания IPSec-туннелей в обоих ОС и добрая слава этого форума, позволили мне спросить тут совета:)


попробуй вместо use в setkey spdadd использоваться require зачем кстати gif? только на этой неделе подымал между freebsd 8.2 и zywall 2 plus тунель. намучался вдоволь =)

hints(правда к твоему вопросу не относится): sysctl net.key.preferred_oldsa=0 racoon.conf: dpd_delay=N; (по усмотрению, но не 0) rekey on;

иначе при переподключении можно наблюдать неприятные косяки, типа множества ключей в setkey -D (дубли) и ошибки в логах типа «пришел пакет неясно для какого тунеля»

fr_butch ()
Ответ на: комментарий от fr_butch

я пробовал с require не помогает, кстати спасибо за твои комментарии, дубли иногда бывали на другой конфигурации, теперь я знаю как их побороть:)

Гиф собственно говоря обеспечивает инкапсуляцию трафика, об этом хорошо написано в хендбуке русском (статья хоть и устарела, но все-таки некоторые части ее все еще актуальны) http://www.freebsd.org/doc/ru/books/handbook/ipsec.html Плюс при поднятии гиф интерфейса сразу же роуты прописываются, что очень удобно, да и вообще для дебага хорошая вещь.

NutipA ()
Ответ на: комментарий от NutipA

>Гиф собственно говоря обеспечивает инкапсуляцию трафика, об этом хорошо написано в хендбуке русском
на самом деле это частный случай. ты можешь ipsec c l2tp использовать и говорить тоже самое. а можно обойтись и без первого и без второго.
можно взглянуть на картинку:
http://www.ipsec-howto.org/images/tunnel_transport.png
In tunnel mode the IP datagram is fully encapsulated by a new IP datagram using the IPsec protocol. In transport mode only the payload of the IP datagram is handled by the IPsec protocol inserting the IPsec header between the IP header and the upper-layer protocol header

насчет документации. читали бы лучше en, хоть там все так же описан пресловутый gif, есть разница в kernel options ;)
http://www.freebsd.org/doc/en/books/handbook/ipsec.html

fr_butch ()
Ответ на: комментарий от fr_butch

Мы с вами говорим об одном и том же, мне больше нравится вот эта картинка http://www.freebsd.org/doc/ru/books/handbook/security/ipsec-crypt-pkt.png Я настраивал ipsec-туннель на виртуалках, так вот там туннель поднимается, но без гифа пакеты не ходят. Не вдавался в подробности, как там в этом случае выглядит трафик в снифере, но по-моему гиф совершенно логичная и необходимая вещь в туннельном режиме. Ipsec шифрует, а гиф инкапсулирует заголовок. С большим интересом послушаю, как обойтись без него. В IPsec HOWTO (http://www.ipsec-howto.org) написано про опцию -m tunnel. Ты не ее имеешь в виду?

Что же касается en версии хендбука, то по ней все и настраивалось, русская, как ты верно подметил, не первой свежести...

NutipA ()
Ответ на: комментарий от NutipA

> Ipsec шифрует, а гиф инкапсулирует заголовок
для трафика ipsec может использовать Authentication Header (AH) - данные в пакете не шифруются при этом, транспортный, и Encapsulating Security Payload (ESP) - весь пакет шифруется целиком, тунельный.
но вы ж знаете это итак. так вот. согласно spd трафик обернется в esp и пойдет до 500\4500 порта удаленного шлюза. зачем еще что то? разве что для эдвансед роутинга.
подымал так тунели между freebsd\linux и freebsd\какая то железка. и впринципе именно так оно обычно работает. а gif - частный случай, зачем то используемый в handbook. если так удобно - я не против. но не со всеми другими устройствами или ОС gif подымешь =)

fr_butch ()
Ответ на: комментарий от fr_butch

как указано в русском хендбуке процесс будет примерно следующим:

1) есть пакет с внутренними адресами 2) при помощи гифа будет инкапсулирован в пакет с внешними адресами (собственно говоря это и есть туннель) 3) при помощи spd зашифруем пакет который получен на стадии 2 и добавим к нему тот же заголовок с внешними адресами

Иными словами, насколько я понимаю, если пропущен шаг 2, то получаем не туннельный, а транспортный режим ipsec. Далее цитата из русского хендбука: IPsec может быть использован или для непосредственного шифрования трафика между двумя хостами (транспортный режим); или для построения "виртуальных туннелей" между двумя подсетями, которые могут быть использованы для защиты соединений между двумя корпоративными сетями (туннельный режим). Последний обычно называют виртуальной частной сетью (Virtual Private Network, VPN).

Но это не так уж важно... Ты говоришь, что у тебя все работает именно в туннельном режиме без гифа?

NutipA ()
Ответ на: комментарий от NutipA

> если пропущен шаг 2, то получаем не туннельный, а транспортный режим ipsec.
почему вы такой вывод делаете?
как я скажу через spd и в настройках, так и будет(тунель или транспорт).
тунельный gif - лишь частный случай. я еще раз намекну, что есть другие ОС и разные железки, которые знать не знают про gif. но при этом отлично подключаются без него в тунельном режиме.
тот же zywall не в курсе «этих ваших gif». покрайней мере zywall 2 plus, с которым я сталкивался.

fr_butch ()
Ответ на: комментарий от fr_butch

Поставил вместо zywall тазик со второй фряхой, которая настроена аналогично первой. Результат также аналогичный: два конца туннеля спокойно видят друг друга, шифруют трафик между собой, но вот если я пытаюсь пинговать второй офис с клиентской машины в первом, то в снифере вижу нешифрованные icmp-пакеты. Вообще уже даже не знаю что думать.

NutipA ()
Ответ на: комментарий от NutipA

удостоверься что на обоих концах тунелей у тебя правильные spd (соответвуют локальной и удаленной сетям)

setkey -DP

конфиг мало чем отличается от дефолтных примеров

path pre_shared_key "/etc/racoon/psk.txt";

listen {
       isakmp х.х.х.х [500];
       isakmp_natt х.х.х.х [4500];
       adminsock disabled;
}

remote anonymous {
        exchange_mode aggressive,main;
        peers_identifier user_fqdn "some@shit.domain";
        dpd_delay 20;
        ike_frag on;
        nat_traversal on;
        initial_contact off;

        proposal {
                encryption_algorithm aes;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group modp2048;
        }
        generate_policy on;
        passive on;
}
 
sainfo address 10.33.33.1[any] any address 192.168.22.0/24[any] any 
{
        encryption_algorithm des,3des,aes;
        authentication_algorithm hmac_md5,hmac_sha1;
        compression_algorithm deflate;
}

sainfo anonymous 
{
        encryption_algorithm des,3des,aes;
        authentication_algorithm hmac_md5,hmac_sha1;
        compression_algorithm deflate;
}

sainfo anonymous address 192.168.22.0/24[any] any 
{
        encryption_algorithm des,3des,aes;
        authentication_algorithm hmac_md5,hmac_sha1;
        compression_algorithm deflate;
}


с мобильником кажется последний раз игрался. может быть даже с l2tp. у меня отличается только [any] - необязательное указание порта sainfo, включенным dpd и автоматической генерацией правил.

кстати, как ты отслеживаешь трафик, всмысле то что он нешифрованый ходит?
tcpdump -n -i <ифейс_смотрящий_в_инет> port 500 or port 4500 or icmp
тоесть отслеживай сразу трафик на 500\4500 (esp) и тот трафик что идет из сети в сеть (например пинг)

fr_butch ()
Ответ на: комментарий от fr_butch

Всю ночь провел за экспериментами, попробовал на фряхах без gif с обоих концов и на дебианах с обоих концов. И понял, что хоть на шаг, но все-таки стал ближе к решению проблемы, т.к. осознал, еще один момент, который раньше от меня ускользал. Скорее всего корень мой проблемы в маршрутизации. Меня чем в свое время прельстил gif, так это тем, что он при создании интерфейса, прописывает кой-какие роуты сразу и вообще предостовляет более менее прозрачную схему маршрутизации, например для LAN1 после поднятия гифа появлялся маршрут:

192.168.10.1       link#8             UH          0     4230   gif0
и мне оставалось, следуя хендбуку, прописать нечто вроде:
route add 192.168.10.0.24 192.168.10.1

Но когда дело дошло до поднятия туннеля без гифа, я понял, что никак не могу сообразить, как же мне прописать эти роуты без отдельного интерфейса. Как ни пытался на фряхах, оба шлюза даже не начинали переговоры, т.к. не видели друг друга. Я основывался на вот этой статье http://www.opennet.ru/base/cisco/ipsec_linux_cisco.txt.html, когда писал маршруты. Вроде бы там предлагалась довольно логичная схема, но она почему-то не работает. Я пробовал так с обоих концов:

route add -host Y.Y.Y.Y dev ppp0
ip route add 192.168.10.0/24 via Y.Y.Y.Y

Также было и на линухе, до тех пор пока я не заглянул в Debian Wiki http://wiki.debian.org/IPsec. Я прописал такие маршруты с обоих концов:

ip route add to 192.168.10.0/24 via 192.168.1.2 src 192.168.1.2
ip route add to 192.168.1.0/24 via 192.168.10.1 src 192.168.10.1
И сразу же SA установились. Однако пинг все равно не идет...

Уважаемый, fr_butch, ты и так меня уже сильно выручил своими комментариями. Так не сможешь ли мне объяснить, что все таки не так с роутингом или хотя бы привести свои роуты для анализа?

P.S. что касается снифера, то я делаю почти как ты сказал

tcpdump -ni ppp0 port 500 or esp or icmp
просто 500 порт это не сами esp, это только диалог IKE.

NutipA ()
Ответ на: комментарий от NutipA

я кстати тоже помню что добавлял маршрут до удаленной сети через ифейс, смотрящий в инет (типа доступно напрямую):

ip ro add <network_on_other_side> dev <inet_iface>

но после экспериментов завелось и без маршрутов

fr_butch ()
Ответ на: комментарий от NutipA

После очередной порции экспериментов удалось-таки поднять туннель на двух линухах, аналогичный конфиг на фряхе не работает хоть ты тресни. Симптомы все те же: в логе ракуна видно, что SA установлены, все вроде бы есть, но трафик идет на дефолт гейтвей, а не обрабатывается при помощи ipsec. Видел похожую проблему на каком-то форуме, там причина была в том, что правила ната выполнялись быстрее чем правила ipsec. Однако у меня нет ната и фаер по-тестовому чист. Отсюда вопрос, где подробно почитать о порядке обработки трафика и как вообще можно влиять на этот порядок?

Что касается роутинга, то он как таковой действительно не требуется, поскольку инкапсуляция делает все за нас. Но есть один нюанс, трафик с приватного адреса одного гейта на приватный адрес любого клиента в удаленной сети отправляется с src ip = внешнему адресу (от провайдера), из-за чего трафик идет в обход ipsec SPD и соответсвенно дропается провом, т.к. dst ip из частной сети не мершрутизируется. Все попытки это обминуть при помощи iproute2 закончились ничем. Таким образом, сейчас туннель полностью рабочий (только на линухе!) и шлюзы не могут видеть друг никого по приватным адресам (клиенты сетей видят и приватные адреса шлюзов и клиентов за ними).

NutipA ()
Ответ на: комментарий от NutipA

>шлюзы не могут видеть друг никого по приватным адресам

исходящий адрес указывайте, например ping -S 192.168.0.1 10.0.0.2

anonymous ()
Ответ на: комментарий от anonymous

Все это конечно так, в пинге можно указать адрес src ip, но как быть с другими протоколами?

NutipA ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.