https://slinkov.ru/openforum/vsluhforumID3/2620.html Обсуждение статьи тематического каталога: Создание VPN во FreeBSD на базе IPSEC и racoon (freebsd ipsec vpn racoon security tunnel)<br><br>Ссылка на текст статьи: http://www.opennet.ru/base/net/vpn_ipsec_racoon.txt.html<br><br> https://slinkov.ru/openforum/vsluhforumID3/2620.html#30 Tue, 28 Aug 2007 00:44:19 GMT ну вопервых заменить фразу support_mip6 на support_proxy <br>ну и конечно exchange_mode main; или exchange_mode aggressive; в секцию remote XXX<br> https://slinkov.ru/openforum/vsluhforumID3/2620.html#29 Sat, 11 Aug 2007 18:45:06 GMT racoon -F<br>Foreground mode.<br>2007-08-11 22:32:07: INFO: @(#)ipsec-tools 0.6.7 (http://ipsec-tools.sourceforge<br>.net)<br>2007-08-11 22:32:07: INFO: @(#)This product linked OpenSSL 0.9.7e-p1 25 Oct 2004<br> (http://www.openssl.org/)<br>2007-08-11 22:32:07: WARNING: /usr/local/etc/racoon/racoon.conf:65: "support_mip<br>6" it is obsoleted. use "support_proxy".<br>2007-08-11 22:32:07: ERROR: /usr/local/etc/racoon/racoon.conf:74: "}" no exchang<br>e mode specified.<br><br>2007-08-11 22:32:07: ERROR: fatal parse failure (1 errors)<br>racoon: failed to parse configuration file.<br><br>видимо, много чего нового появилось и удалилось. Люди. Что racoon.conf нужно поменять?<br> https://slinkov.ru/openforum/vsluhforumID3/2620.html#28 Fri, 10 Aug 2007 15:58:51 GMT Кто-нибудь делал такую конфу, но из трех сетей, вместо двух, как здесь?<br><br>Отличий много?<br> https://slinkov.ru/openforum/vsluhforumID3/2620.html#27 Sat, 23 Jun 2007 15:56:53 GMT а как быть, если FreeBSD находится за NAT ? что-то у меня не поехало никак это дело... https://slinkov.ru/openforum/vsluhforumID3/2620.html#26 Mon, 25 Sep 2006 11:00:32 GMT а как быть с racoon2? синтаксис тот же? https://slinkov.ru/openforum/vsluhforumID3/2620.html#25 Sun, 15 Aug 2004 13:08:05 GMT &gt;так жеж нельзя <br>&gt;ты предлагаешь защищать транспортом траффик между маршрутизаторными внутренними интерфейсами ? если я <br>&gt;правильно понял ... <br>Нет, внешними, конечно. Внутренними - или работать вообще не будет, или как гланды автогеном вырезать :)<br><br>&gt;если использовать транспортный режим, то правильнее всего шифровать протокол инкапсуляции между внешними <br>&gt;интерфейсами (х.х.х.х у.у.у.у) <br>Кто бы спорил - я не буду :)<br><br>&gt;(если зашифруешь весь, то ракун не сможет инициировать обмен ключами, если скажешь <br>&gt;не шифровать трафик ракунов, то ракуну будет тяжело понять какую из <br>&gt;записей СПД брать и т.д.) <br><br>Ну, у меня ISAKMP демоны и так договаривались (за счёт use вместо<br>require). Хотя исключить из шифрования порты 22, 443, 500 и прочих отдельными SP перед основным - действительно полезная настройка.<br> https://slinkov.ru/openforum/vsluhforumID3/2620.html#24 Sun, 15 Aug 2004 04:33:48 GMT ты чего ?<br>думаешь о чем ? о настройке ИПСЕКА или защите сети ?<br><br>так жеж нельзя<br>ты предлагаешь защищать транспортом траффик между маршрутизаторными внутренними интерфейсами ? если я правильно понял ...<br><br>так нельзя делать<br>в инете будет видно, твою внутреннюю сеть, потому что в гиф0 будет инкапсулирован внутренний пакет , а потом его тело зашифровано, но заголовок его будет виден !!!<br><br>если использовать транспортный режим, то правильнее всего шифровать протокол инкапсуляции между внешними интерфейсами (х.х.х.х у.у.у.у)<br><br>(если зашифруешь весь, то ракун не сможет инициировать обмен ключами, если скажешь не шифровать трафик ракунов, то ракуну будет тяжело понять какую из записей СПД брать и т.д.)<br> https://slinkov.ru/openforum/vsluhforumID3/2620.html#23 Tue, 20 Jul 2004 07:06:26 GMT Вроде все. Осталось только заметить, что racoon теряет память и при длительной работе его не мешало бы подпереть перезапускалкой и ulimit'ами.;)) Но на пару статических линков и средний аптайм железки в несколько месяцев это не страшно. <br> <br>Sorry за некоторый сумбур изложения. И просьба к вебмастерам - сделать постинг как-то более разумно, чем передавать весь текст комментария в URL'е. ;( https://slinkov.ru/openforum/vsluhforumID3/2620.html#22 Tue, 20 Jul 2004 07:03:32 GMT Поэтому, рекомендуемый вариант будет следующий: поставить gif точно так же как в статье, обмен ключами - точно так же, но правила в SPD заменить на следующие (для первого шлюза; для второго - аналогично): <br> <br>spdadd 10.1.1.1 10.1.2.1 any -P out ipsec esp/transport//require; <br>spdadd 10.1.2.1 10.1.1.1 any -P in ipsec esp/transport//require; <br> <br>С точки зрения формата и содержимого пакетов вообще ничего не поменяется (так что менять можно даже на одной из сторон;)), но будет меньше проблем с MTU. Проблема с MTU будет решаться в драйвере gif (который на порядок более прозрачен и в котором это решено), остаётся только выставить там разумное MTU (например, 1440). Другое преимущество этого варианта - возможность поддержки динамического раутинга дополнительных сетей (средствами zebra/quagga/gated