Почему не возвращаются пакеты из одной из подсеток?

dimskraft

У меня pfSense подключен к нескольким провайдерам, два из которых имеют собственные модемы, которые на схеме обозначены router1 и router2

Находясь на машине myhost я НЕ могу пинговать router1 НО могу пинговать router2, хотя они настроены эквивалентно. Естественно, провайдером, который находится за router1, я пользоваться не могу, никакой трафик не проходит. Но в данном вопросе рассматриваются только пинги, потому что я свёл проблему к ним

В качестве эксперимента, я пингую один из модемов и, с помощью tcpdump наблюдают, как они ходят. И я вижу, что в подсетках соответствующих модемов присутствуют как запросы, так и ответы. Это означает, что на модемах все настроено нормально и они ведут себя адекватно.

Странное начинается когда я наблюдаю за LAN. В ней я вижу ответы только от одного из модемов.

Эксперимент 1

myhost> ping router1
<Вижу таймауты>

pfSense> tcpdump -n -i re1 icmp
<Вижу как запросы, так и ответы. Запросы исходят от 192.168.0.2, а ответы этому адресу направлены (работает NAT)>

pfSense> tcpdump -n -i re2 icmp
<Вижу только запросы, направленные 192.168.0.1>

Эксперимент 2

myhost> ping router2
<Пингуется нормально>

pfSense> tcpdump -n -i re3 icmp

<Вижу как запросы, так и ответы. Запросы исходят от 192.168.100.2, а ответы этому адресу направлены (работает NAT)>

pfSense> tcpdump -n -i re2 icmp
<Вижу как запросы, так и ответы>

Я не могу этого понять. Создается впечатление, что NAT дропает пакеты. Но я никак не могу увидеть, что именно это происходит и понять, почему это происходит. Я сто раз сверял конфигурации NAT, фаервола и прочие и не вижу ничего такого, что могло приводить к данным различиям.

Как можно диагностировать проблему?

Konstanti

@dimskraft

Здравствуйте

Отключите исходящий nAT на re1 и посмотрите , что будет
Главное , помните о том , чтобы router1 что-то знал о сети 10.0/24

Посмотрите журнал системный - нет ли ошибок драйвера ?
с Re бывают проблемы , описанные в документации
что будет , если поменять карту или провода местами
re1 и re3

dimskraft

@Konstanti я же вижу пакеты через tcpdump, разве это не означает, карта работает?

а где смотеть логи re1?

Konstanti

