IPSec теория и практика

Обсуждаем сайт и форум.

Модератор: f0s

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-08 10:43:52

Статья-не статья, хрен знает. Решайте сами. Новичкам должно помочь.

Немного предисловия. Началось с того, что pptp перестал устраивать, т.к. многие провайдеры не очень, мягко говоря, дружат с gre. Поэтому рещено было перейти на l2tp. Решение оправдало себя, скажу я вам. Если по- быстрому, то меняем все pptp на l2tp в mpd и все работает. Как клиент,так и сервер. Статей по настройке mpd куча, дублировать не вижу смысла. Тут вопрос возник с вендой. В ХР впн только двух вариантов - pptp и l2tp/IPSec. На скорую руку решается созданием ключа

Код: Выделить всё

ProhibitIpSec в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\ типа DWORD со значением "1".
Это просто отключает IPSec на венде и она работает как обычный l2tp клиент. Но раз есть IPSec, надо юзать.

Итак, IPSec. Долго думал, какая же все-таки связь между IPSec и l2tp. Искал строчки с названием первого в конфигах второго и наоборот. Раз позиционируется как одно, значит, связь должна же быть. Ответ оказался прост. Связь примерно такая же, как у стола с табуреткой. Вроде, и можно использовать вместе, но обе совершенно независимые вещи, не имеющие никакой реальной связи между собой. Может быть l2tp/IPSec, может быть smtp/IPSec, telnet/IPSec и, даже, окошмар, icmp/IPSec. На кой хрен в венде это как одно нераздельное - непонятно.
Вообще IPSec вещь универсальная. Если в кратце, то ядро берет пакеты соответствующие определенным правилам и шифрует их перед отправкой в сеть. А другая сторона, получив эти пакеты, расшифровывает и отдает приложению так, как будто они пришли по сети нешифрованными. Физически это можно представить, как если бы из вашего сервера сетевой шнурок шел в черную коробочку, а из нее уже в свич. И у соседа так же. Ваша черная коробочка шифрует пакеты, исходящие от вас и расшифровывает пакеты, приходящие от соседа, которые в свою очередь шифрованы его коробочкой. Коробочки аутентифицируются, обмениваются ключами, параметрами шифрования и т.п. сами, а вы с соседом видите друг друга, как если бы были просто в одном свиче (ну, или просто оба воткнуты в интернет). Дак вот, эти коробочки и есть IPSec. Какой-то трафик пропускается так, какой-то шифруется. Что и как - вы устанавливаете сами. Отсюда и нет никакой прямой связи с тунелями или еще чем-либо. Для приложений работа IPSec прозрачна. В самом простом исполнении тунелей с IPSec создается простой нешифрованный тунель с помощью gif интерфейсов и в правилах IPSec-у указывается, что трафик этого тунеля (или просто - весь трафик между машинами,создающими тунель) надо шифровать.
Я для работы с ipsec использовал ipsec-tools. Еще немного теории.
У IPSec есть 2 режима работы - тунель и транспорт.
В режиме тунеля шифруется пакет целиком, включая заголовки. Т.е. создается виртуальный тунель. В конечном итоге невозможно понять, откуда и куда идет инкапсулированный пакет. Но тут возникает проблема, если клиент находится за натом. Т.к. нат меняет заголовки пакета, то все перестает работать. Решение - NAT-T. На семерку есть патч, на восьмерке.1 нужно просто собрать с ним ядро. При этом не забудьте собрать с поддержкой порт.
В режиме транспорта шифруется только часть с данными и проблем с натом быть не должно.Я использую транспорт.
Раз уж про ядро, то в ядро добавляем

Код: Выделить всё

options         IPSEC              # непосредственно поддержка.
options         IPSEC_ESP       # Encapsulating Security Payload — инкапсуляция зашифрованных данных. 
options         IPSEC_DEBUG	# дебаг. кому надо - кому нет.
device         crypto              # по желанию.
Это касаемо шестерки. В восьмерке появляется IPSEC_NAT_T и исчезает IPSEC_ESP
Собрали-пересобрали-поставили. Конфиг сервера. Впринципе, его же можно и на клиента.
racoon/racoon.conf

Код: Выделить всё

path pre_shared_key "/usr/local/etc/racoon/psk.txt";                                                                
#path pidfile "/var/run/racoon/racoon.pid";                                                                                                                                                  
#path certificate "/etc/ssl/certs";                                                                                                                                                          
#path script "/etc/ssl/certs";                                                                                                                                                               

log info;

# Не останавливаетсяю
#privsep {           
#       user 2000;   
#       group 2000;  
#}                   

# Задает параметры формирования пакетов
# Лучше не трогать. man(c)                   
padding {                              
        maximum_length 20;             
        randomize off;                 
        strict_check off;              
        exclusive_tail off;            
}                                      


# Что слушаем и как. Что б не забивалось на тунельные адреса
listen {                                         
        isakmp 1.1.1.1;                     
        isakmp_natt 1.1.1.1 [4500];         
}                                                

# Значения таймеров. 
# На всех серверах должны быть идентичны. Иначе возможны варианты зависиния тунеля.
timer {                                  
        # Максимальное количество повторов
        counter 5;                        
        # Интервал между повторами        
        interval 20 sec;                  
        # Количество передаваемых пакетов за "посылку"
        persend 1;                                    

        # Максимальное время для завершения фазы 1
        phase1 30 sec;                            
        # Максимальное время для завершения фазы 2
        phase2 15 sec;                            
        #natt_keepalive 10sec;                    
}                                                 

