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

whitener · Aug 17, 2009, 12:30 PM

Нужно опубликовать 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 по нужным портам, но соединения не происходит.
У кого какие предложения и предположения на этот счет? Чего я мог не до крутить?

zar0ku1 · Aug 17, 2009, 12:52 AM

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

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

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

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

Eugene · Aug 17, 2009, 1:41 AM

@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 ?

zar0ku1 · Aug 17, 2009, 7:58 AM

@Eugene:

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

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

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

whitener · Aug 17, 2009, 12:29 PM

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

Eugene · Aug 17, 2009, 12:37 PM

@zar0ku1:

@Eugene:

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

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

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

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

whitener · Aug 17, 2009, 1:57 PM

@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 и физически в один свич свести обе подсети (чего делать очень не хотелось).

Eugene · Aug 17, 2009, 1:56 PM

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

whitener · Aug 17, 2009, 1:59 PM

@Eugene:

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

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

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

zar0ku1 · Aug 17, 2009, 9:55 PM

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