Сайт не отвечает только с 1 устройства. Настройка сети.

Картинки только так и делаются — ссылками на сторонние сайты.

И в чём добавляется интерес - ... они же по идеи тоже бы сломались?!

Нет, запросы от клиентских машин идут через iptables FORWARD, а локальные — через iptables OUTPUT. Если есть tcpdump, смотрите и сравнивайте исходящие пакеты.

А остальные сайты с маршрутизатора curl'ом нормально работают?

tcpdump дампа нету.

Проблем с другими сайтами нету (ну по крайней мере с 30-60 популярных и ру и не ру всё ок). Эта проблема с сайтами на этой сети, как vk, vkplay, vkvideo и из разные поддомены.

Из интересного зловещее название сети Name: vkplay.ru Address 1: 5.61.236.163 is-antiddos-front-vip40.i.smailru.net

Сначала думал может это бан, но клиентские машины то работают. Потом думал может они при соединение TCP как то чекают заголовки http, но потом отпала идея т.к. я делаю же запросы curl

Не знаю, что чекает vk. Но, маршруты тут точно не причём, так как соединение устанавливается, то есть syn-пакет проходит. Да фильтр по содержимому пакетов у вас врятли в маршрутизаторе кто-то настраивал, если бы уж было ограничение, то всех пакетов на этот ip-адрес. Но, опять повторюсь, syn-пакет проходит.

Раз, содержимое http-запроса с локального компа и с маршрутизатора одинаковое, получается, что-то в ip или tcp загловках этому is-antiddos-front не нравится. Можно, конечно, сдампить пакет на клиетнском компе, потом с маршрутизатора сделать запрос в локалку и сдампить его пакет. Но, ИМХО, вобще не угадаешь, что не так с заголовками...

is-antiddos-front-vip40.i.smailru.net

curl

Ну т.е. мысли, что по UA режут вообще никак не промелькнуло?

Может, на роутере curl какой-нибудь обрезанный и, например, 301 ответ не понимает?..

да, хорошо бы версии curl сверить

А как они curl на машине в локальной сети пускают, а на маршрутизаторе нет, если они одинаковый UA передают?

Одинаковый ли? И да, я Ъ, текст не читал.

Curl версии разные, я же вам даже BYTE трассировку включил на curl, на скриншотах видно что заголовки до байта одинаковые REQUEST посылаются, с одним и тем же UA.

Но на клиентских машинах начинают идти байты response , а на роутере просто виснет до таймаута на этом моменте.

Вопрос для знатоков, если канал открылся к им на сервер TCP, то они ответ по этомуже каналу TCP должны ответить? Я просто думаю будет ли влиять mascarad\nat настройки на этом уровне? Выше писали что от клиентов идут по forward, а от роутера OUTPUT, может ли быть там какой DISALLOW глобальный именно для router-response? Или эти правила не влияют и толко только для тех ситуаций когда TCP закрывается и сервер пытается возобновить tcp соединение?

С роутера закачать другие сайты этим же curl удается?
Если - нет, то смотри правила своего файервола.

Пробовал и curl с указанием сети как –interface

Один «минус» потеряли. Возможно что у асуса и один «минус», но лучше бы почитать его доки, что бы быть уверенным.

ppp0

А он в наличии?
Итого:
1. Сначала убедитесь в названиях интерфейсов.
2. Не путайте - и --

Двойной минус срезает движок сайта. Точнее превращает в чёрточку подлинее. Если бы curl'у указывали что-то другое, то tcp-соединение бы не устанавливалось, другие сайты бы не загружались.

Двойной минус срезает движок сайта. Точнее превращает в чёрточку подлинее.

Понял, вы про --interface ? Возможно и так, но тогда в зависимости от темы.

