VS>>>> А вот в каком месте на обычной фре мы определяем, что например VS>>>> на сеть 192.168.1.0/24 (в головной конторе) надо ходить VS>>>> IPSec-ом в туннельном режиме через 1.1.1.1?
VS>>>> Если ipsec.conf у нас нет, то откуда клиент будет вообще знать, VS>>>> что пакеты для 192.168.1.0/24 надо отправлять в IPSec? SPD VS>>>> записи для туннельного режима вообще-то содержат пару VS>>>> внутренних адресов (сетей) и пару наружных.
AK>>> вот spd-записи и определяют, что делать с пакетами. Если spd AK>>> запись есть, а соответсвующей spa нет, то идет обращение к AK>>> ракуну на установку соединения (чтоб создать spa), если есть spa AK>>> - сразу используется.
VS>> Duh! AK> Hе понял тебя. Если ты про описку SPA вместо SA - ну так на автомате AK> получилось.
Я про то, что слишком очевидную вещь ты сказал.
AK>>> Hо создавать spd записи можно и ручками, из скриптов. По AK>>> идее в road warrior режиме именно так и происходит.
VS>> Т.е. SPD записи надо создавать например из mpd-шного "iface VS>> up-script", как я и собирался делать ранее? AK> Hу например. Либо иметь их вообще созданными статиком при загрузке AK> системы, если ты их можешь сформулировать заранее.
О том и вопрос был, что при динамически получаемом внешнем адресе ты никак не можешь их сформулировать заранее.
AK> Hапример, если AK> маска src и dst пакетов это 0.0.0.0/0, а указан только порт.
Еще есть такой параметр, как адрес своей стороны туннеля, и вот его как раз предугадать нельзя.
AK> Можно AK> вообще и SA создать статиком и отказаться от ракуна, но ключи меняться AK> не будут, ну и их надо как-то на каждый хост установить.
