У меня есть небольшая сеть с маршрутизатором, который поддерживает подключение к Интернету, серверу и некоторым рабочим станциям в локальной сети.
Сервер предназначен для доступа из Интернета, и в iptables маршрутизатора установлено несколько записей DNAT, например:
-A PREROUTING -i ppp0 -p tcp -m multiport --dports 22,25,80,443 -j DNAT --to-destination 192.168.2.10
Внешние пакеты поступают в маршрутизатор через ppp0
интерфейс, а внутренние - из br-lan
коммутатора и адаптера WLAN. Проблема заключается в том, что, хотя внешний доступ работает нормально, попытка получить доступ к серверу изнутри локальной сети по DNS-разрешенному внешнему IP-адресу (назначенному ppp0
) не удалась.
Единственное решение, которое я смог придумать, - это добавить статические записи в /etc/hosts
указатель маршрутизатора на внутренний IP-адрес, но поскольку здесь нет подстановочных знаков (и у меня есть как минимум три домена верхнего уровня, назначенных этой системе, не считая десятков поддоменов), это довольно хрустящий и подверженный сбоям. Можете ли вы предложить что-то лучше?
Я только нашел этот вопрос , который не был очень полезным.
Если это актуально, роутер запускает OpenWRT 10.03 Kamikaze с dnsmasq.
Ответы:
Я удивлен, что спустя почти 8 лет никто не объяснил, как сделать это правильно, используя систему конфигурации UCI, используемую по умолчанию в OpenWRT.
Ответ Стивена Понедельника верен, но он использует
iptables
команды напрямую, что является более низким уровнем, чем система конфигурации UCI, и, по возможности, лучше его не трогать большинством пользователей OpenWRT.Правильный способ доступа к внутренним серверам через их общедоступные комбинации IP / портов с другого внутреннего хоста в UCI состоит в том, чтобы включить параметр конфигурации для
reflection
каждой конкретной цели DNAT в файле/etc/config/firewall
. Это поведение задокументировано здесь .Например:
config redirect option target 'DNAT' option src 'wan' option dest 'lan' option proto 'tcp' option src_dport '44322' option dest_ip '192.168.5.22' option dest_port '443' option name 'apache HTTPS server' option reflection '1'
Примечание. Согласно указанной документации OpenWRT
reflection
по умолчанию включено. В моем тестировании это было не так.источник
Я удалил свой оригинальный ответ, потому что я не был полностью уверен, что он был правильным. С тех пор у меня было некоторое время, чтобы настроить небольшую виртуальную сеть виртуальных машин для симуляции рассматриваемой сети. Вот набор правил брандмауэра, который работал для меня (в
iptables-save
формате, только дляnat
таблицы):Первое
POSTROUTING
правило - это простой способ совместного использования интернет-соединения с локальной сетью. Я оставил это там для полноты.PREROUTING
Правило и второеPOSTROUTING
правило вместе устанавливают соответствующие NATs, так что подключение к серверу через внешний IP - адрес может произойти, независимо от того , соединения происходят из - за пределов или внутри локальной сети. Когда клиенты в локальной сети подключаются к серверу через внешний IP-адрес, сервер видит подключения как исходящие с внутреннего IP-адреса маршрутизатора (192.168.2.1).Интересно, что оказывается, что есть пара вариантов второго правила POSTROUTING, которые также работают. Если цель изменяется на
-j SNAT --to-source 192.168.2.1
, эффект (не удивительно) такой же, какMASQUERADE
: сервер видит соединения от клиентов локальной сети как исходящие с внутреннего IP-адреса маршрутизатора . С другой стороны, если цель изменяется на-j SNAT --to-source 89.179.245.232
, тогда NAT все еще работают, но на этот раз сервер видит подключения клиентов локальной локальной сети как исходящие от внешнего IP-адреса маршрутизатора (89.179.245.232).Наконец, обратите внимание, что исходное
PREROUTING
/DNAT
правило с-i ppp0
не работает, потому что правило никогда не совпадает с пакетами, поступающими от клиентов LAN (так как они не входят в маршрутизатор черезppp0
интерфейс). Можно было бы заставить его работать, добавив второеPREROUTING
правило только для клиентов внутренней ЛВС, но оно было бы не элегантным (IMO) и все равно требовало бы явной ссылки на внешний IP-адрес.Теперь, даже после того, как я подробно изложил решение «шпилька NAT» (или «петля NAT», или «отражение NAT», или как его предпочитают называть), я по-прежнему считаю, что решение DNS с разделением горизонта - - с разрешением внешних клиентов на внешние IP и разрешением внутренних клиентов на внутренние IP --- было бы более приемлемым путем. Почему? Потому что больше людей понимают, как работает DNS, чем понимают, как работает NAT, и большая часть построения хороших систем выбирает использование частей, которые можно обслуживать. Настройка DNS более понятна и, следовательно, правильно поддерживается, чем тайная настройка NAT (конечно, IMO).
источник
Распространенным решением является указание ваших внутренних хостов на локальный DNS-сервер, который возвращает правильный «внутренний» адрес для этих имен хостов.
Другое решение - и мы используем это там, где я работаю на наших брандмауэрах Cisco, - это переписать ответы DNS на брандмауэре, которые соответствуют этим адресам. Я не думаю, что есть инструменты для Linux, которые делают это прямо сейчас.
Вы должны быть в состоянии настроить маршрутизацию на вашем шлюзе для правильной работы. Возможно, вам придется настроить серверы так, чтобы они знали их IP-адрес, отображаемый извне (например, назначив его фиктивному интерфейсу). При такой конфигурации связь от одной внутренней системы к другой внутренней системе - используя ее «внешний» адрес - будет проходить через маршрутизатор.
источник
ip rule add to 89.179.245.232 dev br-lan table 10; ip route add 89.179.245.232 via 192.168.2.10 dev br-lan table 10
и это не работает.То, что вы просите сделать, называется
NAT Loopback
и требует добавления правила SNAT, чтобы пакеты, отправленные из вашей локальной сети на ваш сервер, возвращались через маршрутизатор:источник
-i ppp0
опцию в моем правиле, о котором идет речь, так как он был обработан другой цепочкой; это правило предотвратит маршрутизацию пакетов, поступающих из локальной сети (и если я включу его, пакеты будут отправлены из неверного источника и будут отклонены).Комментарий larsks о размещении внутренней версии пространства имен \ domain - это, как правило, способ решения этой проблемы в прошлом. Конечно, для этого вам нужен внутренний DNS-сервер.
источник
cname
не поддерживает маски и, следовательно, не подходит для меня из-за подсчета поддоменов.Я предложил следующее решение, чтобы разрешить моей гостевой сети подключаться к портам, которые были перенаправлены из моей сети wan на локальную сеть. Этот скрипт находится в моем разделе «Сеть -> Брандмауэр -> Пользовательские правила»:
Для поддержки перезагрузок мне нужно было запустить следующую команду из командной строки ssh на openwrt (в противном случае, я считаю, что есть условие гонки, когда некоторые правила были добавлены, а затем сброшены во время перезагрузки):
Отражение NAT настраивается для соединений внутри сети LAN с самим собой, но не с другими сетями, если вы создали несколько интерфейсов для изоляции трафика. Я попытался настроить правило пересылки из веб-интерфейса, но оно отправляет весь трафик на порт из гостевой сети на этот узел локальной сети. Выше только перехватывает запросы к IP WAN вместо всего сетевого трафика.
Вместо этого можно использовать внутренний DNS, но только в том случае, если переадресация всех портов идет только на один хост. Если у вас несколько хостов, на которые вы перенаправляете разные порты, вы можете повторить правила для разных портов для разных
tgthost
IP-адресов и портов.источник
conntrack
модуль соответствия. И все, что вам нужно, чтобы решить проблему, это использовать одно правило:iptables -t nat -A POSTROUTING --dst <lan-net> ! --src <lan-gw-ip> -m conntrack --ctstate DNAT --ctorigdst <wan-gw-ip> -j MASQUERADE