# Удаленные клиенты. Можно написать ip, для остальных anonymous.
# Указываем IKE phase 1 для каждого удаленного клиента. Если    
# указан anonymous секция будет применена к каждому клиенту,    
# не попавшему под конкретную секцию (адрес вместо anonymous)   
remote anonymous {                                              
        # Метод обмена, если мы инициаторы. Так же принимать данный 
        # вид, если клиент. Можно несколько через запятую.          
        exchange_mode aggressive,main;                              
        # exchange_mode aggressive;                                 
        #eans to use IPsec DOI as specified in RFC 2407.  You can   
        # omit this statement.                                      
        # doi- область интерпретации ISAKMP (IKE).                  
        # В данном случае для ipsec.                                
        # doi ipsec_doi;                                            
        # Переидентификация узлов и сравнение политик раз в         
        # 24 часа.                                                  
        # !! На обоих узлах должно быть одинаково. win - ? !!       
        # !! Иначе тонель виснет. фаза1 > фаза2. !!                 
        lifetime time 24 hour;                                      
        # Если не хотим инициировать согласование, ставим off.      
        # Применимо только для сервера.                             
        passive off;                                                
        # Генерировать policy из proposal. Это используется для     
        # клиентов с динамическими адресами. (on | off | require | unique)
        # Имеет смысл только на сервере.                                  
        #!generate_policy on;                                             
        generate_policy off;                                              
        # The below line makes it work with other devices that propose    
        #  a lifetime longer than the racoon default of 28800.            
        # Alternatively, set a longer lifetime.  "proposal_check claim" may
        #  work suboptimally with frequent renegotiation of phase 2.       
        proposal_check obey;                                               

        # Включаем вкомпиленный в ядро NAT-T для клиентов за натом.
        # Можно сделать force для всех.                            
        nat_traversal on;                                          
        # Включаем IKE фрагментацию на принимающей стороне. В случае, если 
        # работает через кривой фаер, имеющий проблемы с фрагментацией udp.
        ike_frag on;                                                       

#       situation identity_only;
#       my_identifier asn1dn;   
#       peers_identifier asn1dn;

        # Методы аутентификации - шифрования клиентов.
        proposal {                                    
                # Алгоритм для фазы 1. Можно использовать
                # des, 3des, blowfish, cast128, aes, camellia
                encryption_algorithm 3des;                   
                # Хэш-алгоритм для фазы 1. Можно использовать
                # md5, sha1, sha256, sha384, sha512          
                hash_algorithm sha1;                         
                # Метод аутентификации для фазы 1. Можно использовать
                # pre_shared_key, rsasig (for plain RSA authentication), gssapi_krb,      
                # hybrid_rsa_server, hybrid_rsa_client, xauth_rsa_server, xauth_rsa_client,              
                # xauth_psk_server or xauth_psk_client.                                                  
                authentication_method pre_shared_key;                                                    
                # Определяем группу для Diffie-Hellman exponentiations. Группа должна                    
                # быть одной из: modp768, modp1024, modp1536, modp2048, modp3072,                        
                # modp4096, modp6144, modp8192.  Или можно использовать 1, 2, 5, 14, 15, 16,             
                # 17, или 18 в качестве DH-номера группы. Если используется                              
                # aggressive mode, необходимо установить индивидуальную группу
                # для каждого proposal.
                dh_group 2;
        }
}

# construct phase 2 proposals by combining sainfo specifications in
# racoon.conf, and policies in the kernel.
sainfo anonymous {
        # encryption_algorithm aes, 3des;
        encryption_algorithm 3des;
        # sha1 - немного секюрней, md5 немного быстрее. Можно
        # принудительно назначить какой-либо.
        # see http://www.ciscopress.com/articles/article.asp?p=25473
        authentication_algorithm hmac_md5, hmac_sha1;
        # Поскольку фаза 2 отвечает за ключи шифрования - время ее жизни
        # час. Раз в час меняем ключи.
        # !! На обоих узлах должно быть одинаково. win - ? !!
        # !! Иначе тонель виснет. фаза1 > фаза2. !!
        lifetime time 1 hour ;
        compression_algorithm deflate;
}
Данный конфиг заточен под конфиг венды, так же без проблем работает с юниксом, если его же перекинуть на клиента - что б совпадали все методы шифрования. Правда, пробовал только 1 клиента за раз.
Теперь по конфигу.
Коменты сверху и секция privsep для запуска ракуна под непривилегированным пользователем. Но штатный rc.d скрипт под это не рассчитан. Он его тупо не тормозит.
Все строки с natt коментим, если его нет в ядре. Или если собрано без его поддержки.
Секция timer. Тут интересно, что такое фаза 1 и 2.
Фаза 1.
узлы договариваются о методе шифрования, алгоритме, хэш-алгоритме и группе Diffie Hellman. Так же идентификация. Путем обмена 3 нешифрованными пакетами - aggressive mode, или шестью - main mode. В результате создается SA первой фазы (IKE SA).
Фаза 2.
Генерятся ключи, узлы договариваются о используемой политике. Все пакеты этой фазы шифруются. В результате создается phase 2 SA (IPSec SA).
SA - связь (ассоциация) безопасности. Это термин IPSec для обозначения соединения.

remote anonymous - мы предполагаем, что не знаем, с какого ип к нам будут конектиться. Если знаем, вместо anonymous пишем ип.
generate_policy off - заслуживает отдельного внимания, но о нем в разделе setkey.
proposal - может быть сколько угодно. Я для венды и фри использую одинаковые параметры.

Ну вот, собственно, по конфигу и все. Для аутентификации можно использовать сертификаты, можно парольную фразу. Я выбрал для начала второе, но по первому примеров масса и делается 2-5 строчками в конфиге. Пример тут http://www.lissyara.su/articles/freebsd/security/ipsec/. И так, парольная фраза. Алгоритм работы примерно таков. Узлы идентифицируют друг друга по парольной фразе, генерят сертификаты, обмениваются ими и создают шифрованный тунель. Обмен ключами осуществляется по протоколу IKE - итнтернет кей эксчейндж. Так же осуществляется переодическая смена ключей. Таким образом, если врагом будет получен один ключ, то расшифровать им он сможет только часть трафика до смены ключей. После смены старый ему никак не поможет, в .т.ч и в получении или перехвате нового. Парольные фразы хранятся в /usr/local/etc/racoon/psk.txt
В виде соответствия хост (ip) - пароль. Пример идет вместе с портом. например,
1.1.1.1 password
Тут возникает некая засада. А если клиенты на динамических адресах? Тут скажу спасибо некому человеку, который придумал следующее. К сожалению, автора не нашел. делаем make extract порта и правим:

Код: Выделить всё

