правила iptables для поддоменов

Какая проблема решается таким странным образом? Для работы с доменами есть HTTP-серверы.

nginx тебе нужен.

у меня на порт 25565 не http трафик идёт. С помощью nginx я не смог это настроить

Эти правила где настраиваешь? Редирект тебе для чего, может nginx сразу на 3000 порт повесить?

у меня на порт 25565 не http трафик идёт

Ну покажи что-ли секцию server из конфига nginx

Во-первых, ты пытаешься сделать какую-то чушь. Просто настрой прогу на 3000 порте чтобы слушала 80-й.

Во-вторых, iptables с доменами никак вообще не связано, оно оперирует только ip-адресами.

имя домена появляется только в http. «ниже» ничего не знают про имена и работают с «цифровым ip».
что за протокол и как в нем прописан домен ??

Твоя задача не решается. Используй разные порты с одним адресом и доменом или используй несколько IP-адресов для нескольких доменов. iptables работает с IP-адресами, домены тут не при чём.

http и есть, ты что не видишь он 80-й порт хочет?

для глядящих с закрытыми глазами привожу конкретный комент

у меня на порт 25565 не http трафик идёт.

тебе про nginx правильно подсказывают
есть конечно модули: string/layer7/ndpi если хочешь почитай про них

То что он хочет касается только 80-го порта. Зачем он приплёл остальные - видимо по глупости.

Это называется тсп мультиплексор.

Но в любом случае это плохая затея.

Зачем тебе редирект? Просто открой 80 (и пусть nginx или что там у тебя его слушает), дропай 8000 и 25565, а 3000 вообще закрой или тоже дропай — нафига он тебе?

Да нет, в частном случае задача вполне себе решается. Спец демон слушает соединение и если начало, это http, то кидает его на нжинкс или сразу на сервер, а если нет, то фаллбек на tcp сервер. Решение не лучшее, но вполне рабочее.

У топикстартера не HTTP по его словам. Хотя может я его не понял, запутано там всё как-то.

всё же буду nginx использовать, он не только http оказалось поддерживает

а если порты закрою, то как на них в nginx редиректить?

На 80 порту как раз http, который надо перекидывать на 3000

Я кажись понял феерическую задумку автора

Типа -d name.net и -d 162.168.1.1 в его голове различаются.

а, т.е iptables домены не будет различать, только ip, а nginx их различает

И таки http это пример.

Мультиплексор просто должен знать и различать хотя бы один протокол, чтобы опознавать его или их и роутить куда надо и один незнакомый кидать как фаллбек ещё куда то.

Такие есть для ssh, а в frp оно прямо развито и позволяет неплохо развести даже ssh по доменам.

Ты не ответил, зачем тебе вообще редиректить. В чём сакральный смысл заставлять nginx (или что там у тебя) слушать 80 и редиректить на 3000, если можно сразу сказать ему слушать 3000? Ну или наоборот, смотря куда ты что редиректить собрался.

Остальных портов это вообще никак не касается.

Ответ же просто как мычание. В интернете блочат трафик на незнакомые порты. А 80 и 443 не блочат. Вот и задача завести весь трафик через безопасный порт. Ты как маленький.

Это не отвечает на вопрос, зачем редирект. Если 80 заблочен с той стороны, и ты предлагаешь обращаться к 3000 — ну так можно и слушать сразу на 3000. Зачем слушать на 80 и редиректить с 3000 на 80?

И наоборот.

у меня есть три сервера один на 3000, другой на 8000, они по http работают и третий на 25565 TCP

Ну и в чём проблема? Почему тот, который на 3000 не сделать на 80 сразу. Средставами самого nginx, или что там у тебя на 3000 сейчас? Зачем редирект-то?

Спасибо)

Да. Ибо один работает на 3 уровне, где есть только ip-адрес, а другой на 7 уровне, где в заголовке http есть специальное поле Host.

Не думай, что nginx чем то умнее. Он тоже умеет пробрасывать tcp/udp потоки (tcp stream), но там нет поля Host и поэтому nginx точно также, как и iptables не сможет различать домены.

Ты издеваешься?

80 порт не блочат в интернет-кафе (например), потому что нет смысла в интернете, в котором не открываются обычные сайты. Понятно, что 443 порт важнее и уж его вообще точно не заблочат, но и 80 порт достаточно часто нужен. Закрой 80 порт и каждый день будут жалобы от смузихлебов, трясущих своими телефонами с неработающими пикабущечками.

А закрой 3000 порт и к тебе прибежит один полудурок в месяц, который и раф то никогда не купит, нищеброд и вообще мутный типок.

А если речь про корпорацию? Там просто закрыто все, кроме трех портов для почты, сайтов и все.

Поэтому современные реалии таковы, что весь входящий трафик идет через tls в одну дырку (443 порт) и там уже раскидывай куда надо.

Я уж и не знаю, как все это еще расписать.

Ты издеваешься?

Я нет. У меня ощущение, что издеваешься ты.

80 порт не блочат в интернет-кафе (например), потому что нет смысла в интернете, в котором не открываются обычные сайты. Понятно, что 443 порт важнее и уж его вообще точно не заблочат, но и 80 порт достаточно часто нужен. Закрой 80 порт и каждый день будут жалобы от смузихлебов, трясущих своими телефонами с неработающими пикабущечками.

Я не предлагаю закрывать 80 порт. Ровно наоборот, я предлагаю прямое решение вместо редиректа. Нафига демону слушать на 3000, а с открытого 80 жёстко редиректить на этот 3000, если можно сразу слушать на 80? В данной конфигурации этот 3000 вообще не нужен.

Ты прав. Я ещё раз перечитал исходный пост, там полная ерунда.

Тогда haproxy, но про имя домена он естественно ничего не знает за пределами http протокола.

Я кажется все таки понял, с десятой попытки.

Простой ответ - нет, это невозможно.

В tcp/ip нет понятия домена. При отправке пакета на www.name.net это имя ресолвится в адрес 1.2.3.4 и туда отправляется пакет. Никаких доменов в пакете нет и быть не может.

В протоколе http клиент может указать переменную host. По умолчанию в ней передается хост, к которому обращается клиент. Но это только в http.

Ещё в протоколе TLS (который используется в HTTPS и некоторых других протоколах) домен передаётся тоже в отдельном поле и также может быть использован для роута тем же nginx-ом. И в общем случае он может отличаться от домена в заголовке Host, ага.

Насколько я помню, там в составе сертификата передаются все возможные домены, на которые этот сертификат распространяется и предается это все в обратную сторону, от сервера к клиенту.

На стороне сервера этот список доменов и так известен.

Можно и так делать, но обычно на каждый домен отдельный сертификат.

У кого как, у меня 90% сертификатов вообще дикие.

Но даже если они простые, логично же, что в одном сертификате будет хотя бы два домена - name.net и www.name.net

т.е. с http трафиком так можно сделать, а с tcp - нет?

В первом приближении, в теории, да.

Потому что то, что ты задумал настолько странно, что даже для http трафика непонятно, чем бы это можно было решить. Реверс-прокси, nginx, например, могут отдавать несколько разных сайтов по именам, могу дефолтный сайт вернуть по любому имени, кроме нужного, редирект могут вернуть на другой сайт, протокол, могут 404 вернуть и все такое.

Именно сбрасывать соединение прокси не умеют. А есть ли алг для http в iptables или nft, это надо рыть.

В целом вся задача выглядит как ненужная ерунда, поэтому и решения скорее всего нет.