Вопрос по опции: "Disable NAT Reflection": [РЕШЕНО]



  • Здравствуйте!

    Подскажите пожалуйста, ЧТО ИМЕННО дает включение/отключение опции "Disable NAT Reflection" (Disables the automatic creation of NAT redirect rules for access to your public IP addresses from within your internal networks. Note: Reflection only works on port forward type items and does not work for large ranges > 500 ports.)?
    Опция находится в System \ Advanced functions: Network Address Translation \ Disable NAT Reflection

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

    Вкратце: с УСТАНОВЛЕННОЙ галочкой на этой опции у меня НЕ ПОЛУЧАЕТСЯ зайти с внутренней подсети на ВНЕШНИЙ адрес (WAN) через который сервера из моей же внутренней подсети опубликованы наружу.

    Поясню свой вопрос подробнее:

    Сервер с pfSense 1.2.3, с 4 интерфейсами, но я упрощу, считая, что их всего два:

    WAN: 11.22.33.44 (белый) –-> LAN: 192.168.0.1/24 -- это подсеть(1)

    В подсети (1) 192.168.0.1/24 опубликованы несколько серверов: SMTP/POP3, WEB и т.д., например:
    192.168.0.2:80, 192.168.0.3:110 и т.д.
    NAT, соответствующие правила Port Forward - созданы.
    Все работает - интернет есть, опубликованные сервера - видны из интернет, по адресам своей подсети - откликаются.

    ПРОБЛЕМА начинается тогда, когда я пытаюсь зайти ПО ВНЕШНЕМУ IP (WAN'овскому) на опубликованные сервера ИЗНУТРИ, с подсети(1) (к примеру - с какого-нибудь из серверов этой подсети).
    Например, если пытаться зайти на WEB (11.22.33.44:80) то открывается веб-консоль pfSense! (по дефолтовому порту).
    Если попробовать достучаться из подсети(1) до любого другого сервиса, опубликованного по внешнему (WAN) IP, то также ожидает неудача.

    Я уже сломал голову, сочинял правила, порт форварды и так далее, уже мозги кипят.
    Похожая проблема была в DLink'е DI604, потом поменяли на D804HV, заработало (там у парня была аналогичная моей проблема). Кажется на своем форуме эту проблему назвали, цитата: "А проблема в локальной петле и NAT'e, кажется её исправили в новой прошивке" и потом вышла прошивка исправленная с "2.Support Virtual Server loopback feature, user can access the virtual servers in the same LAN environment using WAN IP."

    Но! Когда в pfSense я включил опцию "Disable NAT Reflection", то все заработало. И теперь я хочу понять - это именно то что мне нужно, или всего лишь какой-то побочный эффект?

    Подскажите, пожалуйста.

    ps: кстати, а для чего нужен NAT 1:1? Для публикации только одного сервера наружу (DMZ)?



  • Я такое сделал с помощью DNS forwarder. По-моему проще некуда. Например, у нас почтовик в локалке (192.168.0.3), на него проброшены 25 и 110 порты снаружи и он оттуда еще виден по имени mail.domain.tld
    просто заводим в DNS forwarder

    Host  Domain  IP
    mail          domain.tld 192.168.0.3

    в почтовых клиентах, что изнутри, что снаружи, в качестве POP и SMTP серверов ставим mail.domain.tld
    и все работает без всяких заморочек



  • @rubic:

    Я такое сделал с помощью DNS forwarder. По-моему проще некуда. Например, у нас почтовик в локалке (192.168.0.3), на него проброшены 25 и 110 порты снаружи и он оттуда еще виден по имени mail.domain.tld

    Спасибо, я попробую, но это, как мне кажется, несколько другое..
    Всамделишная структура сети несколько сложнее, и у нас в этой подсети стоит DNS-сервер (на Win2003server), также опубликованный наружу. Он поддерживает домен "организация.ru" (для внешних серверов) и "организация.local" - для локальной сети. Соответственно, когда из локальной сети обращаются на "организация.ru", то им выдается внешний IP, на который они и пытаются попасть.
    Я понимаю, что наилучшим вариантом было бы завести 2DNS, либо DNS на *никсе, и уже там сделать разделение для внешних и внутренних запросов, однако на данный момент такое решение невозможно, увы :(



  • Nat reflection i est' to, chto tebe nuzhno. Pochemu ne rabotaet - nado razbirat'sya.
    C vklyuchennym NatReflection (net galki) nado:

    pfctl -sn | grep rdr



  • Что мешает завести ручные NAT-правила вместо Авто-Ната? Там можно четко указать, что нужно пускать через NAT, а что нет.

    Так же имею сомнение, что с LAN > WAN будет работать portforward WAN. Портфорвард меняет dst адрес, оставляя src неизменным. При возвращении LAN пакета назад в LAN не факт, что ответный пойдет тем-же путем. Скорее всего сервер попытается пихнуть его напрямую по адресу src минуя pfsense. А этого клиент не ожидает и коннект не случится.

    Вроде так - поправьте если что.



  • @dvserg:

    Что мешает завести ручные NAT-правила вместо Авто-Ната? Там можно четко указать, что нужно пускать через NAT, а что нет.

    Так же имею сомнение, что с LAN > WAN будет работать portforward WAN. Портфорвард меняет dst адрес, оставляя src неизменным. При возвращении LAN пакета назад в LAN не факт, что ответный пойдет тем-же путем. Скорее всего сервер попытается пихнуть его напрямую по адресу src минуя pfsense. А этого клиент не ожидает и коннект не случится.

    Вроде так - поправьте если что.

    Nat redirection - eto special'niy process. Posemu s Source'ami vsye budet normal'no.



  • @Evgeny:

    Nat reflection i est' to, chto tebe nuzhno. Pochemu ne rabotaet - nado razbirat'sya.
    C vklyuchennym NatReflection (net galki) nado:

    pfctl -sn | grep rdr

    Спасибо за пояснение! Как раз с "отключенной галочкой", т.е. без галочки в пункте "Disable NAT Reflection" (ох, эта путаница с галочками и описаниями), работа происходит как нужно - из LAN есть доступ к серверам опубликованным в LAN по WAN-адресу.

    Я перерыл весь англоязычный форум, в поисках подтверждения своего начального вопроса, вроде так и есть - галочка снимается именно для таких случаев. Об этом даже сказано тут: http://forum.pfsense.org/index.php/topic,7001.0.html - "If you want to be able to use NAT-mappings from withing your own LAN disable the checkbox "Disable NAT Reflection".
    Как я понял, это равнозначно добавлению некоторых правил (знать бы, каких именно, пока только догадываюсь, что что-то связанное с lo0 или 127.0.0.1).
    А при выводе команды pfctl -sn | grep rdr получается следующее:

    
    WAN*  -> em2 -> 195.xxx.yyy.zzz
    LAN*   -> em3 -> 192.168.0.1
    
    # pfctl -sn | grep rdr
    rdr-anchor "pftpx/*" all
    rdr-anchor "slb" all
    no rdr on em3 proto tcp from any to <vpns>port = ftp
    rdr on em3 inet proto tcp from any to any port = ftp -> 127.0.0.1 port 8021
    rdr on em2 inet proto tcp from any to 195.xxx.yyy.zzz port = http -> 192.168.0.253
    rdr on em3 inet proto tcp from any to 195.xxx.yyy.zzz port = http -> 127.0.0.1 port 19000
    rdr on em2 inet proto tcp from any to 195.xxx.yyy.zzz port = domain -> 192.168.0.252
    rdr on em2 inet proto udp from any to 195.xxx.yyy.zzz port = domain -> 192.168.0.252
    rdr on em3 inet proto tcp from any to 195.xxx.yyy.zzz port = domain -> 127.0.0.1 port 19002
    rdr on em3 inet proto udp from any to 195.xxx.yyy.zzz port = domain -> 127.0.0.1 port 19003
    rdr on em2 inet proto tcp from any to 195.xxx.yyy.zzz port = smtp -> 192.168.0.252 port 2525
    rdr on em3 inet proto tcp from any to 195.xxx.yyy.zzz port = smtp -> 127.0.0.1 port 19006
    rdr on em2 inet proto tcp from any to 195.xxx.yyy.zzz port = pop3 -> 192.168.0.252
    rdr on em3 inet proto tcp from any to 195.xxx.yyy.zzz port = pop3 -> 127.0.0.1 port 19008
    rdr on em2 inet proto udp from any to 195.xxx.yyy.zzz port = 1194 -> 192.168.0.252
    rdr on em3 inet proto udp from any to 195.xxx.yyy.zzz port = 1194 -> 127.0.0.1 port 19010
    rdr-anchor "imspector" all
    rdr-anchor "miniupnpd" all
    #</vpns> 
    


  • Да, всё просто. Нужно, чтобы работало, как ты описал - убирай галочку с Disable NAT-reflection. Автоматически появятся перенаправления на 127.0.0.1:80xxx
    Это нельзя сделать правилами.



  • @Evgeny:

    Да, всё просто. Нужно, чтобы работало, как ты описал - убирай галочку с Disable NAT-reflection. Автоматически появятся перенаправления на 127.0.0.1:80xxx
    Это нельзя сделать правилами.

    Спасибо! Тему можно считать закрытой.


Locked