# IMPORTANT:If you really need wildcard PSK (Pre-Shared Key) as well as main mode IP address identity support during PSK authentication
# (for Microsoft Windows XP clients etc.), you may want to apply the following changes to ipsec-toolsbefore compiling the package.
#
# Wildcard PSK (An asterisk "*" matches all IPs)
#
# In ipsec-tools/src/racoon/localconf.c, locate the function named "getpsk(str, len)"; then in the while loop, find the line that looks like:
#
# if (strncmp(buf, str, len) == 0 && buf[len] == '\0') {
# Replace it with:
# if (strcmp(buf, "*") == 0 || (strncmp(buf, str, len) == 0 && buf[len] == '\0')) {
# Save and exit.
# Recompile and reinstall if necessary.
#
# Main mode IP address identity
#
# In ipsec-tools/src/racoon/ipsec_doi.c, locate the function named "ipsecdoi_checkid1(iph1)"; then find the lines that look like:
#
# if (iph1->etype == ISAKMP_ETYPE_IDENT &&
# iph1->approval->authmethod == OAKLEY_ATTR_AUTH_METHOD_PSKEY) {
# if (id_b->type != IPSECDOI_ID_IPV4_ADDR
# && id_b->type != IPSECDOI_ID_IPV6_ADDR) {
# plog(LLV_ERROR, LOCATION, NULL,
# "Expecting IP address type in main mode, "
# "but %s.\n", s_ipsecdoi_ident(id_b->type));
# return ISAKMP_NTYPE_INVALID_ID_INFORMATION;
# }
# }
#
# Change LLV_ERROR into LLV_WARNING; comment out the return statement using /* */.
#
# Save and exit.
#
# Recompile and reinstall if necessary.
После этого вместо ip-адреса можно написать '*'. И пароль будет для всех. Не забудьте сделать права доступа 600 на файл с паролем.
И так, мы настроили конфиг, создали парольную фразу. Можно попробовать запустить ракун и убедиться,что все работает. Не забудьте добавить racoon_enable="YES" и racoon_create_dirs="YES" в rc.conf.
Теперь еще немного теории. Есть 2 базы. SAD и SPD. С обеими работаем через setkey. Лучше использовать тот, что идет вместе с портом - /usr/local/sbin/setkey, т.к. стандартный неккоректно работал с SAD лично у меня.

SA [/usr/local/sbin/setkey -D] - связь (ассоциация) безопасности. Это термин IPSec для обозначения соединения.При установленном соединении для каждого используемого протокола создается пара SA. Пара, т.к. SA - это днонаправыленное соединение, а данные передаются в обоих направлениях. SA- пары хранятся на каждом узле. Если есть SA - соединение установлено. На практике же можно шифровать трафик только в одном направлении. Просто попробовал ради интереса. От меня шел ESP (шифрованный), ко мне шел обычный l2tp. И тунель нормально работал)

SPD [/usr/local/sbin/setkey -PD] - база политик безопасности. Политики безопасности указывают, какой именно трафик надо шифровать. И какой трафик приходит шифрованным. Если на одном сервере укажем, например, что исходящий трафик на порту 1701 надо шифровать, а на соседе не указаем, что на порт 1701 приходит шифрованный трафик, то них работать не будет.
Данная база может заполняться из setkey.conf путем setkey -f setkey.conf. Как говорил выше, в конфиге есть интересная опция generate_policy off;. Если на СЕРВЕРЕ ее поставить в on, то на сервере будут создаваться политики, соответствующие политикам на клиенте. Например, если на клиенте мы укажем, что исходящий трафик на порт 1701 шифровать, то на сервере автоматом создастся правило, что входящий трафик с данного хоста(клиента) на порт 1701 будет шифрованным. Для начала рекомендую поставить on и оставить политики на сервере пустыми. Они заполнятся в соответствии с клиентом. Если взаимодействие политик будет настроено неправильно, шифрование не заработает и SA не создастся, насколько я помню.
Пример файла на клиенте.

Код: Выделить всё

# Чистим все.
flush;
spdflush;

# А вот и сами правила, что шифровать.
# добавляем правило на трафик от клиента(ип 2.2.2.2) с любым портом на сервер (ип 1.1.1.1) порт 1701 по протоколу udp, трафик является исходящим, шифруется, используется esp в режиме транспорта, обязательно.
spdadd 2.2.2.2[0] 1.1.1.1[1701] udp -P out  ipsec esp/transport//require;
# то же самое, только уже входящий (обратный) трафик. Параметры те же. Если убрать одну их этих строк - шифрование будет только в одном направлении.
spdadd 1.1.1.1[1701] 2.2.2.2[0] udp -P in  ipsec esp/transport//require;
На всякий случай, конфиг ракуна для клиента.

Код: Выделить всё

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

log info; 

padding { 
        maximum_length 20;
        randomize off;    
        strict_check off; 
        exclusive_tail off;
}

listen {
        isakmp 2.2.2.2;
        strict_address;
        adminsock "/var/db/racoon/racoon.sock";
}

timer {
        counter 5;
        interval 20 sec;
        persend 1;
        phase1 30 sec;
        phase2 15 sec;
}

remote 1.1.1.1 {
        exchange_mode aggressive,main;
        lifetime time 24 hour;
         my_identifier address;
         peers_identifier address;
         passive off;
        generate_policy on;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
}

sainfo anonymous {
        encryption_algorithm 3des;
        authentication_algorithm hmac_md5, hmac_sha1;
        lifetime time 1 hour ;
        compression_algorithm deflate;
}
Не забываем указать одинаковый пароль на клиенте и сервере в psk.txt.
При появлении трафика, попадающего под соответствующее правило, создадутся ключи и правила на сервере. Для теста, на клиенте можно попробовать racoonctl vc 1.1.1.1 (если собрано с админским контролем), а лучше запустить mpd.
Что б писались логи, добавляем в /etc/syslog.conf

Код: Выделить всё

!racoon
*.*                                             /var/log/racoon.log
Как правило,в логах все есть.
Пример баз на работающем клиенте
/usr/local/sbin/setkey -D

Код: Выделить всё

2.2.2.2 1.1.1.1
        esp mode=transport spi=176271203(0x0a81af63) reqid=0(0x00000000)
        E: 3des-cbc  c81782e2 cb844f5b 78c44a17 a9f1f815 a1a0e116 e0922af7
        A: hmac-md5  d8702bf1 ac42b5d9 aa93e0a6 d29be244
        seq=0x000000a3 replay=4 flags=0x00000000 state=mature
        created: Dec  8 11:06:28 2010   current: Dec  8 11:23:54 2010
        diff: 1046(s)   hard: 3600(s)   soft: 2880(s)
        last: Dec  8 11:23:45 2010      hard: 0(s)      soft: 0(s)
        current: 19344(bytes)   hard: 0(bytes)  soft: 0(bytes)
        allocated: 163  hard: 0 soft: 0
        sadb_seq=1 pid=1389 refcnt=2
1.1.1.1 2.2.2.2
        esp mode=transport spi=78827330(0x04b2cf42) reqid=0(0x00000000)
        E: 3des-cbc  4878e5af fa657ba6 38524d4f 0ef4781a a7897aec f1d9b5fe
        A: hmac-md5  f30c6fae ad7d3235 84d18049 8d380ea8
        seq=0x00000057 replay=4 flags=0x00000000 state=mature
        created: Dec  8 11:06:28 2010   current: Dec  8 11:23:54 2010
        diff: 1046(s)   hard: 3600(s)   soft: 2880(s)
        last: Dec  8 11:23:39 2010      hard: 0(s)      soft: 0(s)
        current: 5246(bytes)    hard: 0(bytes)  soft: 0(bytes)
        allocated: 87   hard: 0 soft: 0
        sadb_seq=0 pid=1389 refcnt=1
