У меня и моего друга в разных регионах одинаково не работает порт 25565 на IP Cloudflare - на нём хостится Minecraft сервер Hypixel.
Даже если в начале удалось пропустить немного трафика TLS фейками, спустя небольшое количество переданных данных, всё равно смерть
При этом у другого знакомого, что в Питере а не в регионе, оно пробивается Запретом. 16 (или сколь-нибудь) КБ блокировки нет.
У нас двоих в регионах 16 кб намертво
Но сайт обс при этом работает нормально?
Решил все-таки проверить.
tcp dport 0
Linux NAT проходит даже с liberal=0
Если linux хост получает SYN с dport=0, он отвечает RST+ACK - точно так же, как если бы листенера не было на порту. connection refused
При проходе через 2 разных провайдера с внешним IP пакет не доходит как до VPS, так и между этими 2 провайдерами. Режут
То есть на первый взгляд если бы не запрет в socket api , то можно было бы подвесить листенер на 0 и сделать туда коннект. Но в инете эти пакеты скорее всего сгинут даже без NAT
В socket api при указании port 0 система сама назначает ненулевой порт.
Про ограничения сокетов, а если попробовать что-то на подобии:
-t nat -A PREROUTING -p tcp --dport 0 -j DNAT --to-destination 127.0.0.1:5555
?
Может наоборот ?
Сгенерировать dport 0 невозможно в сокетах.
Проблема в резалке в инете
Это ведь про конечный хост в интернете.
А микротик ведь схавал это, а провайдер нет:
Starting Nping 0.7.94SVN ( https://nmap.org/nping ) at 2026-03-11 13:10 MSK
SENT (0.0466s) TCP client:21342 > 8.8.8.8:0 S ttl=1 id=45496 iplen=40 seq=1880655471 win=1480
RCVD (0.0469s) ICMP [10.0.0.1 > client TTL=0 during transit (type=11/code=0) ] IP [ttl=64 id=59492 iplen=68 ]
SENT (1.0471s) TCP client:21342 > 8.8.8.8:0 S ttl=2 id=45496 iplen=40 seq=1880655471 win=1480
RCVD (1.0476s) ICMP [192.168.254.6 > client TTL=0 during transit (type=11/code=0) ] IP [ttl=63 id=62217 iplen=72 ]
SENT (2.0496s) TCP client:21342 > 8.8.8.8:0 S ttl=3 id=45496 iplen=40 seq=1880655471 win=1480
SENT (3.0514s) TCP client:21342 > 8.8.8.8:0 S ttl=4 id=45496 iplen=40 seq=1880655471 win=1480
SENT (4.0532s) TCP client:21342 > 8.8.8.8:0 S ttl=5 id=45496 iplen=40 seq=1880655471 win=1480
SENT (5.0542s) TCP client:21342 > 8.8.8.8:0 S ttl=6 id=45496 iplen=40 seq=1880655471 win=1480
SENT (6.0552s) TCP client:21342 > 8.8.8.8:0 S ttl=7 id=45496 iplen=40 seq=1880655471 win=1480
SENT (7.0578s) TCP client:21342 > 8.8.8.8:0 S ttl=8 id=45496 iplen=40 seq=1880655471 win=1480
SENT (8.0596s) TCP client:21342 > 8.8.8.8:0 S ttl=9 id=45496 iplen=40 seq=1880655471 win=1480
SENT (9.0613s) TCP client:21342 > 8.8.8.8:0 S ttl=10 id=45496 iplen=40 seq=1880655471 win=1480
SENT (10.0630s) TCP client:21342 > 8.8.8.8:0 S ttl=11 id=45496 iplen=40 seq=1880655471 win=1480
SENT (11.0644s) TCP client:21342 > 8.8.8.8:0 S ttl=12 id=45496 iplen=40 seq=1880655471 win=1480
SENT (12.0672s) TCP client:21342 > 8.8.8.8:0 S ttl=13 id=45496 iplen=40 seq=1880655471 win=1480
SENT (13.0688s) TCP client:21342 > 8.8.8.8:0 S ttl=14 id=45496 iplen=40 seq=1880655471 win=1480
SENT (14.0700s) TCP client:21342 > 8.8.8.8:0 S ttl=15 id=45496 iplen=40 seq=1880655471 win=1480
SENT (15.0719s) TCP client:21342 > 8.8.8.8:0 S ttl=16 id=45496 iplen=40 seq=1880655471 win=1480
SENT (16.0739s) TCP client:21342 > 8.8.8.8:0 S ttl=17 id=45496 iplen=40 seq=1880655471 win=1480
SENT (17.0771s) TCP client:21342 > 8.8.8.8:0 S ttl=18 id=45496 iplen=40 seq=1880655471 win=1480
SENT (18.0785s) TCP client:21342 > 8.8.8.8:0 S ttl=19 id=45496 iplen=40 seq=1880655471 win=1480
SENT (19.0802s) TCP client:21342 > 8.8.8.8:0 S ttl=20 id=45496 iplen=40 seq=1880655471 win=1480
SENT (20.0820s) TCP client:21342 > 8.8.8.8:0 S ttl=21 id=45496 iplen=40 seq=1880655471 win=1480
SENT (21.0839s) TCP client:21342 > 8.8.8.8:0 S ttl=22 id=45496 iplen=40 seq=1880655471 win=1480
SENT (22.0859s) TCP client:21342 > 8.8.8.8:0 S ttl=23 id=45496 iplen=40 seq=1880655471 win=1480
В DNAT нет никаких ограничений, это работает. Но пакеты не доходят через инет
Так самое интересное, что через микрот трафик проходит, но не доходит до BRAS’a провайдера, используется IPoE.
Можно попробовать set ttl сделать 1,2,3
и тд
и посмотреть приходят ли icmp
такой вот свой traceroute. обычный порт 0 не проглатывает
так можно понять кто режет, если они пришлют icmp
Результат выше я приложил в отредактированном сообщении, там трассировка, BRAS провайдера такое не оценил.
Действительно. Первые простые узлы ничего не режут, а что поумнее прибивает
Не сказать, что в моём случае простой узел, SFP’шки на 10 гиг, микрот на arm64.
обычный linux не режет, хардваре тем более не должен - он вообще тупой
поумнее - в смысле узлы, которые выполняют какую-то фильтрацию
SFP и скорость тут вообще ни при делах
может в киске это по умолчанию, я не сталкивался
Проверил на BRAS’e huawei PPPoE, тоже не жрёт, причём интересная картина, от 0-3 не принимает, принимает только от 4. На IPoE принимает от 1.
1-3 вполне валидны. Фильтры скорее всего какие-то.
Вот что робот сказал :
В промышленных и операторских роутерах порт 0 часто «режется» не из-за прямой настройки, а на уровне архитектуры обработки пакетов в ASIC (Application-Specific Integrated Circuit).
Устройства и архитектуры, блокирующие порт 0:
- Cisco Nexus (ASIC CloudScale / Gatos):
- В этих устройствах реализованы механизмы Hardware-based Sanity Checks. Пакеты с
L4 port == 0могут классифицироваться как malformed (поврежденные) на этапе парсинга заголовков в ASIC. - В режиме ACI (Application Centric Infrastructure) правила в
sup-tcam(Supervisor TCAM) часто содержат жестко закодированные исключения, которые дропают аномальный трафик до того, как он попадет в таблицы маршрутизации.
- Juniper (ASIC Trio / EZchip):
- Чипы серии Trio (используются в MX-серии) выполняют глубокую проверку протоколов. Трафик с портом 0 может быть отброшен как «TCP/UDP header error».
- Если на интерфейсе включены функции Screen Options (в рамках Junos IDS/IPS), пакеты с dport 0 блокируются механизмом защиты от сканирования портов, причем это происходит на аппаратном уровне (PFE — Packet Forwarding Engine) для сохранения производительности.
- Устройства на базе Broadcom (Trident / Tomahawk / Jericho):
- Многие современные коммутаторы и роутеры (Arista, Cisco Nexus 3000, Mellanox) используют чипы Broadcom. В них есть встроенный функционал L4 Header Validation. Если он активен в микрокоде, ASIC считает порт 0 недопустимым согласно стандартам RFC и делает
drop.
- Специализированные Security-роутеры (Fortigate, Cisco ASA/Firepower):
- Хотя это гибридные устройства, их сетевые процессоры (NP) настроены на Protocol Enforcement. Порт 0 зарезервирован IANA и не может быть назначен легитимному приложению, поэтому он отсекается как потенциальный вектор атаки (например, для обхода ACL или отпечатков ОС).
Почему это происходит в ASIC:
- Оптимизация таблиц: ASIC спроектированы для быстрой обработки стандартных заголовков. Аномалии (вроде порта 0) требуют исключительной логики обработки, которую проще и безопаснее реализовать через сброс пакета.
- Защита Control Plane: Блокировка порта 0 на входе защищает внутренний процессор роутера от попыток подбора параметров TCP-стека.
Если ваша задача — пробросить трафик с портом 0 через цепочку промышленных устройств, вероятность успеха крайне мала. Даже если вы отключите NAT, пакет будет уничтожен аппаратным фильтром аномалий на первом же серьезном узле или провайдерском Edge-роутере.
Поведение на Йоте из зоны действия белых списков:
Starting Nping 0.7.94SVN ( https://nmap.org/nping ) at 2026-03-11 13:37 MSK
SENT (0.0124s) TCP 10.155.103.190:42415 > 8.8.8.8:0 S ttl=1 id=27921 iplen=40 seq=2597583055 win=1480
RCVD (0.0517s) ICMP [10.155.103.42 > 10.155.103.190 TTL=0 during transit (type=11/code=0) ] IP [ttl=64 id=55441 iplen=68 ]
SENT (1.0127s) TCP 10.155.103.190:42415 > 8.8.8.8:0 S ttl=2 id=27921 iplen=40 seq=2597583055 win=1480
SENT (2.0160s) TCP 10.155.103.190:42415 > 8.8.8.8:0 S ttl=3 id=27921 iplen=40 seq=2597583055 win=1480
SENT (3.0174s) TCP 10.155.103.190:42415 > 8.8.8.8:0 S ttl=4 id=27921 iplen=40 seq=2597583055 win=1480
SENT (4.0197s) TCP 10.155.103.190:42415 > 8.8.8.8:0 S ttl=5 id=27921 iplen=40 seq=2597583055 win=1480
SENT (5.0217s) TCP 10.155.103.190:42415 > 8.8.8.8:0 S ttl=6 id=27921 iplen=40 seq=2597583055 win=1480
RCVD (5.3295s) TCP 8.8.8.8:0 > 10.155.103.190:42415 RA ttl=59 id=52205 iplen=40 seq=0 win=32120
SENT (6.0235s) TCP 10.155.103.190:42415 > 8.8.8.8:0 S ttl=7 id=27921 iplen=40 seq=2597583055 win=1480
RCVD (6.1951s) TCP 8.8.8.8:0 > 10.155.103.190:42415 RA ttl=59 id=8888 iplen=40 seq=0 win=32120
SENT (7.0274s) TCP 10.155.103.190:42415 > 8.8.8.8:0 S ttl=8 id=27921 iplen=40 seq=2597583055 win=1480
RCVD (7.4212s) TCP 8.8.8.8:0 > 10.155.103.190:42415 RA ttl=59 id=1341 iplen=40 seq=0 win=32120
SENT (8.0290s) TCP 10.155.103.190:42415 > 8.8.8.8:0 S ttl=9 id=27921 iplen=40 seq=2597583055 win=1480
RCVD (8.2406s) TCP 8.8.8.8:0 > 10.155.103.190:42415 RA ttl=59 id=22731 iplen=40 seq=0 win=32120
SENT (9.0308s) TCP 10.155.103.190:42415 > 8.8.8.8:0 S ttl=10 id=27921 iplen=40 seq=2597583055 win=1480
RCVD (9.2696s) TCP 8.8.8.8:0 > 10.155.103.190:42415 RA ttl=59 id=9196 iplen=40 seq=0 win=32120
Пакет доходит до PGW шлюза, но затем отдаёт RST+ACK.
Такое же поведение и на 53 порту:
Starting Nping 0.7.94SVN ( https://nmap.org/nping ) at 2026-03-11 13:36 MSK
SENT (0.0140s) TCP 10.155.103.190:42412 > 8.8.8.8:53 S ttl=1 id=17809 iplen=40 seq=213881915 win=1480
RCVD (0.1040s) ICMP [10.155.103.42 > 10.155.103.190 TTL=0 during transit (type=11/code=0) ] IP [ttl=64 id=54575 iplen=68 ]
SENT (1.0145s) TCP 10.155.103.190:42412 > 8.8.8.8:53 S ttl=2 id=17809 iplen=40 seq=213881915 win=1480
SENT (2.0164s) TCP 10.155.103.190:42412 > 8.8.8.8:53 S ttl=3 id=17809 iplen=40 seq=213881915 win=1480
SENT (3.0178s) TCP 10.155.103.190:42412 > 8.8.8.8:53 S ttl=4 id=17809 iplen=40 seq=213881915 win=1480
SENT (4.0215s) TCP 10.155.103.190:42412 > 8.8.8.8:53 S ttl=5 id=17809 iplen=40 seq=213881915 win=1480
SENT (5.0228s) TCP 10.155.103.190:42412 > 8.8.8.8:53 S ttl=6 id=17809 iplen=40 seq=213881915 win=1480
RCVD (5.1274s) TCP 8.8.8.8:53 > 10.155.103.190:42412 RA ttl=59 id=21606 iplen=40 seq=0 win=32120
SENT (6.0246s) TCP 10.155.103.190:42412 > 8.8.8.8:53 S ttl=7 id=17809 iplen=40 seq=213881915 win=1480
RCVD (6.2452s) TCP 8.8.8.8:53 > 10.155.103.190:42412 RA ttl=59 id=4424 iplen=40 seq=0 win=32120
SENT (7.0265s) TCP 10.155.103.190:42412 > 8.8.8.8:53 S ttl=8 id=17809 iplen=40 seq=213881915 win=1480
RCVD (7.1767s) TCP 8.8.8.8:53 > 10.155.103.190:42412 RA ttl=59 id=27568 iplen=40 seq=0 win=32120
SENT (8.0283s) TCP 10.155.103.190:42412 > 8.8.8.8:53 S ttl=9 id=17809 iplen=40 seq=213881915 win=1480
RCVD (8.2995s) TCP 8.8.8.8:53 > 10.155.103.190:42412 RA ttl=59 id=20227 iplen=40 seq=0 win=32120
10.155.103.42 - андроид в режиме модема.
Однако с мобильными сетями всё иначе, трафик eNB ↔ S-GW ↔ P-GW проносится в инкапсулированном GTP туннеле, не в естественной IP-среде.
Тайминг между SYN и RA целых 100 мс. Многовато для быстрого ответа DPI.
Что происходит если на свой сервак посылать tcp ? Что до сервака доходит ?
Да вроде да. Изображения прогрузились, фон прогрузился, сайт прогрузился
Да, кстати, как вышки выходят в интернет? GTP туннелем до какого-то главного городского сервера оператора? Где физически стоит ТСПУ?
SYN не дойдёт до конечного сервера, а по поводу пингов, оно могло увеличится из-за Wi-Fi обёртки, ну а вообще я замечал что йота по ICMP может искусственно повышать пинг, конкретно не могу сказать в чём дело.
eNB устанавливает соединение до S-GW, S-GW обслуживает регион, может даже несколько регионов, основная задача S-GW обслуживать мобильность, а S-GW соединяется с P-GW, который уже может обслуживать целый федеральный округ, более детально можно узнать информацию в интернете, ТСПУ стоит только у P-GW, S-GW прозрачен с точки зрения L3.