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 5000

    C.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" (и добавление списка локальных ресурсов туда) не подходит?


Log in to reply