/usr/local/sbin/setkey -DP
[cod1.1.1.1[1701] 2.2.2.2[any] udp
in ipsec
esp/transport//require
created: Dec 8 11:24:44 2010 lastused: Dec 8 11:25:10 2010
lifetime: 0(s) validtime: 0(s)
spid=16407 seq=1 pid=1543
refcnt=2
2.2.2.2[any] 1.1.1.1[1701] udp
out ipsec
esp/transport//require
created: Dec 8 11:24:44 2010 lastused: Dec 8 11:25:10 2010
lifetime: 0(s) validtime: 0(s)
spid=16406 seq=0 pid=1543
refcnt=2e]
[/code]
А tcpdump на внешнем инт-е показывает

Код: Выделить всё

10:27:07.106514 IP 2.2.2.2 > 1.1.1.1: ESP(spi=0x0348e9f1,seq=0x54), length 140
10:27:07.106617 IP 1.1.1.1 > 2.2.2.2: ESP(spi=0x02e88b28,seq=0x4c), length 140
10:27:08.107413 IP 2.2.2.2 > 1.1.1.1: ESP(spi=0x0348e9f1,seq=0x55), length 140
10:27:08.107524 IP 1.1.1.1 > 2.2.2.2: ESP(spi=0x02e88b28,seq=0x4d), length 140
10:27:09.108299 IP 2.2.2.2 > 1.1.1.1: ESP(spi=0x0348e9f1,seq=0x56), length 140
10:27:09.108390 IP 1.1.1.1 > 2.2.2.2: ESP(spi=0x02e88b28,seq=0x4e), length 140
10:27:10.109189 IP 2.2.2.2 > 1.1.1.1: ESP(spi=0x0348e9f1,seq=0x57), length 140
10:27:10.109311 IP 1.1.1.1 > 2.2.2.2: ESP(spi=0x02e88b28,seq=0x4f), length 140
При активности внутри l2tp.
Имена и фамилии изменены (с)

Это то,как я понял. Если есть чо добавить - поправить, с удовольствием выслушаю.

Хостинговая компания Host-Food.ru
Хостинг HostFood.ru
 

Услуги хостинговой компании Host-Food.ru

Хостинг HostFood.ru

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-08 11:01:19

Да, совсем забыл. Для работы используется порт isakmp для обмена ключами (IKE) и протокол esp для передачи трафика.
Правила в pf.conf на сервере.

Код: Выделить всё

pass in inet proto {tcp,udp} from 2.2.2.2 to 1.1.1.1 port isakmp flags S/SA keep state
pass in inet proto esp from 2.2.2.2 to 1.1.1.1 keep state

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-08 14:37:38

Еще есть пикольная хреновина -

Код: Выделить всё

# DPD - dead peer detection. Обнаружение мертвых соседей.
 # keep-alive раз в 10 сек.
dpd_delay 10;
# Сколько ждать ответа на keep-alive. По истечении - следующий. 
dpd_retry 5;
# Макс. количество неудач, после которых сосед считается мертвым.
dpd_maxfail 5;
Описания принципов работы не нашел, но, судя по логике, удаляет SA, если соединение умерло.

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-09 11:43:27

База SP (SPD - правила, которые указывают, какой трафик шифруем, загружается через setkey) обнуляется при перезагрузках, переодически при рестарте и т.п., что вызывает некие проблемы, если есть куча удаленных серверов, которые переодически вырубаются из-за отключения света и т.п. Решение следующее.

Код: Выделить всё

ipsec_enable="YES"
ipsec_file="/usr/local/etc/racoon/setkey.conf"
Это стандартный фряшный стартовый скрипт, который просто загружает правила из ipsec_file, чистит базу и т.п. и больше ничего не делает.

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-10 13:29:20

Небольшое уточнение.

Код: Выделить всё

# Если используется
# aggressive mode, необходимо установить однинаковую группу
# для каждого proposal.
dh_group 2;

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-10 14:31:28

Если заработало psk, но хочется чего-то большего, прикручиваем аутентификацию по сертификатам.
Для начала их необходимо создать.
Для аутентификации по сертификатам необходим корневой сертификат (CA), ключ с паролем для него и клиентский сертификат. Корневой сертификат один и мы принимаем все клиентские, подписанные им. Для подписания клиентского сертификата мы используем корневой и ключ с паролем.

И так, по шагам. Есть много способов, но этот, на мой взгляд, один из самых прозрачных.
Создаем папку /usr/local/etc/racoon/cert и переходим в нее.
Корневой сертификат
1. Генерим ключ с паролем для корневого сертификата. Так же ключ необходимо запаролить. Этот пароль используется для подписания клиентских сертификатов, так что от его сложности, по большому счету, зависит стойкость всех клиентских сертификатов. Пароль не восстанавливается, поэтому при его утере генерить новые клиентские сертификаты не получится.

Код: Выделить всё

openssl genrsa -des3 -out ca/ca.key 1024
-des3 - метод шифрования.
-out ca.key - сохраняем ключ в файл ca.key текущей директории.
1024 - длина ключа в битах.

2. Генерим сам сертификат. Сертификат будет самоподписанным, т.к. CA у нас свой, а сертификат первый в иерархии.

Код: Выделить всё

openssl req -new -x509 -days 1095 -key ca/ca.key -out ca/ca.crt
req -new - запрос на новый сертификат
-x509 - тип сертификата (с открытым ключом - несимметричное шифрование).
-days 1095 - "срок годности" сертификата, начиная с момента генерации (3 года).
-key ca.key - файл с ключом для корневого сертификата.
-out ca.crt - в этот файл сохраняем полученный корневой сертификат.

Эти действия проделываются 1 раз. Как правило, корневой сертификат один и им подписывается множество клиентских.При замене корневого так же будет необходимо заменить все клиентские.

Клиентские сертификаты.
Сертификаты для сервера и для клиента генерятся одинаково, т.к. отдельно шифруется исходящий и входящий трафик.
Пример для сервера, клиент аналогичен, только меняем в названиях файлов server на клиент. Так же создаем все вложенные папки.

1. Генерим ключ с паролем.

Код: Выделить всё

openssl genrsa -out server/server.key 1024
2. Генерим запрос на сертификат.

Код: Выделить всё

openssl req -new -key server/server.key -out server/server.csr
3. Выдаем сертификат и подписываем его корневым. Тут вводим пароль к ключу корневого сертификата.

Код: Выделить всё

