ipsec
Eugene Grosbein
Есть два роутера на FreeBSD в одном ethernet-сегменте.
Хочу зашифровать payload пакетов, ходящих между машинами при помощи IPSEC,
заголовки шифровать не надо. Адрес 1.1.1.161/30 на одной машине,
1.1.1.162/30 на второй. Пока на статических ключах.
Пишу в /etc/ipsec.conf на машине 1.1.1.161:
# правило шифрования потока
add 1.1.1.161 1.1.1.162 esp 1000 -m transport -E blowfish-cbc "key1";
add 1.1.1.162 1.1.1.161 esp 2000 -m transport -E blowfish-cbc "key2";
# описание первого потока
spdadd 1.1.1.162/32 1.1.1.161/32 any -P in ipsec
esp/transport/1.1.1.162-1.1.1.161/require;
spdadd 1.1.1.161/32 1.1.1.162/32 any -P out ipsec
esp/transport/1.1.1.161-1.1.1.162/require;
Hа второй машине симметричная конфигурация. Все работает, пинги ходят,
tcpdump показывает шифрованный трафик.
Теперь хочу также зашифровать транзитный трафик, первая машина на другом
своем интерфейсе имеет сеть 1.1.1.65/26, вторая 1.1.1.1/26.
Добавляю в ipsec.conf по аналогии (на второй машине симметрично):
# описание второго потока
spdadd 1.1.1.0/26 1.1.1.64/26 any -P in ipsec
esp/transport/1.1.1.162-1.1.1.161/require;
spdadd 1.1.1.64/26 1.1.1.0/26 any -P out ipsec
esp/transport/1.1.1.161-1.1.1.162/require;
Теперь запускаю тот же ping между теми же машинами,
но теперь c адреса 1.1.1.65 на 1.1.1.1. Hа отвечающей машине вижу
tcpdump'ом входящий зашифрованный пакет и все. Ответа нету.
Hа отвечающей машине в начале списка правил стоит allow icmp from any to me,
оно не мачится. Вывод - пакеты не расшифровываются.
Что я делаю не так?
Eugene
--
"Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
Eugene Grosbein
EG> # правило шифрования потока
EG> add 1.1.1.161 1.1.1.162 esp 1000 -m transport -E blowfish-cbc "key1";
EG> add 1.1.1.162 1.1.1.161 esp 2000 -m transport -E blowfish-cbc "key2";
А вот если тут убрать -m transport...
EG> # описание второго потока
EG> spdadd 1.1.1.0/26 1.1.1.64/26 any -P in ipsec
EG> esp/transport/1.1.1.162-1.1.1.161/require;
EG> spdadd 1.1.1.64/26 1.1.1.0/26 any -P out ipsec
EG> esp/transport/1.1.1.161-1.1.1.162/require;
... и заменить transport на tunnell...
EG> Теперь запускаю тот же ping между теми же машинами,
EG> но теперь c адреса 1.1.1.65 на 1.1.1.1. Hа отвечающей машине вижу
EG> tcpdump'ом входящий зашифрованный пакет и все. Ответа нету.
... тогда все работает, но шифруются и заголовки тоже.
Может возникнуть проблема с Path MTU Discovery?
Valentin Nechayev
EG> # описание первого потока
EG> spdadd 1.1.1.162/32 1.1.1.161/32 any -P in ipsec
EG> esp/transport/1.1.1.162-1.1.1.161/require;
EG> spdadd 1.1.1.161/32 1.1.1.162/32 any -P out ipsec
EG> esp/transport/1.1.1.161-1.1.1.162/require;
EG> Hа второй машине симметричная конфигурация. Все работает, пинги ходят,
EG> tcpdump показывает шифрованный трафик.
[...]
EG> Теперь хочу также зашифровать транзитный трафик, первая машина на другом
EG> своем интерфейсе имеет сеть 1.1.1.65/26, вторая 1.1.1.1/26.
Создай на обеих сторонах по gif-интерфейсу и загоняй в туннель.
-netch-
Valentin Nechayev
EG>> # правило шифрования потока
EG>> add 1.1.1.161 1.1.1.162 esp 1000 -m transport -E blowfish-cbc "key1";
EG>> add 1.1.1.162 1.1.1.161 esp 2000 -m transport -E blowfish-cbc "key2";
EG> А вот если тут убрать -m transport...
EG>> # описание второго потока
EG>> spdadd 1.1.1.0/26 1.1.1.64/26 any -P in ipsec
EG>> esp/transport/1.1.1.162-1.1.1.161/require;
EG>> spdadd 1.1.1.64/26 1.1.1.0/26 any -P out ipsec
EG>> esp/transport/1.1.1.161-1.1.1.162/require;
EG> ... и заменить transport на tunnell...
Не советую. Есть много жалоб на проблемы MTU в этом случае.
Лучше явный gif.
Заодно вместо линейного списка SP получаешь отработку таблицей раутинга.
EG>> Теперь запускаю тот же ping между теми же машинами,
EG>> но теперь c адреса 1.1.1.65 на 1.1.1.1. Hа отвечающей машине вижу
EG>> tcpdump'ом входящий зашифрованный пакет и все. Ответа нету.
EG> ... тогда все работает, но шифруются и заголовки тоже.
EG> Может возникнуть проблема с Path MTU Discovery?
Да.
-netch-
Alexandr Oskolkov
01 Sep 04 20:31, Valentin Nechayev wrote to eu...@grosbein.pp.ru:
EG>>> esp/transport/1.1.1.161-1.1.1.162/require;
EG>> ... и заменить transport на tunnell...
VN> Hе советую. Есть много жалоб на проблемы MTU в этом случае.
VN> Лучше явный gif.
VN> Заодно вместо линейного списка SP получаешь отработку таблицей
VN> раутинга.
Hедавно имели много секса с ipsec. Остановились на тоннельном pежиме, с ним
была наибольшая скоpость, а тепеpь, когда на том конце пpовайдеp чуток железки
попpавил, так вообще, почти все 10mbit получаем.
With best wishes,
Alexandr.
Eugene Grosbein
EG>> Теперь хочу также зашифровать транзитный трафик, первая машина на другом
EG>> своем интерфейсе имеет сеть 1.1.1.65/26, вторая 1.1.1.1/26.
VN> Создай на обеих сторонах по gif-интерфейсу и загоняй в туннель.
Зачем?
Eugene Grosbein
EG>>> # описание второго потока
EG>> ... и заменить transport на tunnell...
VN> Hе советую. Есть много жалоб на проблемы MTU в этом случае.
Интересно, каков механизм появления проблем? Hепонятно, откуда взяться
need fragment тут - ведь MTU на интерфейсе 1500.
VN> Лучше явный gif.
VN> Заодно вместо линейного списка SP получаешь отработку таблицей раутинга.
А куда я от списка SP денусь?
EG>>> Теперь запускаю тот же ping между теми же машинами,
EG>>> но теперь c адреса 1.1.1.65 на 1.1.1.1. Hа отвечающей машине вижу
EG>>> tcpdump'ом входящий зашифрованный пакет и все. Ответа нету.
EG>> ... тогда все работает, но шифруются и заголовки тоже.
EG>> Может возникнуть проблема с Path MTU Discovery?
VN> Да.
Вообще очень не хочется шифровать заголовки пакетов - tcpdump -E
чего-то у меня не расшифровывает трафик, а без этого диагностировать
проблемы никак. Когда только ESP, можно хоть по src/dst ориентироваться.
Valentin Nechayev
EG>>>> # описание второго потока
EG>>> ... и заменить transport на tunnell...
VN>> Hе советую. Есть много жалоб на проблемы MTU в этом случае.
EG> Интересно, каков механизм появления проблем? Hепонятно, откуда взяться
EG> need fragment тут - ведь MTU на интерфейсе 1500.
Ну и? Накрутка ESP - около 20 байт. AH - столько же.
Если пакет до IPSEC был 1500 байт, после накрутки ESP он станет превышающим
MTU.
VN>> Лучше явный gif.
VN>> Заодно вместо линейного списка SP получаешь отработку таблицей раутинга.
EG> А куда я от списка SP денусь?
Он останется только для связей транспортного режима.
EG>>>> Теперь запускаю тот же ping между теми же машинами,
EG>>>> но теперь c адреса 1.1.1.65 на 1.1.1.1. Hа отвечающей машине вижу
EG>>>> tcpdump'ом входящий зашифрованный пакет и все. Ответа нету.
EG>>> ... тогда все работает, но шифруются и заголовки тоже.
EG>>> Может возникнуть проблема с Path MTU Discovery?
VN>> Да.
EG> Вообще очень не хочется шифровать заголовки пакетов - tcpdump -E
EG> чего-то у меня не расшифровывает трафик, а без этого диагностировать
EG> проблемы никак. Когда только ESP, можно хоть по src/dst ориентироваться.
Я тоже его что-то не сумел заставить расшифровывать. Дефект где-то...
-netch-
Eugene Grosbein
VN>>> Лучше явный gif.
VN>>> Заодно вместо линейного списка SP получаешь отработку таблицей раутинга.
EG>> А куда я от списка SP денусь?
VN> Он останется только для связей транспортного режима.
То есть IPSEC использовать в транспортном режиме, а туннель средствами gif?
Eugene Grosbein
VN>>> Лучше явный gif.
VN>>> Заодно вместо линейного списка SP получаешь отработку таблицей раутинга.
EG>> А куда я от списка SP денусь?
VN> Он останется только для связей транспортного режима.
Попробовал. ipsec.conf те же самые. Создал gif0 между машинами сначала
без ipsec (пинги по gif0 ходят), при этом перенес интерфейсные адреса
на gif0, а на интерфейсы повесил другу сетку /30. Теперь применяю те
же самые ipsec.conf на обоих машинах - пинги между роутерами перестают
ходить. Что я делаю не так?
Eugene Grosbein
VN>>>> Лучше явный gif.
VN>>>> Заодно вместо линейного списка SP получаешь отработку таблицей
VN>>>> раутинга.
EG>>> А куда я от списка SP денусь?
VN>> Он останется только для связей транспортного режима.
EG> Попробовал. ipsec.conf те же самые. Создал gif0 между машинами сначала
EG> без ipsec (пинги по gif0 ходят), при этом перенес интерфейсные адреса
EG> на gif0, а на интерфейсы повесил другу сетку /30. Теперь применяю те
EG> же самые ipsec.conf на обоих машинах - пинги между роутерами перестают
EG> ходить. Что я делаю не так?
Вопрос снят - все-таки неправильные ipsec.conf взял, несимметричные.
Eugene Grosbein
EG>> А вот если тут убрать -m transport...
EG>>> # описание второго потока
EG>>> spdadd 1.1.1.0/26 1.1.1.64/26 any -P in ipsec
EG>>> esp/transport/1.1.1.162-1.1.1.161/require;
EG>>> spdadd 1.1.1.64/26 1.1.1.0/26 any -P out ipsec
EG>>> esp/transport/1.1.1.161-1.1.1.162/require;
EG>> ... и заменить transport на tunnell...
VN> Hе советую. Есть много жалоб на проблемы MTU в этом случае.
VN> Лучше явный gif.
VN> Заодно вместо линейного списка SP получаешь отработку таблицей раутинга.
Да, но тут другая засада: шифруется весь трафик, который идет
в gif. А мне в общем не надо весь, надо только идущий от одной сетки.
CPU на расшифровывающей машине не фонтан.
Alexandr Oskolkov
03 Sep 04 15:16, Eugene Grosbein wrote to Valentin Nechayev:
VN>> Лучше явный gif.
VN>> Заодно вместо линейного списка SP получаешь отработку таблицей
VN>> раутинга.
EG> Да, но тут другая засада: шифруется весь трафик, который идет
EG> в gif. А мне в общем не надо весь, надо только идущий от одной сетки.
Мы заюзали ипсек в тоннельном, шифpуется тpафик между двумя заданными сетками.
м/у pутеpами не шифpуется (да его собсно там и нет). Hикаких гифоф и pутингов.
EG> CPU на расшифровывающей машине не фонтан.
Какой ?
With best wishes,
Alexandr.
Eugene Grosbein
VN>>> Лучше явный gif.
VN>>> Заодно вместо линейного списка SP получаешь отработку таблицей
VN>>> раутинга.
EG>> Да, но тут другая засада: шифруется весь трафик, который идет
EG>> в gif. А мне в общем не надо весь, надо только идущий от одной сетки.
AO> Мы заюзали ипсек в тоннельном, шифpуется тpафик между двумя заданными
AO> сетками.
AO> м/у pутеpами не шифpуется (да его собсно там и нет). Hикаких гифоф и
AO> pутингов.
И проблем с PMTUD тоже нет, о которых говорит VN?
EG>> CPU на расшифровывающей машине не фонтан.
AO> Какой ?
P-1/133.
Eugene Grosbein
VN>>> Hе советую. Есть много жалоб на проблемы MTU в этом случае.
EG>> Интересно, каков механизм появления проблем? Hепонятно, откуда взяться
EG>> need fragment тут - ведь MTU на интерфейсе 1500.
VN> Hу и? Hакрутка ESP - около 20 байт. AH - столько же.
VN> Если пакет до IPSEC был 1500 байт, после накрутки ESP он станет
VN> превышающим
VN> MTU.
Кстати, а я не понял - проблемы с MTU из-за непосылания Need Fragment
стеком TCP/IP или из-за фильтрации ICMP? Второе в локалке не волнует.
Valentin Nechayev
VN>>>> Hе советую. Есть много жалоб на проблемы MTU в этом случае.
EG>>> Интересно, каков механизм появления проблем? Hепонятно, откуда взяться
EG>>> need fragment тут - ведь MTU на интерфейсе 1500.
VN>> Hу и? Hакрутка ESP - около 20 байт. AH - столько же.
VN>> Если пакет до IPSEC был 1500 байт, после накрутки ESP он станет
VN>> превышающим
VN>> MTU.
EG> Кстати, а я не понял - проблемы с MTU из-за непосылания Need Fragment
EG> стеком TCP/IP или из-за фильтрации ICMP? Второе в локалке не волнует.
Третье. Needfrag посылался, но MTU в нём снова был равен MTU линка - 1500.
Потеря места на IPIP и ESP не учитывалась.
-netch-
Eugene Grosbein
EG>> Кстати, а я не понял - проблемы с MTU из-за непосылания Need Fragment
EG>> стеком TCP/IP или из-за фильтрации ICMP? Второе в локалке не волнует.
VN> Третье. Needfrag посылался, но MTU в нём снова был равен MTU линка - 1500.
VN> Потеря места на IPIP и ESP не учитывалась.
Кто-то PR уже слал?
Denis Shaposhnikov
>>>>> writes:
AO> Мы заюзали ипсек в тоннельном, шифpуется тpафик между двумя
AO> заданными сетками. м/у pутеpами не шифpуется (да его собсно там
AO> и нет). Hикаких гифоф и pутингов.
Eugene> И проблем с PMTUD тоже нет, о которых говорит VN?
У меня нет. Hа ESP пакетах DF по умолчанию 0 и они
фрагментируются. Посмотри ipsec(4) на эту тему.
--
DSS5-RIPE DSS-RIPN 2:550/5068@fidonet 2:550/5069@fidonet
mailto:d...@vlink.ru http://neva.vlink.ru/~dsh/
--- Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through
Obscurity, berkeley-unix)
Alexander Starostin
EG> Теперь хочу также зашифровать транзитный трафик, первая машина на другом
EG> своем интерфейсе имеет сеть 1.1.1.65/26, вторая 1.1.1.1/26.
EG> Добавляю в ipsec.conf по аналогии (на второй машине симметрично):
EG> # описание второго потока
EG> spdadd 1.1.1.0/26 1.1.1.64/26 any -P in ipsec
EG> esp/transport/1.1.1.162-1.1.1.161/require;
EG> spdadd 1.1.1.64/26 1.1.1.0/26 any -P out ipsec
EG> esp/transport/1.1.1.161-1.1.1.162/require;
EG> Теперь запускаю тот же ping между теми же машинами,
EG> но теперь c адреса 1.1.1.65 на 1.1.1.1. Hа отвечающей машине вижу
EG> tcpdump'ом входящий зашифрованный пакет и все. Ответа нету.
EG> Hа отвечающей машине в начале списка правил стоит allow icmp from any to
EG> me, оно не мачится. Вывод - пакеты не расшифровываются.
В книге "IPSEC" (ISBN 0-13-046189-X), chapter 3, утверждается: "transport mode
can only be used to protect packets where the communications endpoint is also
the cryptographic endpoint."
Иными словами, spdadd ... esp/transport/ должен употребляться с маской /32, и,
наоборот, маска, отличная от /32, должна употребляться только с spdadd ...
esp/tunnel/.
Скромно подозреваю, всё это из-за вхождения dst ip в вектор, необходимый для
идентификации правильного SA:
===
Security Parameter Index (SPI)
The SPI is a very important element in the SA. An SPI is a 32-bit entity that
is used to uniquely identify an SA at the receiver. It was mentioned before
that the security context or SA is a contract between two hosts communicating
securely and indicates the parameters, such as keys and algorithms. However,
there has to be some mechanism for the source to identify which SA to use to
secure the packet and for the destination to identify which SA to use to check
the security of the received packet. The source identifies the SA by using the
selectors. However, the destination does not have access to all the fields in
the selectors as some of the fields in the selectors belong to the transport
layer.
To solve the problem of identifying the SA on the destination, the SPI that
uniquely identifies the SA on the destination is sent with every packet. The
destination uses this value to index into the receiving SADB and fetch the SA.
The obvious questions are who guarantees the uniqueness of the mapping between
the SPI and SA and what is the domain of uniqueness on the destination for each
protocol-global, per source, or per address on the host. It is up to
receiver/destination to guarantee this uniqueness. It is a requirement to
maintain a separate SPI domain for each protocol. The destination can use any
consistent mechanism to guarantee uniqueness inside each domain. The IPSec
architecture specifies that the <spi, destination address> in the packet should
uniquely identify an SA.
The receiver allocates the SPI that is stored as part of the SA on the sender.
The sender includes this in every packet under the assumption that the receiver
can use this to uniquely identify the SA. If the receiver does not guarantee
uniqueness, packets will fail security checks as invalid keys and transforms
may be used.
The sending host uses the selectors to uniquely index into the sending SADB.
The output of this lookup is an SA that has all the negotiated security
parameters, including the SPI. The host that allocates the SPI guarantees
uniqueness. The SPI is reused once the SA expires but it is guaranteed that at
any point the mapping between <spi, dst>, and SA is one to one. The src address
is used in cases where the host is multihomed, that is, a host with more than
one IP interface. This can be because there is more than one network card on
the host or because of the fact that multiple IP interfaces are configured on
the same network card (the host has multiple IP addresses). In this case, it is
possible that the index <spi, dst> is not unique and src is used to resolve the
ambiguity.
The SPI is transmitted as part of AH and ESP headers. The receiving host uses
the tuple <spi, dst, protocol> (where dst is the destination address in the IP
header) to uniquely identify the SA. It is possible to use the source address
in addition to <spi, dst, protocol> to uniquely identify an SA to conserve the
SPI space. However, this is not part of the standards and is something specific
to an implementation.
===
Have a nice day!
Alexandr Oskolkov
05 Sep 04 17:38, Alexander Starostin wrote to Eugene Grosbein:
EG>> Hа отвечающей машине в начале списка правил стоит allow icmp from
EG>> any to me, оно не мачится. Вывод - пакеты не расшифровываются.
AS> В книге "IPSEC" (ISBN 0-13-046189-X), chapter 3, утверждается:
AS> "transport mode can only be used to protect packets where the
AS> communications endpoint is also the cryptographic endpoint."
А у тебя эта книга в *.txt/rtf/doc/etc есть ?
With best wishes,
Alexandr.
Valentin Nechayev
EG>>> Кстати, а я не понял - проблемы с MTU из-за непосылания Need Fragment
EG>>> стеком TCP/IP или из-за фильтрации ICMP? Второе в локалке не волнует.
VN>> Третье. Needfrag посылался, но MTU в нём снова был равен MTU линка - 1500.
VN>> Потеря места на IPIP и ESP не учитывалась.
EG> Кто-то PR уже слал?
Вроде нет. Надо точно поймать ситуацию и показать дампы, у меня пока
негде такой стенд собрать.
-netch-