@dimskraft
Вы не показали ни одной настройки
Все предположения основаны только на Ваших словах
я просто предполагаю , как можно диагностировать проблему
Задам вопрос , почему Вы уверены , что видите icmp пакеты именно от хоста "myhost" после натирования?
Может быть, re1 проверяет канал связи ....
я бы , на Вашем месте , отключил нат для начала на интерфейсе re1 и посмотрел , что будет
у PF есть системный журнал событий , ошибки тоже туда "валятся" (по-моему , /status/system logs/

dimskraft

@Konstanti я отключил все мониторирование и добился того, чтобы с указанным фильтром tcpdump не показывал ничего

После чего наблюдаю совпадение по времени между запуском пинга и появлением выдачи tcpdump

Если нужны какие-то релевантные настройки то я их с удовольствием предоставлю.

Если я отключу NAT, то разве файервол что-то пропустит?

Konstanti

@dimskraft
По умолчанию , файрвол настроен так , что он обрабатывает только первый пакет , пришедший на любой из интерфейсов
Если этот первый пакет соответствует правилам файрвола , и он его пропускает , то это соединение заносится в таблицу состояний и больше не проверяется .
Таким образом , исходящий трафик , по умолчанию, не проверяется . И трафик обратный тоже не проверяется .
Если Вы отключите исходящий НАТ , и настроете router1 так , чтобы он знал про сеть 10.0/24

то Вы увидеть должны такую картину на интерфейсах re2 и re1
10.24->0.1 ( этот пакет проверяется файрволом)
0.1->10.24 ( этот и последующие уже нет)
.....

dimskraft

@Konstanti я отключил NAT

конкретно, я удалил все правила NAT имеющие отношение к провайдеру re1

в результате, я стал видеть в обоих подсетках (re2 и re1) только реквесты

при этом я вижу в подсетке re2 реквесты уже от myhost

в данном случае поведение правильное, так как router1 не знает маршрута к myhоst и, видимо, кидает ответы в глобальный интернет

Konstanti

@dimskraft

Если Вы отключите исходящий НАТ , и настроете router1 так , чтобы он знал , про сеть 10.0/24

то Вы увидеть должны такую картину на интерфейсах re2 и re1
10.24->0.1 ( этот пакет проверяется файрволом)
0.1->10.24 ( этот и последующие уже нет)

посмотрите вывод команды

dmesg | grep re1
dmesg | grep re2

dimskraft

@Konstanti я не вижу, как заставить router1 отвечать на запрос, пришедший от 192.168.10.24, в нужном направлении

Konstanti

@dimskraft
Здесь я бессилен , потому что не знаю , что такое router1 (что это за устройство) , и как у него производится настройка статических маршрутов

dimskraft

@Konstanti в dmesg я не вижу "криминала"

...
re1: <RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet> port 0xb000-0xb0ff mem 0xe3100000-0xe3100fff,0xe3200000-0xe3203fff irq 16 at device 0.0 on pci2
re1: Using 1 MSI-X message
re1: Chip rev. 0x2c000000
re1: MAC rev. 0x00200000
miibus1: <MII bus> on re1
re1: Using defaults for TSO: 65518/35/2048
re1: Ethernet address: ff:de:27:01:da:c1
re1: netmap queues/slots: TX 1/256, RX 1/256
re1: link state changed to DOWN
re1: link state changed to UP
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: link state changed to DOWN
re1: link state changed to UP
re1: link state changed to DOWN
re1: link state changed to UP
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled
re1: promiscuous mode enabled
re1: promiscuous mode disabled

UP/DOWN это я перетыкал провод

Konstanti

@dimskraft
а если поменять местами re1 и re3 ( включить NAt) , ситуация как-нибудь изменится ? настройки , соответственно тоже поменять

dimskraft

@Konstanti скорее всего этой функии там нет

Что Вы ожидатете от этого эксперимента?

Допустим, реплаи при выключенном NAT будут проходить. Что это будет значить?

Допустим, реплаи при выключенном NAT проходить все равно не будут. Что это будет означать?

dimskraft

@Konstanti я хотел приступить к таким экспериментам как можно позже; неужели нельзя отдиагностировать ситуацию программными средствами?

может быть так, что какие-то новые примочки Роскомнадзора каким-то образом "портят" пакеты, чтобы они далеко не ходили?

может быть так, что pfSense криво встала и криво обновилась и какой-то драйвер не подгружается?

Konstanti

@dimskraft
1 если бы PF встала криво , у Вас были бы ошибки драйвера, и интерфейс не поднимался бы
2 каким образом РКН может портить пакеты , когда у Вас прямая связь между устройствами . Или это не так ? и у Вас VPN ?

dimskraft

@Konstanti устройство стоит у меня, но провайдер имеет к нему доступ и может там прошить что угодно

Konstanti

@dimskraft
Никто не будет вам "прошивать" как-то устройство . Системы DPI стоят на площадках провайдера и работают параллельно с основным устройством.
У меня внутри РФ все работает хорошо

По Вашей проблеме - я пока ни разу не видел проблем с НАТом
Все работает четко и как надо

Нет ли у Вас случайно Floating правил ?

dimskraft

@Konstanti в том-то и дело, что все работает чётко, кроме НАТа в одной из подсеток

и не получается понять, почему

нет Floating правил нет

dimskraft

@Konstanti

проблема видна и в таблице стейтов

Konstanti

@dimskraft
а что такое 192.168.1.1 ?

покажите вывод команды

ifconfig -m re1
ifconfig -m re2
ifconfig -m re3

В документации рекомендуют еще отключить аппаратный расчет контрольных сумм пакетов , в частности , эта рекомендация относится к Realtek.

Checksum offloading is broken in some hardware, particularly some Realtek cards. Rarely, drivers may have problems with checksum offloading and some specific NICs. This will take effect after a machine reboot or re-configure of each interface.