Проброс портов на роутере. TP-Link Archer C5

https://tp-link.com/ru/support/faq/742/

И? Шутка юмора типа?

Что и где в роутере ткнуть я разобрался прежде чем, что-то делать.

И в чём тогда вопрос? Ты либо неправильно указываешь номера портов, либо неправильно тестируешь.

Если ты пробуешь проверить доступность порта на внешнем сетевого интерфейсе (IP адресе) роутера из внутренней сети за роутером, то, вполне возможно, ничего работать не будет.

Проверяй доступность с ПК, находящимся во внешнем мире, а не в твоей локальной сети.

К тому же на странице указан комментарий:

Поскольку правила переадресации связаны с IP-адресом устройства, необходимо зарезервировать постоянный IP-адрес вашему устройству, для которого необходимо открыть порты. Если вы не знаете, как настроить постоянный IP-адрес на устройстве, вы можете настроить резервирование адресов, чтобы IP-адрес всегда назначался этому устройству.

Возможно, если внешний интерфейс получает параметры по DHCP, то логика роутера не отрабатывает правильно.

В общем, запускай на системе, на которую настраивается перенаправление порта tcpdump: tcpdump -ni any port 80, стучись telnet с внешнего мира на внешний IP адрес роутера и порт 80, смотри что будет в выводе tcpdump.

Ещё не запутайся в протоколе, ставь «ALL» или tcp.

Так я же в посте все описал. IP белый, через no-ip домен привязал. Тестирую тоже снаружи, об этом написано в посте. При этом независимо от проброса портов на роутер не приходит traceroute, кроме как с параметром -I, который равносилен пингу. Для теста настроил проброс на tinyproxy и transmission. Nmap с vds между портами видит разницу(на одном прокси, на втором xml html), но пишет, что порты фильтруются.

Вопрос в том, что может кто-то сталкивался и может сказать, что дело в провайдерской прошивке. И тогда надо ее ковырять. Либо есть что-то не очевидное в настройке роутера, чего нет в гайдах.

В инете большая часть вопросов и ответов у людей, у которых серый IP, и соответственно проблема совсем другая.

И что показывает tcpdump с ПК, куда порт пробрасывается? Роутер тп-линк является для него шлюзом? Подключи вместо роутера тп-линку нормальное устройство, где можно видеть подключения, например микротик, там сможешь отфильтровать есть ли вообще подключения на порт.

Благодарю за помощь. Хоть и вышло недопонимание, все таки понял в чем проблема благодаря совету. Tcpdump показал, что пакет приходит на нужный ПК и на нужный интерфейс, а ответ уходит через интерфейс wireguard, который себя прописал шлюзом по умолчанию.

Запустил на телефоне ftp сервер(сразу не додумался), порт оказался доступен снаружи.

Правда я все равно не понимаю, почему снаружи traceroute не доходит до роутера, а пинг доходит. Может я тут не догоняю некоторых деталей.

И опять же непонятно, почему tinyproxy и transmission игнорируют параметр bind-addres и все равно лезут в wg0?

а ответ уходит через интерфейс wireguard, который себя прописал шлюзом по умолчанию.

Вот то-то и оно, поэтому я и спросил тебя про шлюз.

почему снаружи traceroute не доходит до роутера,

Доходит, только твой роутер не отвечает на некоторые ICMP пакеты. В выводе трассировки ты можешь видеть IP адреса интерфейсов промежуточных маршрутизаторов, через которые идёт трассировка до твоего IP адреса.

Точно так же сделав трассировку, например до ya.ru ты не увидишь ответов с его IP адресов, только часть ответов до сети Yandex.

почему tinyproxy и transmission игнорируют параметр bind-addres и все равно лезут в wg0?

Они не игнорируют. При отправке ответов на IP адрес назначения в роль вступает таблица маршрутизации. А маршрутом по умолчанию был маршрут через WG.

Если тебе нужно, чтобы работал одновременно wireguard и ты выходил в Internet через него и в тоже время трафик от нужных тебе сервисов шёл через тп-линк, то тебе нужно в таблице mangle маркировать пакеты, например с IP адреса интерфейса, которые слушают эти сервисы.

Далее создать отдельную таблицу маршрутизации в /etc/iproute2/rt_tables, добавить в неё маршрут по умолчанию через тп-линк и маршрут сети твоего сетевого интерфейса.

Далее посредством ip rule перенаправлять маркированные пакеты через эту таблицу маршрутизации.

Можешь маркировать не все пакеты, а только пакеты с портами источниками, которые тебе нужны.

Спасибо за советы. Попробую, но уже позже. Надо поспать.

Вообще на самом компе с linux я настроил форвардинг, чтобы его указать шлюзом для телевизора и прочих устройств, где только шлюз и можно задать. Таким образом на них продолжают работать ресурсы с «устаревшим оборудованием». Хотя изначально хотел запустить там просто прокси - этого было достаточно для двух других ПК в доме.

Потом понял, что transmission при раздаче тоже полезет в wg0, завернул ее в network namespace и все ок. Она не видит wg0, а из виртуальной сети все пакеты на роутер маршрутизируются.

Теперь после ваших советов и дополнительного чтения матчасти(хотя я не сисадмин, просто дома нужна файлопомойка:)), понял, что пакеты, которые родило ПО(прокси и т.д.) никак не привязываться к интерфейсу запроса, а просто улетают в дефолтный шлюз. Даже не смотря на опции «bind», которые казалось бы должны решать проблему.

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

Даже не смотря на опции «bind», которые казалось бы должны решать проблему.

Опция bind нужна лишь, чтобы явно задать на каком сетевом интерфейсе (IP адресе) приложение принимает запросы и слушает порт.

Т.е. этот параметр задаёт откуда приложение принимает запросы, а не как и куда отправляет.

Обычно, если ничего не задано стоит 0.0.0.0, т.е. на всех сетевых интерфейсах. Если явно указать IP адрес сетевого интерфейса - то только на нём.

А то, через какой сетевой интерфейс будут уходить ответные пакеты, т.е. каким маршрутом, через какой сетевой интерфейс уже определяется таблицей маршрутизации.

Чтобы в случае использования другого шлюза пакеты пришедшие через шлюз тп-линк от проброса портов уходили обратно на него же нужно делать SNAT на тп-линк. Т.е. подмену адреса источника, на внутренний IP адрес тп-линк, но умеет ли так делать тп-линк - не знаю.

Если умеет - настраивай, только ты не будешь видеть в логах сервисов с какого внешнего IP адреса пришёл пакет (запрос).

В этом случае не нужно будет делать отдельную таблицу маршрутизации или запускать приложения в отдельном неймспейс.

Но transmission всё равно придётся. А вот WEB-сервер, на который ты допустим перенаправляешь порты с тп-линк - нет.