IPSec туннели, быстрый вопрос.

Хочу сказать, что это возможно… Кажется, я уже что-то подобное делал… Свяжитесь с Бутчем Эвансом. (посмотрите сайт консультантов) Мне кажется, у него может быть решение на его сайте. Крейг.

Спасибо, Женя! Думал, так и будет. Конечно, проверю dst-nat (это меня, кстати, тоже приходило в голову), но стараюсь минимизировать изменения конфигурации на удаленных концах. Придется еще и политики переключать с Tunnel encryption на Host encryption, потому что пир на 1.1.1.1 не знает о существовании 5.5.5.5… Ну, переделка знатная. Похоже, придется все пересмотреть.

Да, но проблема в том, что мне нужен туннель! 2 системы: 1.1.1.1, 1.1.1.2. Firewall: 1.1.1.3. Firewall выступает в роли IPSec-серверов, взаимодействуя с 2.2.0.1, 2.2.0.2, 2.2.0.3. Со своей стороны, я должен настроить туннель, если хочу зашифровать коммуникации между удалёнными узлами и 1.1.1.1, 1.1.1.2. .1 и .2 — это HA-кластер (например), один основной, один резервный. Имеет смысл завершать эти туннели на выделенном файерволе, поскольку это означает меньше конфигураций и значительно меньшую нагрузку на серверы, так как шифрование переносится на них. Вопрос теперь в том, что произойдёт, если у 2 и более удалённых пиров есть частная LAN за файерволом (что мне нужно учесть в конфигурации туннеля), с дублирующимися IP-адресами. Если я использую dst-nat на удалённом узле, то мой IPSec-пир и мой туннельный пир будут иметь один и тот же адрес... Это значит транспорт, а не туннель. В общем, я в заднице, как я вижу это. С транспортом я не смогу настроить конфигурацию на IPSec-сервере, а с туннелем у меня есть потенциал столкнуться с ошибками маршрутизации из-за дублирующихся IP-адресов? Мне придётся придумать способ использовать транспорт между 1.1.1.1 и различными удалёнными узлами для использования nat, но это не зашифрует трафик между узлами, которые находятся за IPSec-пирами... Я немного не хватает опыта здесь, но не может ли TNAT в IPSec помочь здесь? Мне придётся почитать об этом, но если кто-то обладает знаниями…

Всё ещё есть проблема с потенциальным конфликтом, Юджин.

Удалённая заметка: 192.168.1.0/24, 99% будут использовать 192.168.1.1 в качестве шлюза по умолчанию, что означает, что это будет частный IP для dst-nat, и это не решает мою проблему, так как с dst-nat на частный IP частный IP всё равно будет более чем на одном удалённом узле (помни, у меня может не быть доступа или контроля над удалёнными узлами изначально).

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

Что касается транспорта, то, кажется, NAT-Traversal – единственный вариант. Тогда я смогу выполнить преобразование адреса внутри туннеля как часть шифрования, и это устранит конфликт на IPSec-серверах… По крайней мере, тогда данные будут зашифрованы в незащищённой сети (на удалённом конце). Но это оставляет ещё одну проблему: MT не поддерживает NATT, верно?