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

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

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

  • Статический IP-адрес сайта B (скажем, 12.345.67.89), который является IP-адресом, на который я могу пинговать
  • Маска подсети 30
  • Статический IP- адрес шлюза site-A (987.654.32.10)
  • Интерфейс e0/0

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

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

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

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

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

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

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

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

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

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

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

Источник

1 ответ

Решение

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

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

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

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

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

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

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

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

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

ДЛЯ ТУННЕЛЯ САМОГО:

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

ПОЛИТИКАМ:

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

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

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

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

FLORIDA SSG5 (та же нота, что и у Мичигана)

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

Все это говорит...

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

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

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

Источник
Другие вопросы по тегам