iptables - не всегда срабатывает правило

[Shion]

Решил опробовать способ обхода заглушек провайдера с одного всем известного сайта. Принцип несложный - фильтровать пакеты по наличию в них HTTP строки на переадресацию. Однако четкой инструкции на мой роутер на сайте не было, поэтому попробовал реализовать это с помощью OPKG и Entware отсюда. Включил OPKG через веб-интерфейс, "накатил" Entware, сделал через SSH "opkg update" и "opkg install iptables" и прописал по инструкции такую вот команду.

iptables -t raw -A PREROUTING -p tcp --sport 80 -m string --algo bm --from 50 --to 200 --hex-string "Location: http://%заглушка%/" -j DROP

И вроде работает. Но только вот работает как-то нестабильно. Довольно часто пакеты, которые должны попадать под это правило, всеравно проходят. Адрес в %заглушка% указан верно. Диапазон поиска фразы в пакете подходит (согласно тупому визуальному сравнению в Wireshark).

Как найти виновного с учетом того, что в linux-системах я понимаю мало?

[Александр Рыжов]

@Shion, это правило будет работать исключительно для HTTP-ресурсов и не сможет работать на HTTPS. Может быть дело в этом?

[Shion]

Извиняюсь, не уточнил. Для HTTPS там указано другое правило и оно работает на ура:

iptables -t raw -A PREROUTING -p tcp --sport 443 -m u32 --u32 "4=0x00000000&&0x20=0x50140000" -j DROP

Такого же рода есть правило и для HTTP:

iptables -t raw -A PREROUTING -p tcp --sport 80 -m u32 --u32 "0x1E&0xFFFF=0x5010 && 0x60=0x7761726e && 0x64=0x696e672e && 0x68=0x72742e72" -j DROP

Однако оно, и правило что я упоминал выше дают непостоянный результат. Иногда пакет с HTTP-переадресацией (302 FOUND ... Location: http://%заглушка%/) роутером пропускается, иногда - нет. И каким образом можно выяснить причину, я не знаю.

На случай если я что-то недоглядел, пример пакета пропускаемого роутером:

Изменено 15 сентября, 2016 пользователем Shion

[Shion]

Нашелся добрый человек (kx77), давший объяснение проблеме:

Quote

если те же правила работают на других linux системах, то дело может быть в проприетарных хаках ядра от производителя.
их делают для поддержки аппаратного nat и роутинга. если есть наcтройки отключения hardware nat, акселерации или что-то там еще - отключай

Обновление роутера без пункта "Network accelerator engine" решило проблему и правила теперь стабильно работают. Разработчикам NDMS и Entware есть над чем подумать.

[Le ecureuil]

3 часа назад, Shion сказал:

Нашелся добрый человек (kx77), давший объяснение проблеме:

Обновление роутера без пункта "Network accelerator engine" решило проблему и правила теперь стабильно работают. Разработчикам NDMS и Entware есть над чем подумать.

А, ну да.

С ppe hardware и ppe software подобные вещи несовместамы априори.

Я думал это всем известно, и это никто не собирается чинить.

Хотите "ванильный" netfilter - отключайте ppe software и ppe hardware.

[Shion]

On 15/09/2016 at 6:45 PM, Le ecureuil said:

Хотите "ванильный" netfilter - отключайте ppe software и ppe hardware.

А поподробнее можно, куда именно нужно в Giga II ткнуть, чтобы все это повыключать? А то снова правило то работает то не работает. Ну на самом деле я даже не понимаю работало ли оно до этого. Знаю только, что раньше, примерно 2 обновления NDMS назад, блоченные РКН сайты по HTTPS открывались стабильно с вышеуказанными правилами. А теперь почему-то перестали. Учитывая, что я с роутером ничего кроме этих обновлений не делал, либо система блокировки у провайдера поменялась (что никто из знакомых не подтвердил), либо разработчики прошивки роутера опять что-то накосячили. Пункт Network accelerator engine в обновлении естественно не отмечен.

[Le ecureuil]

7 часов назад, Shion сказал:

А поподробнее можно, куда именно нужно в Giga II ткнуть, чтобы все это повыключать? А то снова правило то работает то не работает. Ну на самом деле я даже не понимаю работало ли оно до этого. Знаю только, что раньше, примерно 2 обновления NDMS назад, блоченные РКН сайты по HTTPS открывались стабильно с вышеуказанными правилами. А теперь почему-то перестали. Учитывая, что я с роутером ничего кроме этих обновлений не делал, либо система блокировки у провайдера поменялась (что никто из знакомых не подтвердил), либо разработчики прошивки роутера опять что-то накосячили. Пункт Network accelerator engine в обновлении естественно не отмечен.

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

> system set net.ipv4.netfilter.ip_conntrack_fastnat 0

> no ppe software

> no ppe hardware

> system configuration save

[Shion]

Не сразу понял, что речь идет о CLI. Результат команд ниже:

(config)> system set net.ipv4.netfilter.ip_conntrack_fastnat 0
FileSystem::Proc: System setting saved.
(config)> no ppe software
Command::Base error[7405600]: no such command: ppe.
(config)> no ppe hardware
Command::Base error[7405600]: no such command: ppe.
(config)> system configuration save
Core::ConfigurationSaver: Saving configuration...

Я так понимаю команда ppe не сработала, поскольку не установлен "Network accelerator engine"?

Нужна ли перезагрузка? И достаточно ли будет написать "system set net.ipv4.netfilter.ip_conntrack_fastnat 1" и "system configuration save", чтобы вернуть все обратно?

[Le ecureuil]

56 минут назад, Shion сказал:

Не сразу понял, что речь идет о CLI. Результат команд ниже:

 

(config)> system set net.ipv4.netfilter.ip_conntrack_fastnat 0
FileSystem::Proc: System setting saved.
(config)> no ppe software
Command::Base error[7405600]: no such command: ppe.
(config)> no ppe hardware
Command::Base error[7405600]: no such command: ppe.
(config)> system configuration save
Core::ConfigurationSaver: Saving configuration...

 

Я так понимаю команда ppe не сработала, поскольку не установлен "Network accelerator engine"?

Нужна ли перезагрузка? И достаточно ли будет написать "system set net.ipv4.netfilter.ip_conntrack_fastnat 1" и "system configuration save", чтобы вернуть все обратно?

Перезагрузка не нужна, для отмены можете набрать
> no system set net.ipv4.netfilter.ip_conntrack_fastnat

или то, что предложили вы.

[vasek00]

ksoftirqd - kernel soft irq demon

Как говорится через раз/два но срабатывает ведь.

[Максим_]

В 28.02.2018 в 04:51, DarkDiver сказал:

> iptables -t mangle -A PREROUTING -p tcp --sport 443 --tcp-flags RST RST -j DROP

Команда выполнена без замечаний.

При выполнении второй:

В 28.02.2018 в 04:51, DarkDiver сказал:

> iptables -t mangle -A PREROUTING -p tcp --sport 80 -m string --string "Location: http://%заглушка%" --algo bm -j DROP

получаю "iptables: No chain/target/match by that name."

В чем может быть проблема?