NAT проблемы проброса портов
-
Доброгое времени суток.
При использовании pfsense 1.2.3 появилась следующая проблема.
Есть маленькая сеть состоящая из: двух независимых серверов (192.168.1.200/24 - веб сервер Linux и 192.168.1.201/24 - игровой сервер Linux), шлюзом (на pfsense WAN - 89...232, LAN - 192.168.1.1/24) и несольких клиентов (Win/Mac 192.168.1.100-199/24).
Интернет и DHCP разаюется все замечательно. Пробросить порты из вне на внутрнение сервера не составляет труда. Люди из вне благополучно обращаються к внутреним серверам.
Проблема возникает когда клиенты из внутреней сети пытаються обратиться через шлюз (WAN - INT_IP:PORT) к внутреним серверам.
P.S.: буду рад помощию
-
http://91.192.71.196/BSDCert/BSDA-course/apcs02.html
C.2.1.6.4. Перенаправление и отражениеПеренаправление часто используется для предоставления доступа внешним машинам к внутреннему серверу:
server = 192.168.1.40
rdr on $ext_if proto tcp from any to $ext_if port 80 -> $server
port 80Однако при тестировании правил перенаправления из внутренней сети они не работают. Дело в том, что пакеты из внутренней сети не проходят через внешний интерфейс шлюза ($ext_if в примере) и потому не подвергаются трансляции.
Добавление второго rdr правила не спасает ситуацию: пакет проходит через внутренний интерфейс, ему заменяют адрес назначения и он направляется на сервер, однако исходящий адрес при этом не исправляется и поэтому сервер будет овечать непосредственно клиенту минуя шлюз. Клиент при этом ждёт ответа от шлюза, а не от сервера. Таким образом, соединение так и не будет установлено.
И всё таки желательно из внутренней сети видеть сервер так же как он виден из внешней и так, чтобы для клиента всё было прозрачно. Существует несколько способов решения этой проблемы.
C.2.1.6.4.1. Создание локального DNS
Сервер DNS можно настроить так, что он будет давать разные ответы в разные сети. Можно сделать так, чтобы локальные клиенты ходили на сервер непосредственно, без помощи шлюза. Такое решение, к тому же, снижает нагрузку на шлюз.
C.2.1.6.4.2. Перемещение сервера в отдельную сеть
Можно переместить сервер в отдельную сеть (см. так же DMZ) и добавить новый сетевой интерфейс в шлюз.
C.2.1.6.4.3. TCP proxy
Можно произвести проксирование TCP соединений при помощи приложений из userspace. Приложение перехватывает соединение, устанавливает соединение с сервером и далее пробрасывает данные через себя. Простейший пример можно сделать при помощи inetd(8) (см. Раздел 5.17.2, «Суперсервер inetd(8)»)и nc(1) (см. Раздел 6.4.4, «telnet(1), nc(1)»). Следующая строка в /etc/inetd.conf(5) создаёт сокет привязанный к кольцевому интерфейсу, порт номер 5000. Соединение пробрасывается на 80-й порт машины 192.168.1.10:
127.0.0.1:5000 stream tcp nowait nobody /usr/bin/nc nc -w 20 192.168.1.10 80
Теперь на внутреннем интерфейсе мы можем связать 80-й порт с нашим proxy-сервером:
rdr on $int_if proto tcp from $int_net to $ext_if port 80 ->
127.0.0.1 port 5000C.2.1.6.4.4. RDR в комбинации с NAT
И наконец, в комбинации с правилом NAT можно достичь того, что трансляция адресов источника так же будет осуществляться и соединение будет устанавливаться ожидаемым образом.
rdr on $int_if proto tcp from $int_net to $ext_if port 80 -> $server
no nat on $int_if proto tcp from $int_if to $int_net
nat on $int_if proto tcp from $int_net to $server port 80 -> $int_ifЭти правила приведут к тому, что первый пакет поступивший от клиента будет заново транслирован, когда будет отправлен через внутренний интерфейс, при этом у него будет подменён адрес источника на внутренний адрес шлюза. Внутренний сервер ответит шлюзу, который вернёт адреса обратно благодаря NAT и RDR трансляциям и пакет отправится к клиенту. Это достаточно сложный приём. Нужна осторожность, чтобы не применить правила NAT к другому трафику, например к внешним соединениям (прошедшим через другие правила rdr) или к соединениям самого шлюза. Так же имейте ввиду, что это преобразование приводит к тому, что TCP/IP стек видит данные пакеты, полученные внутренним интерфейсом, как направляющиеся внутрь сети.
Авторы документации к пакетному фильтру рекомендуют в общем случае использовать какое-нибудь из предыдущих решений вместо последнего.
-
Спасибо буду пробывать.
-
bounce - устанавливается легко ) добавляется в запуск тоже :)
правда не мапит удп, насколько помню… -
А чем "Enable DNS forwarder" (и добавление списка локальных ресурсов туда) не подходит?