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

pfSense - Трафик в подсеть не маршрутизируется статическим маршрутом

Версия pfSense: 2.3.4-РЕЛИЗ

Недавно мы перешли с межсетевого экрана WatchGuard на использование pfSense. У нас почти все работает так, как мы хотим, но есть одна мелочь, с которой мы не можем заставить работать. По сути, у нас есть два сетевых сегмента: один для наших компьютеров и один для нашей телефонной системы. Каждый из них находится в своей собственной подсети, входящей в маршрутизатор pfSense на разных интерфейсах. Мы хотели бы иметь возможность управлять нашей телефонной системой в «сегменте телефонов» с клиентских компьютеров в «компьютерном сегменте».

Раньше в конфигурации WatchGuard у нас был настроен статический маршрут, который сообщал маршрутизатору, как маршрутизировать между различными подсетями. Я пытаюсь настроить что-то подобное на роутере pfSense, используя шлюзы и статические маршруты.

Вот несколько примеров того, что мы хотели бы сделать:

У нас настроены, протестированы и работают следующие интерфейсы:

У нас настроен, протестирован и работает следующий шлюз:

У нас настроен, протестирован и работает следующий статический маршрут:

Телефонный сегмент был открыт некоторое время назад продавцом. Я не знаю, почему они решили создать две разные подсети (подсеть 10.18.0.0/16 и подсеть 10.1.10.1/30). Я бы предпочел все на одном, но я не эксперт в решениях VoIP, и система настроена и работает, поэтому я не видел причин менять ее.

С клиента в "компьютерном сегменте" я могу пинговать и просматривать (с помощью веб-браузера) 10.1.10.1 и 10.18.1.3. Оба они физически находятся на устройстве UC500. Я не могу пинговать или перейти к 10.18.1.4, который является веб-интерфейсом управления коммутатором.

Из чтения, которое я сделал о статических маршрутах с pfSense, было сказано, что «Не нужно добавлять маршруты для сетей, которые напрямую подключены к какому-либо интерфейсу межсетевого экрана ...». Поскольку IP-адрес веб-сайта управления интеллектуальным коммутатором - 10.18.1.4/16, а кабель для интерфейса OPT1PHONE подключен непосредственно к интеллектуальному коммутатору, я бы подумал, что маршрутизация должна работать только с тем, что мы уже настроили. Однако по какой-то причине это не так. Итак, чтобы попытаться заставить это работать, я подумал, что это будет так же просто, как добавить статический маршрут для адреса 10.18.1.4. Вот как я это настроил:

Network: 10.18.1.0/24 Gateway: PhoneGW Interface: Opt1Phone

Я пытался использовать 10.18.1.1/16 в качестве сети для маршрута, но pfSense не позволяет мне это сделать, поскольку эта подсеть уже используется для интерфейса. Это имеет смысл (см. Мой пункт выше о том, как должна работать маршрутизация), но поскольку маршрутизация не работает без статического маршрута, я подумал, что смогу заставить pfSense распознавать маршрут с помощью этого статического маршрута. Поскольку это тоже не работает, я думаю, это неправильный способ.

Статические маршруты - правильный способ сделать это с помощью pfSense? Я знаю, что что-то упускаю, но не могу понять, что именно. Если бы кто-нибудь мог указать мне правильное направление, я был бы очень признателен.

Вот простая сетевая диаграмма:

Вот обрезанная распечатка маршрутизатора pfSense маршрутов, которые в настоящее время работают:

Destination    Gateway    Flags    Use    Mtu    Netif    Expire
===========    =======    ======   ===    ===    =====    ======
10.1.10.0/30   10.18.1.1  UGS      307    1500   igb2
10.17.0.0/16   link#1     U        6293358 1500  igb0
10.17.1.1      link#1     UHS      0      16384  lo0
10.18.0.0/16   link#3     U        6      1500   igb2
10.18.1.1      link#3     UHS      279582 16384  lo0

Вот обрезанная распечатка маршрутизатора pfSense маршрутов, настроенных с моим тестовым статическим маршрутом:

Destination    Gateway    Flags    Use    Mtu    Netif    Expire
===========    =======    ======   ===    ===    =====    ======
10.1.10.0/30   10.18.1.1  UGS      307    1500   igb2
10.17.0.0/16   link#1     U        6293358 1500  igb0
10.17.1.1      link#1     UHS      0      16384  lo0
10.18.0.0/16   link#3     U        6      1500   igb2
10.18.1.0/24   10.18.1.1  UGS      28     1500   igb2
10.18.1.1      link#3     UHS      279582 16384  lo0

Я пробовал выполнить пинг с маршрутизатора pfSense, чтобы узнать, где прерывается связь:

Судя по таблице маршрутизации без тестового статического маршрута, маршрутизатор должен знать, как перейти из подсети 10.17.0.0/16 в подсеть 10.18.0.0/16. Обе подсети имеют правильный шлюз, и эхо-запросы (по большей части) подтверждают это. Даже статический маршрут к сети 10.1.10.0/30, имеющей шлюз 10.18.1.1, работает правильно. Я бы подумал, что я должен иметь возможность пинговать и просматривать веб-интерфейс по адресу 10.18.1.4/16, поскольку маршрутизатор знает о подсети 10.18.0.0/16 и о том, на каком интерфейсе она находится. Однако по какой-то причине это не работает.

