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

Маршрутизация OpenBSD: невозможно достичь шлюза из IF, настроенного на статический блок

При попытке настроить маршрутизатор OpenBSD я столкнулся с очевидной проблемой маршрутизации.

У меня есть машина 1U с 6 гигабитными сетевыми картами (em0-em5). Мой интернет-провайдер предоставил мне следующее:

xx.xx.97.246/28 static WAN IP.
xx.xx.97.241 default gateway address.
xx.xx.98.192/29 static block that is externally routed to via xx.xx.97.246

Это моя установка:

+-------------------+
|        em0        +----> ISP's gateway (xx.xx.97.241)
|    xx.xx.97.246   |
+-------------------+
|        em2        +----> DMZ network (xx.xx.98.194-198)
|  xx.xx.98.193/29  |
+-------------------+
|        em4        +----> LAN2 (172.16.1.0/24)
|     172.16.1.1    |      [NATs to xx.xx.97.246 address]
+-------------------+
|        em5        +----> LAN (192.168.1.0/24)
|    192.168.1.1    |      [NATs to xx.xx.97.246 address]
+-------------------+

Пересылка была включена в sysctl.conf.

С помощью этой настройки и некоторых основных правил PF я смог получить базовый доступ в Интернет из сетей LAN (em4 / 5), и я могу получить доступ к почтовым / DNS-серверам в сети DMZ из сетей LAN. Все идет нормально.

Проблема заключается в доступе к сети DMZ из Интернета и к любому узлу в сети DMZ, имеющему доступ к Интернету (для выполнения восходящего поиска DNS и т. Д.). Кажется, что нет возможности подключения к Интернету в любом направлении, когда сетевой адрес DMZ является конечной точкой.

Я могу пинговать xx.xx.97.246 Адрес WAN из сети DMZ, но я не могу пропинговать адрес шлюза ISP по умолчанию (xx.xx.97.241).

Я получаю странную трассировку при попытке трассировки из сети DMZ на IP-адрес WAN - он пропускает переход em2 и сообщает только IP-адрес WAN, как если бы это был следующий переход. Я могу отследить до em2 и получить его адрес в качестве следующего перехода, если я укажу адрес em2 в качестве адреса назначения. Несмотря на то, что я не могу пинговать или отследить адрес шлюза - я получаю сообщение «узел недоступен».

Вот что я пробовал до сих пор:

  1. Добавление статического маршрута из xx.xx.98.193 к WAN IP и получил "маршрут существует" нормально, имеет смысл. От отчаяния я попытался добавить маршрут из xx.xx.98.193 на адрес шлюза и получил "пункт назначения недоступен".

  2. Добавление xx.xx.98.193 в качестве IP-псевдонима em0 и изменив адрес em2 к xx.xx.98.194. Похоже, это не повлияло ни на что, кроме нарушения всей маршрутизации через шлюз.

  3. Отключил переключатель DMZ от em2 и подключен к ПК, настроенному на статический адрес xx.xx.98.194 затем отключил pf с помощью pfctl -d который, по сути, пропускает все и исключает pf из картины. Без изменений.

  4. Дважды проверил таблицу arp с помощью arp -a и видно, что em2 (это MAC) привязан к xx.xx.98.193 / 29. Также проверил таблицу маршрутизации с netstat -ranf inet и это показывает xx.xx.97.241 шлюз по умолчанию.

На данный момент я думаю, что это чисто проблема маршрутизации, особенно после выполнения шагов 3 и 4. Кстати, шаги 1 и 2 были отменены, и система перезагрузилась, чтобы вернуться к предыдущей конфигурации перед попыткой 3 и 4.

Я думал о наведении мостов em0 и em2 но это просто не кажется необходимым, поскольку все интерфейсы находятся на одной машине и один раз em2 пакет хоста попадает в маршрутизатор, таблица маршрутизации должна иметь путь к шлюзу по умолчанию.

Я также заметил странное сообщение arp, повторяющееся в /var/log/messages «попытка перезаписать постоянную запись xx.xx.98.193 на». Mac через arp был от шлюза провайдера xx.xx.97.241. Не уверен, нормальное ли это "болтовня" или симптом моей проблемы.

Заранее благодарим за то, что уделили время чтению и ответу,

Роб

ОБНОВИТЬ:

Вот моя таблица маршрутизации:

Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
default            xx.xx.97.241       UGS        4       54     -     8 em0  
127/8              127.0.0.1          UGRS       0        0 32768     8 lo0  
127.0.0.1          127.0.0.1          UHl        1        0 32768     1 lo0  
172.16.1/24        172.16.1.1         C          0        0     -     8 em4  
172.16.1.1         xx:xx:xx:xx:1b:60  HLl        0        0     -     1 lo0  
172.16.1.255       172.16.1.1         Hb         0        0     -     1 em4  
192.168.1/24       192.168.1.1        C          0        0     -     8 em5  
192.168.1.1        xx:xx:xx:xx:1b:61  HLl        0        0     -     1 lo0  
192.168.1.255      192.168.1.1        Hb         0        0     -     1 em5  
xx.xx.97.240/28    xx.xx.97.246       UC         1        0     -     8 em0  
xx.xx.97.241       xx:xx:xx:xx:fc:d4  UHLc       1        4     -     8 em0  
xx.xx.97.246       xx:xx:xx:xx:1b:5c  HLl        0        0     -     1 lo0  
xx.xx.97.255       xx.xx.97.246       UHb        0        0     -     1 em0  
xx.xx.98.192/29    xx.xx.98.193       UC         2        0     -     8 em2  
xx.xx.98.193       xx:xx:xx:xx:1b:5e  HLl        0        0     -     1 lo0  
xx.xx.98.195       xx:xx:xx:xx:d8:33  UHLc       0        4     -     8 em2  
xx.xx.98.197       link#3             UHLc       0        4     -     8 em2  
xx.xx.98.199       xx.xx.98.193       UHb        0        0     -     1 em2  
224/4              127.0.0.1          URS        0        0 32768     8 lo0 

Прошлой ночью перепробовал много конфигов (в первую очередь потому, что у меня заканчиваются идеи). Как и в предыдущих попытках, PF был отключен с помощью pfctl -d чтобы удалить его как переменную. Наверное, самая разумная попытка чего-то была такая:

  1. Отключили em4 и em5 (динамические сети) и удалили их файлы hostname.if из / etc, чтобы оставить только em0 и em2.
  2. Настроен em0 с xx.xx.98.193 адрес и em2 с xx.xx.98.194 адрес затем ПК, подключенный к em2 с участием xx.xx.98.195.

С этой конфигурацией с ПК я мог пинговать до адреса 194 (em2 IF), но не до адреса 193 (em0 IF). Из системы OpenBSD я мог пропинговать адреса 194 и 195.

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

Должно быть что-то глупое, чего мне здесь не хватает. Моя следующая безумная вещь, которую я хочу попробовать, - это включить / добавить журналы маршрутизации ядра и сравнить то, что выводится между успешной маршрутизацией между интерфейсами и между em0 / 2. Это будет ускоренный курс по сетевому стеку / ядру OpenBSD. : /

Разместите вывод netstat -ranf inet. Что произойдет, если вы отключите pf и выполните ping-команду в Интернете, которая, как известно, отвечает с помощью команды ping -I xx.xx.98.193? Я также считаю, что ваш интернет-провайдер предоставляет MAC-адрес для xx.xx.98.193 необычным - это наводит меня на мысль, что ваша проблема находится на стороне вашего интернет-провайдера.