Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Проброс 53(tcp/udp) порта на локальный DNS сервер

    Scheduled Pinned Locked Moved Russian
    5 Posts 2 Posters 2.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H
      Hoper
      last edited by

      Задача по пробросу портов понятна и описана (сделана) много раз.
      работает на этом сервере (2.2.1-RELEASE (i386) ) на реальной машине.
      wan - pppoe (со статикой в несколько IP через Virtual IPs)
      lan - dmz

      Что стоит:

      • System - Advansed - FireWall/NAT - NAT Reflection mode for port forwards = enabled NAT +Proxy

      • Services - DNS forwarder - Disabled

      • WAN - Block private networks - включено,  Block bogon networks - включено

      Правила NAT:

      ATLPULL TCP         * * 1.2.3.4 3389 (MS RDP) 192.168.1.9 3389 (MS RDP) (сделано для теста)
      ATLPULL TCP/UDP * * 1.2.3.4 53 (DNS)    192.168.1.9 53 (DNS)

      Автоматически созданные правила:

      IPv4 TCP         * * 192.168.1.9 3389 (MS RDP) * none
      IPv4 TCP/UDP * * 192.168.1.9 53 (DNS) * none

      Сервер DNS 192.168.1.9 шлюз у него pfSense

      Результаты:
      NMap c pfSense

      Running: /usr/local/bin/nmap  -sU -e bge0 '192.168.1.9'
      
      Starting Nmap 6.47 ( http://nmap.org ) at 2015-03-25 12:23 FET
      Nmap scan report for 192.168.1.9
      Host is up (0.00038s latency).
      Not shown: 998 open|filtered ports
      PORT    STATE SERVICE
      53/udp  open  domain
      
      $sudo nmap -sU -p53 1.2.3.4
      
      Host is up (0.0025s latency).
      PORT   STATE         SERVICE
      53/udp open|filtered domain
      
      

      Попытка запросить у него зону (мы поддерживаем свою зону)

      nslookup info.domain.ltd 1.2.3.4
      ;; connection timed out; no servers could be reached
      

      К RDP подключается
      DNS запросы не выдает  :( , правила, как видите, идентичны.
      В чем может быть проблема? Куда копать?
      ![2015-03-25 12:14:26.png](/public/imported_attachments/1/2015-03-25 12:14:26.png)
      ![2015-03-25 12:14:26.png_thumb](/public/imported_attachments/1/2015-03-25 12:14:26.png_thumb)
      ![2015-03-25 12:14:53.png](/public/imported_attachments/1/2015-03-25 12:14:53.png)
      ![2015-03-25 12:14:53.png_thumb](/public/imported_attachments/1/2015-03-25 12:14:53.png_thumb)

      1 Reply Last reply Reply Quote 0
      • werterW
        werter
        last edited by

        Вы извне проверяете nslookup info.domain.ltd 1.2.3.4 ?

        Логи fw на pf посмотрите при nslookup info.domain.ltd 1.2.3.4

        P.s. При таких условиях я бы еще Suricata прикрутил к pfsense - http://pfsensesetup.com/tag/suricata/

        1 Reply Last reply Reply Quote 0
        • H
          Hoper
          last edited by

          @werter:

          Вы извне проверяете nslookup info.domain.ltd 1.2.3.4 ?

          Угу, с другого канала.
          @werter:

          Логи fw на pf посмотрите при nslookup info.domain.ltd 1.2.3.4

          Что то вот с логами тут не очень хорошо. :( Те что можно смотреть в WEB-интерфейсе как то не очень информативны.
          Что то там упускается. Сейчас разбираюсь на предмет включения полного логирования. И возможности смотреть это дело с консоли.
          @werter:

          P.s. При таких условиях я бы еще Suricata прикрутил к pfsense - http://pfsensesetup.com/tag/suricata/

          Стоял Snort для этого дела, но был снесен для чистоты эксперимента.

          1 Reply Last reply Reply Quote 0
          • werterW
            werter
            last edited by

            Что то вот с логами тут не очень хорошо.  Те что можно смотреть в WEB-интерфейсе как то не очень информативны.

            На предмет блокирования\разрешения - вполне информативны. Другое дело, что далеко не все этим пользуются.
            Вплоть до вопроса "Гы, а де оно включается это логирование ?"

            1 Reply Last reply Reply Quote 0
            • H
              Hoper
              last edited by

              хм, немного не понял логику работы, но проблема решилась таких образом:
              Добавлю к исходным данным.
              интерфейсы: 2 физических 3 логических
              1. LAN (eth0) - это внутренняя сеть DMZ
              2. WAN (xl0) - это провайдер с PPPOE (1.2.3.4)
              3. ATLPULL (xl0) - это статика провайдера (1.2.3.5)
              но поскольку провайдер выдал 8 IP остальные повесил на VirtualIPs (1.2.3.6,7,8,9…) и привязал их к интерфейсу ATLPULL

              В NAT указывал инт. ATLPULL как входящий и дальше выбирал IP из VirtualIPs как Destination и далее редирект -> внутренний сервер:порт
              Все работало для 80,443,3389(для теста :) )!!!
              Делаю копию правила для 53 порта - затуп :(
              Два дня бился, звонил провайдеру - ничего не блокируют (!67,68,1137-139,445 :) )

              От безысходности решил сменить привязку VirtuslIPs, привязать их к WAN. Ну и соответственно в правиле NAT сменил интерфейс ATLPULL -> WAN
              OOOPS!!!  :o - ответило.

              По итогу оказалось, что надо было сразу привязку правила NAT делать к WAN (VirtuslIPs можно оставить на ATLPULL - как то логичнее)

              ![2015-03-27 11:05:25.png](/public/imported_attachments/1/2015-03-27 11:05:25.png)
              ![2015-03-27 11:05:25.png_thumb](/public/imported_attachments/1/2015-03-27 11:05:25.png_thumb)

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.