openssl x509 -req -days 365 -in server/server.csr -CA ca/ca.crt -CAkey ca/ca.key -CAcreateserial -out server/server.crt
В результате мы получаем клиентский сертификат для сервера - server.crt. Запрос на создание - server.csr можно удалить.

Сертификат для клиента. Метод создания аналогичен серверному.

Код: Выделить всё

openssl genrsa -out client/client.key 1024
openssl req -new -key client/client.key -out client/client.csr -config ./opensss.conf
openssl x509 -req -days 365 -in client/client.csr -CA ca/ca.crt -CAkey ca/ca.key -CAcreateserial -out client/client.crt
opensss.conf - создал для удобства, т.к. заполнять,по большому счету, одинаковыми значениями поля для 100 клиентских сертификатов достаточно напряжно.

Код: Выделить всё

cat racoon/sert/opensss.conf                                                                                                                                           
# Establish working directory.                                                                                                                                                               
dir                                     = .                                                                                                                                                  

[ req ]
distinguished_name                      = req_distinguished_name

[ req_distinguished_name ]
countryName                     = Country Name (2 letter code)
countryName_default             = RU
countryName_min                 = 2
countryName_max                 = 2

stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = My_city obl

localityName                    = Locality Name (eg, city)
localityName_default            = My_city

0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = My_organization

# we can do this but it is not needed normally :-)
#1.organizationName             = Second Organization Name (eg, company)
#1.organizationName_default     = World Wide Web Pty Ltd

organizationalUnitName          = Organizational Unit Name (eg, section)
organizationalUnitName_default  = CO

commonName                      = Common Name (eg, YOUR name)
commonName_max                  = 64
commonName_default              = proxy.my_org.ru

emailAddress                    = Email Address
emailAddress_max                = 64
emailAddress_default            = root@my_org.ru

Что бы можно было установить сертификат на венду, его надо переобуть в формат PKCS(Public Key Cryptography Standards). Установку его на венду оставлю любителям оной, вроткампот эту ос.

Код: Выделить всё

openssl pkcs12 -export -inkey client/client.key -certfile ca/ca.crt -in client/client.crt -out client/win-client.p12
И так, сертификаты созданы.
Посмотреть можно так

Код: Выделить всё

openssl x509 -noout -issuer -subject -dates -in client.crt
openssl x509 -text -in client.crt
Правим racoon.conf
Добавляем путь к папке с сертификатами

Код: Выделить всё

path certificate "/usr/local/etc/racoon/cert" ;
Дальше есть 2 варианта.
1. Добавляем аутентификацию по сертификатам в секцию remote anonymous. Добавялем строки

Код: Выделить всё

        # Что отсылаем в качестве идентификатора. Насколько я понял, используется. для сопоставления пары ключа и сертификата. 
        # Отсылаем в качестве dn поле Subject сертификата. От соседа требуем того же.
        my_identifier asn1dn;
        peers_identifier asn1dn;
        # Я так понял, что клиент должен отправить в identifier то, что указано в peers_identifier, иначе соединение не установится.
        verify_identifier on;
        # Проверка клиентского сертификата. identifier, посланный клиентом ( my_identifier на клиенте),  сравнивается с параметрами сертификата на сервере.
        # В случае с asn1dn поле  subject сравнивается с identifier. (попарно сравниваются "C=XX, O=YY, и т.п.)
        verify_cert on;
        # Указываем путь к клиентскому и серверному сертификатам.
        # Наши сертификаты - сертификат сервера и ключ.
        certificate_type x509 "server/server.crt" "server/server.key";
       # Сертификат клиента.
        peers_certfile x509 "client/client.crt";
И добавляем еще один proposal c authentication_method rsasig.

Код: Выделить всё

        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method rsasig;
                dh_group 2;
        }
Для клиента конфиг тот же, только меняем

Код: Выделить всё

        certificate_type x509 "client/client.crt" "client/client.key";
        peers_certfile x509 "server/cserver.crt";
Т.е. нашим сертификатом становится клиентский, а удаленным (peers) - серверный. Доступ на сертификаты - 400, владелец - от кого запущен racoon.
Все.
Теперь клиенты могут аутентифицироваться по сертификатам. С динамических адресов. Проблема одна - в секции remote может быть только 1 peers_certfile. Поэтому либо все аутентифицируются по одному сертификату, либо вариант 2.

Вариант 2. Создаем шаблон вида

Код: Выделить всё

remote 127.0.0.2 {
        exchange_mode aggressive,main;
        doi ipsec_doi;
        lifetime time 24 hour;
        passive on;
        generate_policy on;
        proposal_check obey;
        nat_traversal on;
        ike_frag on;
        my_identifier asn1dn;
        peers_identifier asn1dn;
        verify_identifier on;
        verify_cert on;
        certificate_type x509 "server/server.crt" "server/server.key";
        #peers_certfile x509 "client/client.crt";

        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method rsasig;
                dh_group 2;
        }
}

И по нему шлепаем клиентов со статическими адресами, каждый из которых аутентифицируется по собственному сертификату.

Код: Выделить всё

remote 91.208.126.253 inherit 127.0.0.2 {
        peers_certfile x509 "client/client.crt";
}
При этом remote anonymous так же можно оставить.
Как заставить racoon выбирать подходящий сертификат из списка и обойтись единственной секцией anonymouns с множеством клиентских сертификатов я так и не нашел. Походу, никак.
Остается несколько вопросов.
1. Если один сертификат будут использовать несколько клиентов (если это вообще возможно), шифроваться будет им же, или для шифрования генерятся отдельные ключи? Если им же, то это не очень хорошо.
2. Опять же, если шифруется им, то смены ключа шифрования по времени тоже не произойдет - в psk я менял каждый час.

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-10 14:46:52

Насколько я понял, корневой (СА) сертификат нужен только для венды, что б у нее была нормальная иерархия без ругани на недоверенные сертификаты. В юниксе он, как бэ, нах не надо. В любом случае, в конфигах он не участвует, а при его замене и генерации нового серверного сертификата (клиентский остался тот же, со старым корневым), все отлично работает.

snorlov
подполковник
Сообщения: 3927
Зарегистрирован: 2008-09-04 11:51:25
Откуда: Санкт-Петербург

Re: IPSec теория и практика

Непрочитанное сообщение snorlov » 2010-12-10 15:42:46

Мне кажется вы где-то потеряли открытый сертификат CA, по которому проверяется подлинность выданных им сертификатов, в данном случае сервер запрашивает сертификат клиента, не в чистом виде конечно, а уже в шифрованном, и именно по нему и сертификату CA устанавливает подлинность сертификата клиента, так же действует и сам клиент...

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-10 16:59:14

