Назад | Перейти на главную страницу

Настройка записи маршрутизации с помощью Juniper SSG 5 - LAN to LAN VPN

У меня двухчастный:
Вчера я настроил локальную сеть для локальной сети VPN (после этой статьи можжевельника kb), и она почти работала, поэтому я нашел другой руководство и прошел процесс создания записей маршрута для статических IP-адресов, после чего все стало работать нормально. Сегодня утром я встал, и он больше не работал.

При дальнейшем просмотре настроек я обнаружил, что мои записи маршрутизации выглядят не совсем правильно. На брандмауэре site-A я использовал настройки:

Я изменил эти настройки для сайта B, хотя подсеть сайта A другая.

Проблема в том, что маршруты придумывают разные IP / маска сети запись, где в настройках сайта-A статический IP-адрес сайта-B составляет 12.345.67.87. Точно так же настройки сайта B читают статический IP сайта A как: 987.654.32.08. Короче говоря, проблема в том, что две последние цифры IP-адреса на 2 меньше, чем я изначально ввел.

  1. Это нормально, что IP-адреса отображаются иначе?
  2. Есть ли у кого-нибудь предложения относительно того, почему мой VPN больше не работает?

Заметка
Используя только статью в базе знаний Juniper, я могу создать почти функциональную VPN, в которой оба брандмауэра сообщают об активном туннеле. Кроме того, мой DHCP-сервер (машина Windows) показывает записи для рабочих станций на сайте-B, но я не могу пинговать их, а также они не могут просматривать Интернет, пинговать меня или получать доступ к своим сетевым дискам (которые размещены на сайте-A).

Оба сайта используют межсетевой экран Juniper SSG5.

Заранее благодарю за любую помощь!

Изменить - предоставление дополнительной информации

С любого компьютера на сайте A я могу проверить связь с двумя частными IP-адресами, которые находятся на сайте B: 172.16.100.50, который является IP-адресом интерфейса для bgroup0 на брандмауэре сайта B, и 172.16.100.53, который является рабочей станцией, с которой сайт -B офис не может физически найти.

С любого компьютера на сайте B пинг частного IP-адреса на сайте A (172.16.10.12) не получает ответа.

При входе в любой брандмауэр через PuTTY я не могу выполнить эхо-запрос ни одного из IP-адресов локальной сети (например, пинг с сайта A на сайт B 172.16.100.56 и пинг с сайта B на сайт A 172.16.10.12), но я могу пинговать статические WAN IP-адреса каждого устройства.

Вторая статья, на которую я ссылаюсь, предполагает, что мне также нужно было создать маршруты для статических IP-адресов WAN, это адреса, на которые я ссылаюсь в своем OP. Сетевые маски, которые я использую, я получил от интернет-провайдеров каждого сайта. Сетевая маска сайта A - 29, сетевая маска сайта B - 30.

Разве я на днях не ответил на ваши вопросы по этому поводу? Вопрос был удален?

Созданные вами записи CIDR установят его таким образом из-за маски.

Если вы устанавливаете маску / 30, то технически первый (хотя второй октект недействителен) должен быть похож на:

12.0.67.88 - 12.0.67.91, с .88 в качестве маршрута / сети, .89 и .90 допустимые хосты и .91 широковещательный адрес.

Вам необходимо убедиться, что ваши подсети и записи маршрутизации соответствуют правильному разделению на подсети.

Вкратце для настройки VPN:

  1. Настройте туннель с двумя адресами WAN, настройками ike и т. Д.
  2. Настройте маршруты - каждая сторона должна иметь маршруты к удаленным подсетям LAN, при этом шлюз является туннелем.
  3. Политики должны быть настроены так, чтобы разрешать трафик из локальных подсетей LAN в удаленные подсети LAN и наоборот ... это должно выполняться с помощью FW.

РЕДАКТИРОВАТЬ:

Хорошо, посмотрев на диаграмму, я вижу:

ДЛЯ СЕБЯ ТУННЕЛЯ:

  • Выглядит нормально. На самом деле вам не нужны настройки идентификатора прокси (по крайней мере, похоже, у вас есть некоторые с локальным и удаленным диапазонами IP-адресов), но если вы это сделаете, это нормально.

ДЛЯ ПОЛИТИКИ:

  • У вас должно быть два набора политик: один для «ДОВЕРЯТЬ НЕ ДОВЕРИТЬ» и соответствующий двунаправленным политикам для «НЕ ДОВЕРЯТЬ ДОВЕРИЮ». Вы должны настроить элементы политики для двух локальных сетей на обоих брандмауэрах. Что-то вроде "LAN Флориды" = 172.16.100.0/24 и "LAN Мичигана" = 172.16.10.0/24.
  • Тогда политика на стороне Мичигана должна быть «ДОВЕРИТЬ НА НЕ ДОВЕРИТЬ» Источник = «Мичиганская LAN», Назначение «Флорида LAN», Сервис = ЛЮБОЙ, Действие = ТУННЕЛЬ, Туннель = «Флорида VPN», установите флажок «Соответствующая двунаправленная политика. ". Это должно создать политику ДОВЕРИЯ НЕ ДОВЕРИТЬ и НЕ ДОВЕРИТЬ ДОВЕРИТЬ на SSG5 штата Мичиган для туннелирования. Вы захотите создать то же самое на стороне Флориды, на этот раз с источником «LAN Флориды» и местом назначения «LAN Мичигана», но с тем же типом политики (действие = туннель, туннель = Michigan VPN)

ДЛЯ МАРШРУТОВ:

MICHIGAN SSG5 (примечание: я предполагаю, что у вас есть только одно соединение WAN, и что текущий маршрут по умолчанию 0.0.0.0 указывает на шлюз 108.245.51.86):

  • trust-vr должен иметь запись для локальной сети, чтобы знать, как к нему добраться. Убедитесь, что в записи протокола для этого 172.16.10.0/24 есть «172.16.10.0/24 со шлюзом 172.16.10.1» или, по крайней мере, «C», что означает подключенный.

FLORIDA SSG5 (то же примечание, что и мичиганский)

  • trust-vr должен иметь запись для локальной сети, чтобы знать, как к нему добраться. Убедитесь, что в записи протокола для этого 172.16.100.0/24 есть «172.16.100.0/24 со шлюзом 172.16.100.50» или, по крайней мере, «C», что означает, что он подключен.

Все сказанное ...

  1. Вам не нужны записи статической маршрутизации для ваших подключений к WAN ISP.

  2. Я думаю, ваша основная проблема сводится к тому, что ваша подсеть LAN во Флориде - 172.16.100.0/24, но ваш IP-адрес bgroup1 - 172.16.100.50, который находится в середине этой подсети, идеально было бы, чтобы это было 172.16.100.1, а не .50. На ОБЕИХ сторонах убедитесь, что выбран правильный шлюз по умолчанию для рабочих станций. На стороне Мичигана все они должны быть установлены на 172.16.10.1, а на стороне Флориды они должны быть установлены на 172.16.100.50.

Предполагая, что все записи vpn, политики и маршрутизации SSG5 верны, я держу пари, что проблема заключается именно здесь, со шлюзами по умолчанию на компьютерах.