Если вы можете получить доступ (ping) к управляющему IP-адресу из pfsense, но не из компьютерного сегмента, было бы проще всего добавить опцию гибридного NAT в pfsense примерно так: (переключите GUEST для Opt1Phone), скорее всего, это устройство, на котором вы попытка доступа не имеет обратного маршрута.

Для сетей с прямым подключением статический маршрут не требуется.

Ваша установка слишком велика / сложна, чтобы уместиться в моей голове. Может быть, ты тоже. Итак, как мне решить проблему? Может, рассказываю, поможет тебе.

У вас есть две фундаментальные инженерные проблемы:

  1. вы не знаете, почему ваша текущая установка работает так, как она
  2. вы хотите, чтобы ваша система работала так, как вы хотите

Чтобы решить (1.), вам необходимо разобраться в своей системе. Что есть понимание? Понимание означает, что у вас есть ментальная модель, соответствующая реальности. Как убедиться, что это соответствует действительности? Вы берете свою ментальную модель и предсказываете, как система будет вести себя при определенных условиях. Затем вы фактически переводите систему в эти условия и мера. Затем вы сравниваете измерения с вашими прогнозами. Идентичны ли измерения и прогноз?

Если да: идеально, ваша ментальная модель верна. Чем больше независимых прогнозов вы сможете проверить, тем увереннее вы будете в правильности своей ментальной модели.

Если нет: ваша ментальная модель неверна. Вам нужно исправить вашу модель. Имея размеры, можете ли вы адаптировать вашу модель к измерению?

Чтобы опровергнуть это: если вы думаете, что правильно настроили свою сеть, то как она должна действовать? Как это измерить?

Мои основные инструменты сетевой инженерии: ping, traceroute и tcpdump(также известный как захват пакетов). Таким образом, пакеты должны исходить из этого интерфейса здесь. Они? Подключите свой ноутбук к интерфейсу C1 и выполните эхо-запрос от C1 до R и tcpdump что выходит из C1. Часто сетевое оборудование имеет собственные инструменты захвата пакетов, поэтому вы можете захватывать пакеты там (например, на следующем коммутаторе в очереди) без необходимости выдергивать кабели и подключать их к ноутбуку.

Переходим к (2.). У вас есть цель, которую трудно / сложно достичь. Чем ты занимаешься? Вы разделяете и побеждаете. Также вы сводите проблему к частям. Затем вы реализуете одну часть за другой, а затем шаг за шагом соединяете их вместе, одну за другой. И вы проверяете правильность своих прогнозов на каждом этапе.

Что касается вашей проблемы, допустим, вы хотите иметь такую ​​сеть:

C1 - N1 - R - N2 - C2

где R - маршрутизатор, N1 и N2 - сети, а C1 и C2 - клиенты. Вы хотите, чтобы С1 мог общаться с С2. Хорошо, давайте уменьшим проблему:

  1. C1 должен иметь возможность общаться с R
  2. то же самое для C2
  3. R необходимо пересылать пакеты

Мы можем еще больше уменьшить это. Мы сокращаем (1.):

  • а. C1 должен иметь возможность отправлять пакеты в R
  • б. R должен иметь возможность отправлять пакеты в C1

Мы можем уменьшить файл. (и б.) далее:

  1. C1 должен знать, куда отправлять пакеты для R (какой из них является следующим узлом, на который C1 должен отправлять пакеты, которые должны достичь R, или какой интерфейс, в который C1 должен отбрасывать пакеты, предназначенные для R?)
  2. R должен уметь распознавать и принимать пакеты, предназначенные для него.

И так далее. Каждый из приведенных выше пунктов - это гипотеза, которую вы делаете, уменьшая проблему. Что вы делаете, так это приводите свою систему в соответствие с условиями, необходимыми для выполнения вашего прогноза, полученного на основе вашей модели. То есть: если я настрою интерфейс C1 таким образом и R таким образом, то C1 сможет пинговать R. Хорошо, давайте настроим нашу систему сейчас, как я думаю, это правильно. А теперь примерим. Пинг работает? Если нет, то какие пакеты я вижу на проводе? Какие пакеты показывает мне tcpdump на R. И т.п.

Так я бы и поступил. Я бы разделил все это на мелкие части и убедился, что каждая часть работает так, как задумано, и будет измерять (tcpdump) в каждой точке, если что-то не работает должным образом.

Насколько я понимаю ваш сценарий. Все ваши клиенты подключены к LAN 10.17.0.0/16 и ко всем другим коммутаторам в Opt1Phone 10.18.0.0/16. Приведенные ниже статические маршруты должны работать для вас. попробуйте.

Network: 10.18.0.0/16 Gateway: PhoneGW Interface: Opt1Phone
Network: 10.1.10.1/30 Gateway: PhoneGW Interface: Opt1Phone