BelyaevAlexander

Это очевидно. И да: сonntrack НЕ ВЛИЯЕТ на filter - эта цепочка всегда обрабатывает все пакеты, во всяком случае это верно для netfilter-а Linux-а. Это поведение можно изменить руками, добавив запись -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT в самое начало цепочек, но микротик такого не делает, что очевидно. А statefull достигается за счет ctstate который может быть NEW|RELATED|ESTABLISHED|INVALID и параметра сессии ctmark, который - произвольное число. Такое поведение отличается только для nat цепочки, она действительно связана с conntrack. Так что правила у топик стартера срабатывают, вопрос был в том: Насколько корректно он дропает. Как он так настраивал VPN, что трафик через него не шел.

Эм? Разве в цепочке filter пакеты зависят от conntrack, это же не nat цепочка? Разумеется если микротик не скрывает зачем-то первой записи вида conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT, но это было бы странно .) 04:06:06.942663 IP (tos 0x0, ttl 64, id 36948, offset 0, flags [none], proto UDP (17), length 64) gw-l.45467 > 8.8.8.8.53: [bad udp cksum 0x6805 -> 0x6f44!] 6976+ A? danbooru.donmai.us. (36) 04:06:06.943649 IP (tos 0x60, ttl 120, id 54321, offset 0, flags [none], proto UDP (17), length 80) 8.8.8.8.53 > gw-l.45467: [udp sum ok] 6976 q: A? danbooru.donmai.us. 1/0/0 danbooru.donmai.us. [10m] A 92.255.241.100 (52) 04:06:06.953739 IP (tos 0x60, ttl 54, id 9776, offset 0, flags [none], proto UDP (17), length 96) 8.8.8.8.53 > gw-l.45467: [udp sum ok] 6976 q: A? danbooru.donmai.us. 2/0/0 danbooru.donmai.us. [17m38s] A 67.202.114.133, danbooru.donmai.us. [17m38s] A 67.202.114.134 (68) Первый есть: хоть и не от топик стартера, но пусть будет .) Независимые процессы: 1. Сначала идет разрешение имени в IP по DNS - они пытаются подменить IP адрес там; 2. Потом они уже пытаются влезть в сам трафик до этих адресов. Да, не совсем. Фильтр с content для IPv6 адресов должены быть в цепочке IPv4, так же как и правила IPv4 должны быть внутри цепочки IPv6. (Дублироваться) Это из-за того, что если вы используете DNS поверх IPv4/UDP, то в ответе всё равно может содержаться адрес из IPv6. Так-же верно и обратное.

По TCP/443 обычно ходит SSL, он зашифрован. TCP/443 нет смысла добавлять, они в него не вторгаются, так как он зашифрован, его просто блокируют/перенаправляют DNAT-ом. VPN нужен для: 1. TCP/443; 2. Ресурсов которые "добровольно себя блокируют" исходя из страны запрашивающего; 3. Ну и не отсвечивать, что таки ходите на ресурсы из списка; 4. Блокировка может оказаться "выше", на аплинке провайдера, тогда drop их "Location ... " не поможет; 5. Избавляет от необходимости просматривать HTTP трафик. Хотя можно совместить address list со "списком" и drop по content="Location ...". Хотя тут просто вопрос оптимизации нагрузки на процессор. В остальном да, можно просто дропать то, когда они вмешиваются, как сейчас. Тут вам решать. З.Ы: Это странно. Так не должно быть, скорее всего трафик не идет через VPN.

Не понимаю что там в content написано... убедитесь, что лишнее не дропает? Если работает и не дропает лишнего, то нормально .) Кстати, фильтровать то, что они лезут в HTTP - мило, но: Уверены что хотите искать по всем пакетам TCP/80 ? Ресурсов хватит? К тому-же с SSL уже не поможет. Корректней маршутизировать адреса "из списка" через VPN, раз уж он есть. В mikrotik-е подозреваю это можно сделать через policy routing и http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Address_list ?

Они снифают UDP/53 и отвечают быстрее чем настоящий сервер, от его IP, если домен из "списка". Это можно исправить обрасывая ответы с IP заглушек. Пример для netfilter-а Linux-а: iptables -t filter -N dns iptables -t filter -I INPUT -p udp -m udp --sport 53 -j dns iptables -t filter -A dns -m string --hex-string "|2a022698a00000000000000000000064|" --algo bm --to 65535 -j DROP iptables -t filter -A dns -m string --hex-string "|2a022698a00000000000000000000065|" --algo bm --to 65535 -j DROP iptables -t filter -A dns -m string --hex-string "|2a022698a00000000000000000000066|" --algo bm --to 65535 -j DROP iptables -t filter -A dns -m string --hex-string "|5cfff164|" --algo bm --to 65535 -j DROP iptables -t filter -A dns -m string --hex-string "|5cfff165|" --algo bm --to 65535 -j DROP iptables -t filter -A dns -m string --hex-string "|5cfff166|" --algo bm --to 65535 -j DROP Для Mikrotik смотрите в сторону L7 filter: http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/L7

systemd.log_level=debug в cmdline ядра