При попытке настроить маршрутизатор 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 в качестве адреса назначения. Несмотря на то, что я не могу пинговать или отследить адрес шлюза - я получаю сообщение «узел недоступен».
Вот что я пробовал до сих пор:
Добавление статического маршрута из xx.xx.98.193
к WAN IP и получил "маршрут существует" нормально, имеет смысл. От отчаяния я попытался добавить маршрут из xx.xx.98.193
на адрес шлюза и получил "пункт назначения недоступен".
Добавление xx.xx.98.193
в качестве IP-псевдонима em0 и изменив адрес em2
к xx.xx.98.194
. Похоже, это не повлияло ни на что, кроме нарушения всей маршрутизации через шлюз.
Отключил переключатель DMZ от em2
и подключен к ПК, настроенному на статический адрес xx.xx.98.194
затем отключил pf с помощью pfctl -d
который, по сути, пропускает все и исключает pf из картины. Без изменений.
Дважды проверил таблицу 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
чтобы удалить его как переменную. Наверное, самая разумная попытка чего-то была такая:
em0
и em2
.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 необычным - это наводит меня на мысль, что ваша проблема находится на стороне вашего интернет-провайдера.