Ну, скажу так, его можно указать, но толку это не дает, по крайней мере, я не нашел. Или не понял. Да и ассимитричное шифрование не подразумевает никаких корневых сертификатов. Скажу даже больше, если на клиенте вообще не указывать (не копировать) сертификат сервера, то сервер с радостью его отдает. Получается, по приведенный выше схеме (а это подавляющее большинство решений в интернете) аутентификация на основе сертификатов не производится. Только шифрование. Кстате, в этом случае на клиенте и сервере сертификаты были подписаны разными корневыми, и все работало. Другое дело, можно принудительно отключить выдачу публичного ключа сервером

Код: Выделить всё

send_cert off;
Тогда клиенту будет просто нечем шифровать.
Если подскажите, зачем вообще тут нужен корневой сертификан с конкретным примером - буду благодарен. Чуть позже напишу про plainrsa ключи, там вообще все просто. Генерятся одной строкой и 2 строчки в конфиг. Исходя из вышесказанного вообще не вижу смысла в х509 сертификатах тут по сравнению с ключами plainrsa.

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-10 17:08:51

Есть пример,так называемый road warrior. Там как раз используется х509 и корневой сертификат. Там сервер аутентифицируется на клиенте по сертификатам (у сервера - публичный и приватный, у клиента - корневой), а клиент на сервере по логину-паролю. Схема наподобии ssh, когда проверяется не только подлинность клиента, но и сервера.

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-10 17:33:23

Как итог, получается 3 метода аутентификации:
1. PSK - аутентификация по паролю. Если пароль подошел, генерятся сертификаты и сервера обмениваются ими автоматически по IKE.
2. Plain_rsa - для каждого направления трафика генерится пара ключей (не сертификатов!) - публичный и приватный. Публичный раздается для шифрования - приватный оставляем для расшифровки. Если соединение unix-unix, то использовать х509 сертификаты тут не имеет смысла. Но, подозреваю, что винда не умеет работать с чистыми ключами и поэтому при работе с виндой все придется использовать х509 сертификаты. Но корневой сертификат тут будет абсолютно не при чем.
3. hybrid_rsa. Описывается в семплах, идущих с портом в каталоге /usr/local/share/examples/ipsec-tools/roadwarrior. Конфиги очень просты, рассматривать подробно смысла не вижу. Суть работы примерно как у ssh. Аутентифицируется не только клиент на сервере, но и сервер на клиенте, т.е. клиент проверяет подлинность сервера. На сервере хранится пара сертификата и ключа х509, а клиентам раздается корневой сертификат. Клиент аутентифицируется на сервере по логин-паролю, а сервер на клиенте по сертификатам.

snorlov
подполковник
Сообщения: 3927
Зарегистрирован: 2008-09-04 11:51:25
Откуда: Санкт-Петербург

Re: IPSec теория и практика

Непрочитанное сообщение snorlov » 2010-12-10 17:49:57

Трафик шифруется временыыми ключами, время жизни ключа

Код: Выделить всё

sainfo anonymous {
        lifetime time 1 hour ;
}
У сервера должен быть свой сертификат и публичный сертификат,и у клиента должен быть свой сертификат и публичный сертификат.
И вообще свой сертификат нигде в сети не светится, светится то, что генерится на базе его и публичного сертификата и сам публичный сертификат.

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-10 22:06:36

Хотя да, вот,наверное,и ответ. Все ключи-методы аутентификации относятся к фазе 1, у которой лайфтайм сутки. А ключи шифрования трафика генерятся на фазе2. Остается только надеяться, что они рандомные и не зависят от ключей-сертификатов фазы1. Я думаю, что сертификаты фазы 1 используются для инициации фазы 2 в шифрованном режиме. И не важно, генерятся ли они рандомно или заранее указаны. Почему не для аутентификации - ниже)
В понедельник почитаю на эту тему.
Дружище, ты только что повторил то, что я писал почти в каждом посту сверху))
Под своим сертификатом ты понимаешь приватный ключ? Тогда что генерится на основе приватного и публичного ключей?
Но сути не меняет)
Вообще суть ассиметричного шифрования в 2-х ключах. приватном и публичном. Приватный храним у себя и никому не показываем, публичный не имеет никакой ценности с точки зрения безопасности в данном случае, поэтому раздаем его направо и налево (тут - клиенту). Клиент шифрует сообщение открытым ключом и отправляет нам. А вот рассшифровать его можно только приватным ключом, который находится на сервере. Таким образом, шифруется одно направление трафика. Для обратного - по аналогии.
Ну, это я для тех, кто не понял))

Ну, и еще раз повторю. В примере 2 с предыдущего поста никакой авторизации по сертификатам, по большому счету, нет. Ее можно сделать косвенно, если не разрешать серверу выдавать свой публичный ключ клиенту и хранить его на клиенте сразу. Но, по-умолчанию, выдача разрешена. С другой стороны, можно не копировать на клиента публичный ключ сервера, а заставить его просто стягивать с сервера при соединении. И не обязательно,что б у клиента и сервера был один СА. Сертификаты х509 используются как обычные рандомные ключи. Т.е., говоря простым языком, клиент может постучаться на сервер, сказать, что у него есть свой хзоткудавзятый публичный и приватный ключ, запросить у сервера его публичный ключ, отдать ему свой публичный и соединение установится. Единственное, что может этому, возможно, помешать - verify_cert. Но пока не нашел,что же она на самом деле верифи.

Пример 3 не отличается от примера 1 для среднего пользователя абсолютно ничем, кроме более сложного исполнения и заморочки на сертификаты с СА. Я думаю, врядли кто-то станет подменять адрес сервера и т.п. Смысл проверять, что обращаяясь на свой сервер по адресу а.б.с.д. там действительно мой сервер. Ну хз, на любителя..

Получается оптимальный вариант по простоте - эффективности psk, т.е. обычная аутентификация по паролю. И на венде она,кстате, отлично работает.

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-13 11:34:46

И так, аутентификация по сертификатам!)
Все, что выше про сертификаты - лажа, а не аутентификация. Как и 90% статей на эту тему в Интернете.
Делаем так. Генерим СА, сертификат сервера и клиента. Серверный сертификат с ключом кладем на сервер, клиентский на клиента. Таким образом мы получаем, что множество клиентов могут логиниться по секции anonymous с различных адресов каждый со своим сертификатом. При установлении соединения, сервер запрашивает у клиента его публичный ключ, а клиент у сервера. Локально мы их не храним. Все. сервера обменялись ключами. У сервера свой публичный и приватный + полученный публичный от клиента, у клиента аналогично. Далее аутентификация. На сервере мы указываем корневой СА сертификат, по которому он проверяет клиентские и включаем эту проверку. На клиенте можно сделать аналогично, но смысла не вижу, поэтому клиент просто доверяет сертификату, пришедшему с сервера. И так, если клиентский сертификат подписан тем же СА, что указан на сервере, аутентификация пройдена. Конфиги:
Сервер

