[Решено] Публикация MS SQL



  • Нужно опубликовать MS SQL, на сколько помню это 1433 порт. Недавно тут уже было два поста на тему публикации портов, я их читал от корки до корки и делал все что там написано. Решением в этих постах было снятие галочки с System: Advanced functions: Disable NAT Reflection. В моем случае почему-то этого оказалось недостаточно.
      Установил  pfSense 1.2.2 с нуля. Никаких пакетов не добавлял. Настроил внутренний и внешний интерфейс. Доступ из локалки в инет есть. У меня в локалке 2 подсети (10.1.1.0/24, 192.168.1.0/24), соединены они через win2003(10.1.1.100, 192.168.1.100). Доступ в инет я даю только для 10.1.1.0/24, внутренний интерфейс  pfSense тоже смотрит в 10.1.1.0/24.  MS SQL находится в 192.168.1.1. Настроил статический маршрут:
    LAN   192.168.1.0/24   10.1.1.100
    Из локалки скуль виден.
    Снимаю галочку System: Advanced functions: Disable NAT Reflection.
    Добавляю в Firewall: NAT: Port Forward правила:
    WAN     TCP             1433           192.168.1.1 (ext.: 85.90..)      1433    
    WAN     TCP       3389(MS RDP)     10.1.1.100  (ext.: 85.90..)      3389 (MS RDP)
    Не работает ни RDP, ни SQL.
    В правилах фаервола только :
    TCP   *   *   192.168.1.1   1433          *       NAT    
    TCP   * * 10.1.1.100 3389 (MS RDP) *   NAT

    Запрещающего ничего нет. Вроде все как у всех…Но ни пингов из вне, ничего. Смотрел в диагностике, видно попытки соединится извне к внешнему интерфейсу pfSense по нужным портам, но соединения не происходит.
    У кого какие предложения и предположения на этот счет? Чего я мог не до крутить?



  • не трогал никакие "галочки", просто прописал:

    WAN TCP 5050   192.168.10.2 (ext.: x.x.x.x) 3389

    все работает РДП на внутренний win-сервер

    если испытываешь проблемы, смотри лог фаервола за это время



  • @whitener:

    У меня в локалке 2 подсети (10.1.1.0/24, 192.168.1.0/24), соединены они через win2003(10.1.1.100, 192.168.1.100).

    Это настораживает…

    А каковы default gateways 10.1.1.100 и 192.168.1.1 ?



  • @Eugene:

    Это настораживает…

    А каковы default gateways 10.1.1.100 и 192.168.1.1 ?

    А в чем проблема? просто два шлюза и все



  • решилась проблема следующим образом, дефолтным шлюзом публикуемых серверов нужно было выставить прокси pfSense. А у меня несколько маршрутизаторов для различных целей и по дефолту стояли они,  а не pfSense.
    Всем спасибо!!!



  • @zar0ku1:

    @Eugene:

    Это настораживает…

    А каковы default gateways 10.1.1.100 и 192.168.1.1 ?

    А в чем проблема? просто два шлюза и все

    Как показало вскрытие проблема была в простейшей маршрутизации.



  • @Eugene:

    @zar0ku1:

    @Eugene:

    Это настораживает…

    А каковы default gateways 10.1.1.100 и 192.168.1.1 ?

    А в чем проблема? просто два шлюза и все

    Как показало вскрытие проблема была в простейшей маршрутизации.

    не совсем. ИСА2004 так работала. С самих шлюзов тоже все было доступно. И мне до конца не понятно зачем на скуле мне обязательно нужно указывать по дефолту шлюзом pfSense, ИСА такого не требует. У меня в инет ходили через один шлюз, а из инета доступ в локалку был через другой. pfSense почему-то при маршрутизации с WAN не учитывает статических маршрутов прописанных ручками. В статике явно было заданно, что доступ к 192.168.1.1 идет через шлюз 10.1.1.100. Он игнорировал это правило и искал 192.168.1.1 не обращаясь к 10.1.1.100. Мне пришлось дать 192.168.1.1 еще и айпишник из 10.1.1.0/24 и физически в один свич свести обе подсети (чего делать очень не хотелось).



  • pfSense знал, как найти 192.168.1.1. Скорее всего обратные пакеты не знали дороги. Если всё ещё загадка, то рисуй схему будем разбираться.



  • @Eugene:

    pfSense знал, как найти 192.168.1.1. Скорее всего обратные пакеты не знали дороги. Если всё ещё загадка, то рисуй схему будем разбираться.

    Вот это очень даже может быть… Думаю в этом есть правда))

    сейчас проверим



  • маршрутизация… марщрутизация...
    рисуйте схемы, господа, и все станет понятно


Log in to reply