EX-R SFP роутер – публично доступные ресурсы/сервисы недоступны из локальной сети.

EX-R SFP роутер – публично доступные ресурсы/сервисы недоступны из локальной сети., UniFi Network

daniel.kosieradzki

Guest

10.04.2025 07:04:00

У меня Ubiquiti EX-R SFP роутер. Я открыл порт 443 с помощью переадресации портов (порт веб-консоли управления изменился на 8443). Hairpin NAT отключен. Функция автоматического брандмауэра включена, и я могу легко получить доступ к этим сервисам с устройств, не подключенных к моей локальной сети (например, с мобильного телефона с отключенным Wi-Fi), но не могу сделать это внутри моей частной сети (LAN). Подозреваю, что мне не хватает какого-то правила брандмауэра, но я не знаю, как его настроить.

Детали подключения:
eth0 – кабель от моего провайдера (я сомневаюсь, что это играет какую-либо роль, но у меня статический IP),
eth1 – коммутатор Ubiquiti, к которому подключены все остальные сетевые устройства (например, AP, мой homelab сервер),
остальные порты – не подключены.

Я могу предоставить свою конфигурацию, но она действительно базовая. Без кастомных правил брандмауэра, несколько переадресаций портов (помимо упомянутой выше).

А, еще кое-что: до того, как я изменил порт для веб-консоли управления, я выполнил CLI команду для отключения удаленного доступа к консоли (она работала на порту 443). У меня есть подозрение, что, сделав это, я мог добавить какое-то скрытое правило DENY/DROP в брандмауэр (невидимое в конфигурации).

Я был бы очень благодарен за вашу помощь.

its3am Guest	#2 10.04.2025 19:02:00 Настоящее™ решение – использовать публичные IP-адреса для серверов вместо NAT.

daniel.kosieradzki

Guest

10.04.2025 18:54:00

Всё работает после включения hairpin... Я избегал этого, потому что сталкивался с мнением, что hairpin — это "скорее некрасивая костыль", чем правильное решение, и я лично был уверен, что должна быть какая-то альтернатива, позволяющая мне избежать его использования. В любом случае, спасибо за помощь

redfive

Guest

10.04.2025 18:40:00

На самом деле, менять https-порт роутера не нужно, как только настроен hairpin NAT, только пакеты, отправленные изнутри локальной сети и предназначенные для public.ip.address:443, будут перенаправлены на внутренний целевой хост (конечно, все пакеты, приходящие снаружи и предназначенные для public.ip.address:443, тоже будут перенаправлены на этот же хост, но думаю, что роутер напрямую выставлять в сеть не требуется). Конечно, есть еще вопросы про автоматический файрвол, но для начала попробуйте заставить это работать...

its3am

Guest

10.04.2025 15:14:00

Ответный пакет отбрасывается, потому что система не считает его частью одного TCP-соединения – его исходный адрес отличается от адреса назначения первоначального пакета. Это не связано с файерволом. Собственно, файервол роутера даже не задействован, потому что ответ отправляется напрямую источнику TCP-соединения.

daniel.kosieradzki

Guest

10.04.2025 14:59:00

Спасибо за очень утомительное разъяснение

Ещё один вопрос, если позволите. Раз это правда, что мои соединения обрываются, потому что мне не хватает правила брандмауэра, разрешающего трафик между хостами в локальной сети, верно? Если я все правильно понял, то и умные правила брандмауэра тоже должны сработать (вместо включения hairpin NAT), правильно? Я не пытаюсь избежать hairpin любой ценой — просто использую возможность узнать что-то новое у умных ребят

Спасибо заранее за вашу помощь. Вы мне уже очень помогли.

its3am

Guest

10.04.2025 14:45:00

Вот именно поэтому вам нужен hairpin NAT, чтобы перенаправление портов работало для внутренних хостов. Вот как это работает: внешний хост подключается к адресу WAN IP. Шлюз заменяет целевой IP-адрес на внутренний IP-адрес перенаправленного хоста и пересылает пакет. Возвратные пакеты из того же TCP-соединения проходят тот же процесс в обратном направлении, где внутренний IP-адрес источника заменяется на IP-адрес WAN-шлюза.

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

Теперь с включенным hairpin: внутренний хост подключается к адресу WAN IP. Шлюз заменяет целевой IP-адрес на внутренний IP-адрес перенаправленного хоста, а адрес источника — на свой собственный, и пересылает пакет. Внутренний хост видит подключение из общего направления шлюза и отправляет ответ туда. Шлюз заменяет адреса источника и назначения на основе своей NAT-таблицы и пересылает ответный пакет запрашивающему хосту, который видит его как часть TCP-соединения, которое он инициировал.

Это всё – распространённое недопонимание, касающееся TCP/IP. Всё маршрутизируется на основе каждого узла. Нет схем, в которых отправитель определяет, как двунаправленный поток передается между конечными точками.

redfive Guest	#8 10.04.2025 13:21:00 Короче, нужно просто включить функцию hairpin, указав правильный lan-интерфейс (например, switch0 или switch0.XY, в общем, интерфейс/ы L3).

daniel.kosieradzki

Guest

10.04.2025 12:01:00

Хм... Мне кажется, это нелогично, потому что, насколько я понимаю, мой локальный трафик, идущий на публичный IP, должен просто маршрутизироваться к публичному IP, и с точки зрения edge router он должен восприниматься как любой другой трафик из публичного интернета... Так часто работало для меня в случаях с облачной инфраструктурой и так далее (например, если мой трафик покидает сеть через какой-то edge router и пытается подключиться к публичному IP этого же router, он считается публичным трафиком). Или... может, мне лучше добавить какое-нибудь правило маршрутизации, потому что мой локальный трафик никогда не покидает LAN?

redfive Guest	#10 10.04.2025 08:39:00 Если hairpin NAT отключен, то, пожалуй, это нормально — эти сервисы из локальной сети не будут доступны по публичному IP-адресу/FQDN.

Читают тему (гостей: 1)