Код: Выделить всё

 remote anonymous {
        exchange_mode aggressive,main;
        doi ipsec_doi;
        lifetime time 24 hour;
        passive on;
        generate_policy on;
        proposal_check obey;
        nat_traversal on;
        ike_frag on;
        my_identifier asn1dn;
        peers_identifier asn1dn;
        verify_identifier on;
        # Посылаем запрос на сертификат
        send_cr on;
        # Проверяем пришедший сертификат на соответствие СА
        verify_cert on;
        # Разрешаем отправку своего сертификата 
        send_cert on;
        # Непосредственно сертификат и ключ сервера
        certificate_type x509 "server/server.crt" "server/server.key";
        # Корневой сертификат для проверки
        ca_type x509 "ca/ca.crt";
        #peers_certfile x509 "client/client.crt";

        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method rsasig;
                dh_group 2;
        }
}
На клиенте соответствующий кусок.

Код: Выделить всё

        verify_identifier on;
        #
        verify_cert off;
        send_cert on;
        send_cr on;
        certificate_type x509 "client.crt" "client.key";
        #peers_certfile x509 "server.crt";

        proposal {
Не забываем дать права на чтание сертификатов пользователю, от которого запущен ракун.
Проверяем. Соединение должно нормально установиться. Далее можно попробовать поменять клиентский сертификат на левый, с другим СА, или непосредственно СА-ключ. В логах получаем примерно следующее

Код: Выделить всё

ERROR: the peer's certificate is not verified.
А на клиенте

Код: Выделить всё

ERROR: fatal INVALID-CERT-AUTHORITY notify messsage, phase1 should be deleted
Все хорошо. Но если порядка 100 клиентов и 1 сертификат утерян. Менять СА и все оставшиеся 99 сертификатов - не вариант. Поэтому делаем список отозванных сертификатов. Смысл в том, что если сертификат скомпрометирован - добавляем его в этот список и он больше не действует, несмотря на правильную подпись СА.

1. Генерим список отозванных сертификатов. После добавления сертификата в список его необходимо переинициализировать етой же комендой. Не звабывает установить серийник.

Код: Выделить всё

cat > ca/crlnumber
01
touch ./ca/index.txt
openssl ca -gencrl -keyfile ca/ca.key -cert ca/ca.crt -out ca/crl.pem -config opensss.conf
2. Отзываем сертификат так.

Код: Выделить всё

openssl ca -revoke server.crt -crl_reason affiliationChanged -config openssl.conf
3. Смотрим список отозванных сертификатов.

Код: Выделить всё

openssl crl -in ca/crl.pem  -text -noout
4. Что б список видел ракун, делаем такую штуку

Код: Выделить всё

cd /usr/local/etc/racoon/cert
ln -s ca/crl.pem `openssl crl -noout -hash < ca/crl.pem`.r0
Все. Можно попробовать отозвать сертификат, сделать шаг 2, 1(только команду openssl), 3, 4 и при попытке подключения в логах получим

Код: Выделить всё

ERROR: certificate revoked(23) at depth:0

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-13 12:00:47

Как удалить сертификат из списка отзыва средствами openssl не нашел. По-деревенски можно просто удалить строку из ca/index.txt и пересобрать базу. Кстате, ссылку обновлять не надо.

Код: Выделить всё

CRLReason ::= ENUMERATED {
    unspecified             (0),
    keyCompromise           (1),
    cACompromise            (2),
    affiliationChanged      (3),
    superseded              (4),
    cessationOfOperation    (5),
    certificateHold         (6),
    removeFromCRL           (8),
    privilegeWithdrawn      (9),
    aACompromise           (10)}
 
removeFromCRL вроде как не работает..

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-14 12:07:46

Понадобилось еще подключать вендовых ipsec\l2tp клиентов. Еще раз убедился, что если не знаешь, лучше не лезть, но, т.к. вендовый админ в командировке, пришлось делать самому. Короче, венда.
На венду копируем win-client.p12 и ca.crt. Насчет последнего - попрос, т.к. р12 уже, по идее, его содержит. А вот дальше самое интересное. Зачем так сделано, я так и не понял. Сертификаты можно установить, просто кликнув на них как на .exe. Но не тут-то было. Установленные таким образом сертификаты с l2tp работать не будут. Делаем пуск->выполнить->mmc. Добавляем центр управления сертификатами. В местере указываем локальный компьютер. А вот мастер установки при щелкании по сертификату ставит его "для текущего пользователя" и l2tp клиент его не видит.
Сгрыз не один монитор, пока понял. Добавляем клиентский сертификат в личные и, если хотим, что б все было кошерно, корневой во доверенные центры. Дальше настраиваем обычное vpn соединение мастером. В свойствах тип указываем l2tp/ipsec. Другие параметры, как то: ставить парольную фразу, делать аутентификацию по сертификатам и т.п., делать не надо. Не забываем, что IPSec работает отдельно, а l2tp клиент отдельно.

Mark_ua
проходил мимо

Re: IPSec теория и практика

Непрочитанное сообщение Mark_ua » 2010-12-14 16:39:50

Не хочу утверждать, так как не проверял на 8.1, на всех предидущих собрать ядро с IPSEC без crypto не удавалось.
Если это так, то прошу фразу "по желанию" заменить на "обязательно".
К сожалению сейчас проверить самому, нет времени.

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-14 17:03:17

Если не ошибаюсь, на 6.какой-то собралось, но при этом не понимало ни одного метода шифрования. Хорошо, заменю формулировку.

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-15 11:47:48

Короче, по поводу NAT-T и винды. ХР начиная со второго сервис-пака его понимает. Вот только соединения из-за ната не получается. Все согласовывается, устанавливается ipsec соединение, пролетают несколько инкапсулированных в udp esp пакетов от клиента к серверу и все. Ну, еще кип-элайвы. Сдается мне, что на фре nat-t так до конца и не доделали.

Код: Выделить всё

11:44:59.065345 IP 2.2.2.2.53661 > 1.1.1.1.4500: UDP-encap: ESP(spi=0x07bbb485,seq=0x5), length 140
11:45:03.038990 IP 1.1.1.1.4500 > 2.2.2.2.53661: isakmp-nat-keep-alive
11:45:03.987148 IP 2.2.2.2.53661 > 1.1.1.1.4500: isakmp-nat-keep-alive

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-15 14:09:21

Короче, похоже, допер. Скажу сразу, l2tp\IPSec через nat на фре работать не будет. Возможно, причиной этого все та же независимость IPSec и l2tp. Возможно, будет работать другой порт - не mpd. При этом и клиент (winxp sp2 и выше), и сервер NAT-T понимают и успешно договариваются о соединении.

Причина довольно интересна. у нас отсутствует поддержка NAT-OA (rfc3947), который позволяет обновлять чек-суммы пакетов при получении. Для tcp эта проверка обязательна. Для udp (в т.ч. l2tp) проверку можно отключить.
Я пробовал через

Код: Выделить всё

 sysctl net.inet.udp.checksum
Но это не помогло. Похоже, само приложение, осуществляющее l2tp, производит проверку чек-сумм пакетов и, ясен пень, они не сходятся. Как результат - IPsec сессия устанавливается, а пакетики внутри нее не бегают. Точнее, доходят от клиента к серверу, сервер их принимает (на стороне ракуна никаких ошибок нет), проверяет чек сумму - она ясенхрен из-за ната не сходится, и сервер (или само приложение) дропает пакеты, не передавая их на обработку приложению - mpd. Поэтому в логах mpd тоже пусто.

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-15 14:29:54

Да, откуда я это взял (то, что выше). Пробуем подключиться из-за ната и смотрим

Код: Выделить всё

netstat -s -p udp
...
        61 with bad checksum
        1316 with no checksum

...
И эти числа растут.

Немного справки. Полезно при разборе логов и tcpdump`ов.
NAT-D nat discovery - проверяет, если ли нат на пути согласования. Для соединения используются 2 пакета - по доному в каждую сторону
NAT-K - nat keep alive - пакеты состояния тунеля
NAT-OA - Original Address (NAT-OA) IKE. содержит оригинальный адрес хоста для прохождения через нат.

Аватара пользователя
kharkov_max
капитан
Сообщения: 1862
Зарегистрирован: 2008-10-03 14:56:40

Re: IPSec теория и практика

Непрочитанное сообщение kharkov_max » 2010-12-23 15:13:21

День добрый.

Вопрос.
Есть 2 сети.
Одна сидит на Adsl со статическим IP, вторая за Nat провайдера.
Связал их через MPD5, но что то мне кажется, что нормально на mpd5 работать не будет.

Хочу попробовать использовать IPSEC по вашей статье.
Вопросы:
1. Получится ли мне, теоретически, реализовать тунель из выше описанных условий ?
2. Если получится, то для такого тунеля, необходимо что б 2я сеть (за Nat) была клиентом.
Исходя из статьи где нужно править это:
Тут возникает некая засада. А если клиенты на динамических адресах? Тут скажу спасибо некому человеку, который придумал следующее. К сожалению, автора не нашел. делаем make extract порта и правим:
и т.д.
По содержимому текста не смог найти в извлеченном порте..
Ткните носом где и в каком файле.

Спасибо.

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-23 17:07:56

kharkov_max писал(а):День добрый.

Вопрос.
Есть 2 сети.
Одна сидит на Adsl со статическим IP, вторая за Nat провайдера.
Связал их через MPD5, но что то мне кажется, что нормально на mpd5 работать не будет.
Будет. l2tp точно будет. Да и pptp, скорее всего. Не забудьте настроит соотв. модем.
kharkov_max писал(а): Хочу попробовать использовать IPSEC по вашей статье.
Вопросы:
1. Получится ли мне, теоретически, реализовать тунель из выше описанных условий ?
2. Если получится, то для такого тунеля, необходимо что б 2я сеть (за Nat) была клиентом.
1. Так работают очень многие. Пробем не вижу. В моем примере IPSEC накладывается на уже рабочий тунель на mpd.
2. Да, так проще.
kharkov_max писал(а): Исходя из статьи где нужно править это:
Тут возникает некая засада. А если клиенты на динамических адресах? Тут скажу спасибо некому человеку, который придумал следующее. К сожалению, автора не нашел. делаем make extract порта и правим:
и т.д.
По содержимому текста не смог найти в извлеченном порте..
Ткните носом где и в каком файле.

Спасибо.
Прочитайте внимательно.

Код: Выделить всё

In ipsec-tools/src/racoon/localconf.c, locate the function named "getpsk(str, len)"
В файле ipsec-tools/src/racoon/localconf.c найдите функцию getpsk(str, len) и далее по тексту.
Дочитайте статью до конца, мой вам совет.
Незачто.

ASMi
проходил мимо
Сообщения: 1
Зарегистрирован: 2010-12-27 0:05:10

Re: IPSec теория и практика

Непрочитанное сообщение ASMi » 2010-12-27 0:17:58

Работает через 2 NAT-а на ФРЕ!!!

(по следам http://lists.freebsd.org/pipermail/free ... 39726.html)

в /usr/src/sys/netipsec/ipsec_input.c
после

Код: Выделить всё

prot = ip->ip_p;
добавляем

Код: Выделить всё

#ifdef IPSEC_NAT_T
        if (saidx->mode == IPSEC_MODE_TRANSPORT && sproto == IPPROTO_ESP) {
                if (prot == IPPROTO_TCP || prot == IPPROTO_UDP) {
                /* Ignore checksum of packet protected by ESP.  */
                        m->m_pkthdr.csum_flags |= (CSUM_DATA_VALID | CSUM_PSEUDO_HDR);
                        m->m_pkthdr.csum_data = 0xffff;
                }
        }
#endif
После этого фря перестает проверять консистентность UDP пакетов с ESP. Говорят в линуксе ракун работает таким же образом. Ядро не проверяет UPD пакеты с инкапсулированным ESP.

Код: Выделить всё

# uname -r
8.1-RELEASE
Последний раз редактировалось Alex Keda 2010-12-27 8:49:43, всего редактировалось 1 раз.
Причина: Товарищщи, цените чужое время, юзайте кнопочку [code]...

Al
ст. прапорщик
Сообщения: 501
Зарегистрирован: 2007-10-18 13:42:48
Откуда: Тверь
Контактная информация:

Re: IPSec теория и практика

Непрочитанное сообщение Al » 2010-12-27 9:18:21

Остальная часть патча, как я понял, позволяет включать-отключать проверку чек-сумм через sysctl + делать рекалькуляцию пакетов (но racoon этого не поддерживает, т.к. не посылает NAT-OA)+еще какие-то проверки?
Интересно, какие потенциальные косяки может вызвать подобное отключение..
ЗЫ. кому невпадлу - пробуйте. В случае пары положительых отзывов добавляю в статью:)