Канал tcp это уже абстракция верхнего уровня, а на нижнем уровне есть только ip-пакеты, несущие tcp. Одна сторона отправляет tcp SYN-пакет, другая либо молчит, либо отвечает ICMP-reject пакетов, либо tcp SYN-ACK пакетов. В последнем случае tcp-соединение (канал) считается установленым. Это значит, что на всех маршрутизаторах, осуществляющих трансляцию адресов подготовлены и «закреплены» записи в соответствующих таблицах. Если говорить конкретно про iptables, то через таблицу nat (где mascarad настройки) последующие пакеты вобще не проходят.

может ли быть там какой DISALLOW глобальный именно для router-response?

Можно сделать очень много что, но это надо специально постараться. Если в свой маршрутизатор забивали iptables правила маршрутизации, созданые с помощью chatGPT, то так и скажите. Не получится просто так написать или откуда-то скопипастить правило, пропускающее SYN-ACK пакет и не пропускающее остальные, причём ещё только для vkplay.

ИМХО, это проблема именно vkplay. Если фантазировать, то возможно, они там как-то по заголовкам ip/tcp отличают комп от маршрутизаторов и для последних закрывают трафик. Многие spam/ddos боты рулят именно бытовыми маршрутизаторами, так как в них типовые дырки, они постоянно включены...

Да, про interface. Тут, и на других сайтах это частый прикол, что два «минус» подряд при отправке сообщения заменяются на, «en-тире» или как это назвать. Потом с сайта в терминал копипастишь, даже если добавить минус, всё одно будет «неизвестная опция», нужно стирать и ставить два минуса.

Но, то что ТС выложил в виде скриншотов, там вобще опции interface нету, да и не нужен он на маршрутизаторе с одним выходом в инет. А trace там с двумя минусами, так что ТС на этом уровне не запутался :) проблема где-то дальше.

Там, на скринах, кстати, вообще не понятно, что второе - это роутер )

https://i.imgur.com/OOXGZem.png

btw да :) Отлично подметили. Что на первом, что на втором:
tester@ubu-fwkjm43vgp:
tester@ubu-fwkjm43vgp:

Какой ещё icmp-reject?

Те пакеты, которые перечислены в ″man iptables-extensions″ в ″-j REJECT″.

Не понял причём тут extensions, но -j REJECT в норме никаких icmp (в ответ на syn) не шлёт. Он шлёт tcp rst.

REJECT описан в ″man iptables-extensions″, когда то давно всё было в ″man iptables″, но сейчас две разные man-страницы.

У меня там написано:

--reject-with type The type given can be icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited, icmp-host-prohibited, or icmp-admin-prohibited (*), which return the appropriate ICMP error message (icmp-port-unreachable is the default). The option tcp-reset can be used on rules which only match the TCP protocol...

Сейчас проверил, если в ″FORWARD″ сделать ″-j REJECT″, без опций, а потом пустить SYN-пакет «через это правило», то в ответ прилетает icmp-port-unreachable с указанием хоста/порта. На клиенте, пытающемя подключится, ядро обрабатывает этот пакет и вызов connect() сразу завершается с ошибкой.

Согласен, что я в том посте не дописал, что как вариант, в ответ на SYN может и RST пакет прийти. Но особо смысл ответа это не поменяет. Если TCP-соединение устанавливается, то копать настройки своего маршрутизатора смысла нет.

P.S. Да, мне было лень писать ICMP Type 3 (Destination Unreachable Message). Я расчитывал, что ТС погуглит ″icmp-reject″ и много чего узнает. Но он куда-то исчез.

Согласен, что я в том посте не дописал, что как вариант, в ответ на SYN может и RST пакет прийти

Так дело в том что это не просто вариант, а дефолт, который имеется в 99% случаев. А ответы icmp-пакетами на tcp syn это редкая экзотика.

Хотя -j REJECT оказывается и правда дефолтно шлёт icmp, но его доля в обработке tcp syn-ов в среднем по миру исчезающе мала (а ты писал именно про реакцию на syn вообще, а не про то как его файрволлом отклонять). В подавляющем большинстве случаев, если ответ не SYN+ACK, то там либо RST от порта который просто никто не слушает, либо drop в файрволле и ответа нет вообще. А вот на нерабочие udp-порты отвечаются icmp, да.