Есть два роутера на 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 -- "Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
01 сен 2004, среда, в 19:06 KRAST, 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?
Eugene -- "Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
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-интерфейсу и загоняй в туннель.
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?
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 получаем.
01 сен 2004, среда, в 19:30 KRAST, Valentin Nechayev написал(а):
EG>> Теперь хочу также зашифровать транзитный трафик, первая машина на другом EG>> своем интерфейсе имеет сеть 1.1.1.65/26, вторая 1.1.1.1/26. VN> Создай на обеих сторонах по gif-интерфейсу и загоняй в туннель.
Зачем?
Eugene -- "Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
01 сен 2004, среда, в 19:31 KRAST, Valentin Nechayev написал(а):
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 ориентироваться.
Eugene -- "Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
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 ориентироваться.
Я тоже его что-то не сумел заставить расшифровывать. Дефект где-то...
02 сен 2004, четверг, в 14:07 KRAST, Valentin Nechayev написал(а):
VN>>> Лучше явный gif. VN>>> Заодно вместо линейного списка SP получаешь отработку таблицей раутинга. EG>> А куда я от списка SP денусь? VN> Он останется только для связей транспортного режима.
То есть IPSEC использовать в транспортном режиме, а туннель средствами gif?
Eugene -- "Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
02 сен 2004, четверг, в 14:07 KRAST, Valentin Nechayev написал(а):
VN>>> Лучше явный gif. VN>>> Заодно вместо линейного списка SP получаешь отработку таблицей раутинга. EG>> А куда я от списка SP денусь? VN> Он останется только для связей транспортного режима.
Попробовал. ipsec.conf те же самые. Создал gif0 между машинами сначала без ipsec (пинги по gif0 ходят), при этом перенес интерфейсные адреса на gif0, а на интерфейсы повесил другу сетку /30. Теперь применяю те же самые ipsec.conf на обоих машинах - пинги между роутерами перестают ходить. Что я делаю не так?
Eugene -- "Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
03 сен 2004, пятница, в 15:31 KRAST, 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 -- "Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
01 сен 2004, среда, в 19:31 KRAST, Valentin Nechayev написал(а):
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 на расшифровывающей машине не фонтан.
Eugene -- "Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
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 на расшифровывающей машине не фонтан. Какой ?
03 сен 2004, пятница, в 20:32 KRAST, Alexandr Oskolkov написал(а):
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 -- "Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
02 сен 2004, четверг, в 14:07 KRAST, 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.
Кстати, а я не понял - проблемы с MTU из-за непосылания Need Fragment стеком TCP/IP или из-за фильтрации ICMP? Второе в локалке не волнует.
Eugene -- "Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
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 не учитывалась.
05 сен 2004, воскресенье, в 18:04 KRAST, Valentin Nechayev написал(а):
EG>> Кстати, а я не понял - проблемы с MTU из-за непосылания Need Fragment EG>> стеком TCP/IP или из-за фильтрации ICMP? Второе в локалке не волнует. VN> Третье. Needfrag посылался, но MTU в нём снова был равен MTU линка - 1500. VN> Потеря места на IPIP и ESP не учитывалась.
Кто-то PR уже слал?
Eugene -- "Люди забыли эту истину," - сказал Лис, - "но ты не забывай"
AO> Мы заюзали ипсек в тоннельном, шифpуется тpафик между двумя AO> заданными сетками. м/у pутеpами не шифpуется (да его собсно там AO> и нет). Hикаких гифоф и pутингов.
Eugene> И проблем с PMTUD тоже нет, о которых говорит VN?
У меня нет. Hа ESP пакетах DF по умолчанию 0 и они фрагментируются. Посмотри ipsec(4) на эту тему.
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. ===
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 есть ?
EG>>> Кстати, а я не понял - проблемы с MTU из-за непосылания Need Fragment EG>>> стеком TCP/IP или из-за фильтрации ICMP? Второе в локалке не волнует. VN>> Третье. Needfrag посылался, но MTU в нём снова был равен MTU линка - 1500. VN>> Потеря места на IPIP и ESP не учитывалась. EG> Кто-то PR уже слал?
Вроде нет. Надо точно поймать ситуацию и показать дампы, у меня пока негде такой стенд собрать.
