Почему не возвращаются пакеты из одной из подсеток?
-
Здравствуйте
Отключите исходящий nAT на re1 и посмотрите , что будет
Главное , помните о том , чтобы router1 что-то знал о сети 10.0/24- Посмотрите журнал системный - нет ли ошибок драйвера ?
с Re бывают проблемы , описанные в документации
что будет , если поменять карту или провода местами
re1 и re3
- Посмотрите журнал системный - нет ли ошибок драйвера ?
-
@Konstanti я же вижу пакеты через tcpdump, разве это не означает, карта работает?
а где смотеть логи re1?
-
@dimskraft
Вы не показали ни одной настройки
Все предположения основаны только на Ваших словах
я просто предполагаю , как можно диагностировать проблему
Задам вопрос , почему Вы уверены , что видите icmp пакеты именно от хоста "myhost" после натирования?
Может быть, re1 проверяет канал связи ....
я бы , на Вашем месте , отключил нат для начала на интерфейсе re1 и посмотрел , что будет
у PF есть системный журнал событий , ошибки тоже туда "валятся" (по-моему , /status/system logs/ -
@Konstanti я отключил все мониторирование и добился того, чтобы с указанным фильтром tcpdump не показывал ничего
После чего наблюдаю совпадение по времени между запуском пинга и появлением выдачи tcpdump
Если нужны какие-то релевантные настройки то я их с удовольствием предоставлю.
Если я отключу NAT, то разве файервол что-то пропустит?
-
@dimskraft
По умолчанию , файрвол настроен так , что он обрабатывает только первый пакет , пришедший на любой из интерфейсов
Если этот первый пакет соответствует правилам файрвола , и он его пропускает , то это соединение заносится в таблицу состояний и больше не проверяется .
Таким образом , исходящий трафик , по умолчанию, не проверяется . И трафик обратный тоже не проверяется .
Если Вы отключите исходящий НАТ , и настроете router1 так , чтобы он знал про сеть 10.0/24то Вы увидеть должны такую картину на интерфейсах re2 и re1
10.24->0.1 ( этот пакет проверяется файрволом)
0.1->10.24 ( этот и последующие уже нет)
..... -
@Konstanti я отключил NAT
конкретно, я удалил все правила NAT имеющие отношение к провайдеру re1
в результате, я стал видеть в обоих подсетках (re2 и re1) только реквесты
при этом я вижу в подсетке re2 реквесты уже от myhost
в данном случае поведение правильное, так как router1 не знает маршрута к myhоst и, видимо, кидает ответы в глобальный интернет
-
Если Вы отключите исходящий НАТ , и настроете router1 так , чтобы он знал , про сеть 10.0/24
то Вы увидеть должны такую картину на интерфейсах re2 и re1
10.24->0.1 ( этот пакет проверяется файрволом)
0.1->10.24 ( этот и последующие уже нет)посмотрите вывод команды
dmesg | grep re1
dmesg | grep re2 -
@Konstanti я не вижу, как заставить router1 отвечать на запрос, пришедший от 192.168.10.24, в нужном направлении
-
@dimskraft
Здесь я бессилен , потому что не знаю , что такое router1 (что это за устройство) , и как у него производится настройка статических маршрутов -
@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 disabledUP/DOWN это я перетыкал провод
-
@dimskraft
а если поменять местами re1 и re3 ( включить NAt) , ситуация как-нибудь изменится ? настройки , соответственно тоже поменять -
@Konstanti скорее всего этой функии там нет
Что Вы ожидатете от этого эксперимента?
Допустим, реплаи при выключенном NAT будут проходить. Что это будет значить?
Допустим, реплаи при выключенном NAT проходить все равно не будут. Что это будет означать?
-
@Konstanti я хотел приступить к таким экспериментам как можно позже; неужели нельзя отдиагностировать ситуацию программными средствами?
может быть так, что какие-то новые примочки Роскомнадзора каким-то образом "портят" пакеты, чтобы они далеко не ходили?
может быть так, что pfSense криво встала и криво обновилась и какой-то драйвер не подгружается?
-
@dimskraft
1 если бы PF встала криво , у Вас были бы ошибки драйвера, и интерфейс не поднимался бы
2 каким образом РКН может портить пакеты , когда у Вас прямая связь между устройствами . Или это не так ? и у Вас VPN ? -
@Konstanti устройство стоит у меня, но провайдер имеет к нему доступ и может там прошить что угодно
-
@dimskraft
Никто не будет вам "прошивать" как-то устройство . Системы DPI стоят на площадках провайдера и работают параллельно с основным устройством.
У меня внутри РФ все работает хорошоПо Вашей проблеме - я пока ни разу не видел проблем с НАТом
Все работает четко и как надоНет ли у Вас случайно Floating правил ?
-
@Konstanti в том-то и дело, что все работает чётко, кроме НАТа в одной из подсеток
и не получается понять, почему
нет Floating правил нет
-
-
@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.
-
@Konstanti пардон, это я экспериментировал, сменил адрес подсетки re1
У меня был ещё один свободный интерфейс re4, я переключил кабель на него, потом несколько раз выскакивали какие-то виртуальные гейтвеи, которые я удалял и, наконец, все заработало; перетыкать кабель назад лень, я и так убил на это слишком много времени и все равно будет непонятно, что это было...
