Здрасьте всем.
От старого админа достался прокси-сервер на FreeBSD 6.1, поднят squid 2.6, с FreeBSD я столкнулся первый раз в жизни.
Перестало работать RDP соединение у директора из дома на рабочий компьютер. При запуске команда netstate -a показывает что RDP открыт, но соединение с домашнего компа не проходит.
Где искать подскажите, или может есть готовые решения для "фри", тогда ткните носом...P.S. запущены какие то unixgate-ы и nat.d (насколько я понимаю они используются для перенаправления из внешней сети по внутренним адресам) но как они настраиваются не нашел (((
>От старого админа достался прокси-сервер на FreeBSD 6.1, поднят squid 2.6, с
>FreeBSD я столкнулся первый раз в жизни.Лучше найти грамотного админа.
rdp на free? открыт? ))
>rdp на free? открыт? ))фря по идее должна перебросить на рабочу машину (виндовую) rdp запрос.
запрос нетстат показывает:
tcp4 0 0 *.3386 *.* LISTEN
tcp4 0 0 *.rdp *.* LISTEN
>>rdp на free? открыт? ))
>
>фря по идее должна перебросить на рабочу машину (виндовую) rdp запрос.
>запрос нетстат показывает:
>tcp4 0 0 *.3386 *.* LISTEN
>tcp4 0 0 *.rdp *.* LISTENsockstat | grep 3386
>>>rdp на free? открыт? ))
>>
>>фря по идее должна перебросить на рабочу машину (виндовую) rdp запрос.
>>запрос нетстат показывает:
>>tcp4 0 0 *.3386 *.* LISTEN
>>tcp4 0 0 *.rdp *.* LISTEN
>
>sockstat | grep 3386я не знаю что это но она вроде выполнилась... по крайней мере ошибку никакую не показало...
PS. ошибку допустил: не tcp4 0 0 *.3386 *.* LISTEN, а tcp4 0 0 *.3306 *.* LISTEN
>[оверквотинг удален]
>>>tcp4 0 0 *.rdp *.* LISTEN
>>
>>sockstat | grep 3386
>
>я не знаю что это но она вроде выполнилась... по крайней мере
>ошибку никакую не показало...
>
>PS. ошибку допустил: не tcp4 0 0 *.3386
>*.* LISTEN, а tcp4 0 0 *.3306
> *.* LISTENсложно приведенную команду в консоль скопипастить???
sockstat
sockstat | grep 3386
>[оверквотинг удален]
>>я не знаю что это но она вроде выполнилась... по крайней мере
>>ошибку никакую не показало...
>>
>>PS. ошибку допустил: не tcp4 0 0 *.3386
>>*.* LISTEN, а tcp4 0 0 *.3306
>> *.* LISTEN
>
>сложно приведенную команду в консоль скопипастить???
>sockstat
>sockstat | grep 3386именно так и сделал
>sockstat - выдал список всех процессов.
>sockstat | grep 3386 - ничего не выдалroot syslogd 385 5 dgram /var/run/logpriv
root syslogd 385 6 udp6 *:514 *:*
root syslogd 385 7 udp4 *:514 *:*
root devd 323 4 stream /var/run/devd.pipe
server# sockstat | grep 3386
server#там конечно больше вышло...
>сложно приведенную команду в консоль скопипастить???
>sockstat
>sockstat | grep 3386порт для рдп - 3389 :)
>
>>сложно приведенную команду в консоль скопипастить???
>>sockstat
>>sockstat | grep 3386
>
>порт для рдп - 3389 :)епта описка ))
топикстартер ввел в заблуждение ))
>[оверквотинг удален]
>FreeBSD я столкнулся первый раз в жизни.
>Перестало работать RDP соединение у директора из дома на рабочий компьютер. При
>запуске команда netstate -a показывает что RDP открыт, но соединение с
>домашнего компа не проходит.
>Где искать подскажите, или может есть готовые решения для "фри", тогда ткните
>носом...
>
>P.S. запущены какие то unixgate-ы и nat.d (насколько я понимаю они используются
>для перенаправления из внешней сети по внутренним адресам) но как они
>настраиваются не нашел (((если все работало, то первое предположение: изменение в настройках Windows XP
взять и проверить на другой Windows XP самостоятельно, если работает - директору
выговор за вредительство.
>[оверквотинг удален]
>>носом...
>>
>>P.S. запущены какие то unixgate-ы и nat.d (насколько я понимаю они используются
>>для перенаправления из внешней сети по внутренним адресам) но как они
>>настраиваются не нашел (((
>
>если все работало, то первое предположение: изменение в настройках Windows XP
>взять и проверить на другой Windows XP самостоятельно, если работает - директору
>
>выговор за вредительство.была перезагрузка фри... а в "автозагрузке" насколько я понял эти перенаправления не стояли, и где щас что искать никто не знает, а старый админ сменил номер
>[оверквотинг удален]
>>>настраиваются не нашел (((
>>
>>если все работало, то первое предположение: изменение в настройках Windows XP
>>взять и проверить на другой Windows XP самостоятельно, если работает - директору
>>
>>выговор за вредительство.
>
>была перезагрузка фри... а в "автозагрузке" насколько я понял эти перенаправления не
>стояли, и где щас что искать никто не знает, а старый
>админ сменил номерПосмотрите содержимое /etc/natd.conf
и добавьте туда, если нету
строкуredirect_port tcp локальный_ip_машины_директора:3389 3389
и потом выполните
/etc/rc.d/natd restart
это верно, если используется natd - а судя по Вашим словам - так оно и есть :)
можете посмотреть
# ipfw show
и /etc/rc.conf
>и /etc/rc.confвсе сделал, дописал. RDP так и не заработал (((
Возможно нужно добавить разрешающее правило в ipfw
>Возможно нужно добавить разрешающее правило в ipfwэто ipfw show
server# ipfw show
00001 52 3088 allow tcp from 195.x.x.87 to me
00002 1437704 329182289 allow tcp from 192.168.1.24 to any
00003 5289578 450762173 skipto 10 ip from 192.168.1.0/24 to me
00004 148847 14341594 skipto 10 ip from 192.168.1.24 to any
00050 33174177 25143623641 divert 8668 ip4 from any to any via 195.x.x.87
00100 1874 819682 allow ip from any to any via lo0
00200 0 0 deny ip from any to 127.0.0.0/8
00300 0 0 deny ip from 127.0.0.0/8 to any
65000 67375551 50417318555 allow ip from any to any
65535 1 64 deny ip from any to any
>>Возможно нужно добавить разрешающее правило в ipfw
>
>это ipfw show192.168.1.24 это не машина с рдп случаем?
Первый шаг - проверить что РДП работает на самом виндовом серве. с локалки РДП доступно?
Второй шаг - проверить rc.conf, грузится ли там натд С ВАШИМ КОНФИГОм.(может быть указан какйто иной файл с конфигом..мало ли :)
Третий шаг - проверить natd.conf в вашем случае там должны быть строки:deny_incoming yes
same_ports yes
dynamic yes
port natd
proxy_only no
interface интерфейсвнешнегоайпишника
redirect_port tcp адрессерверасрдп:3389 внешнийадрессервера:3389строка дениинкомингс-обязательна,иначеваш файрвол ничего не зафайрволит
Но есть одно обстоятельство: у вас странные строчки в файрволе... Доблирующие друг друга правила, ссылки указывающие в никуда... вероятно какието строчки исчезли... некоторые строчки вобще безсмысленны...а стандартно нужных- не хватает...
Не исключено что в вашем сервере еще много сюрпризов.На самом деле лучше всего сделеать трасировку прохождения пакетов через файрвол (просмотреть глазами логи проследив какой пакетик куда не дошел) но для этого у вас вероятно нет опыта.
>[оверквотинг удален]
>
>строка дениинкомингс-обязательна,иначеваш файрвол ничего не зафайрволит
>
>Но есть одно обстоятельство: у вас странные строчки в файрволе... Доблирующие друг
>друга правила, ссылки указывающие в никуда... вероятно какието строчки исчезли... некоторые
>строчки вобще безсмысленны...а стандартно нужных- не хватает...
>Не исключено что в вашем сервере еще много сюрпризов.
>
>На самом деле лучше всего сделеать трасировку прохождения пакетов через файрвол (просмотреть
>глазами логи проследив какой пакетик куда не дошел)как это сделать?
> но для этого
>у вас вероятно нет опыта.четвертый шаг - в ipfw должно быть разрешающее правило
allow tcp from any to хост_RDP dst-port 3389
или правило разрешающее такое
>[оверквотинг удален]
>>
>>Но есть одно обстоятельство: у вас странные строчки в файрволе... Доблирующие друг
>>друга правила, ссылки указывающие в никуда... вероятно какието строчки исчезли... некоторые
>>строчки вобще безсмысленны...а стандартно нужных- не хватает...
>>Не исключено что в вашем сервере еще много сюрпризов.
>>
>>На самом деле лучше всего сделеать трасировку прохождения пакетов через файрвол (просмотреть
>>глазами логи проследив какой пакетик куда не дошел)
>
>как это сделать?поставить логирование..после чего смотреть лог секурити.. ну и конечно же надо понимать как пакетики проходят через файрвол... чтоб толк был от просмотра лога... :)
>
>> но для этого
>>у вас вероятно нет опыта.
>
>четвертый шаг - в ipfw должно быть разрешающее правило
>allow tcp from any to хост_RDP dst-port 3389
>или правило разрешающее такоеНет. такого правила недолжно быть. При использовании ната- проброс порта будет разрулен натом. разрешение такового прямо в файрволе- пустит трафик мимо ната, и соответственно редиректа не произойдет.
а в текущих условиях прохождение этого пакета из ната в локалку- будет обеспечено правилом под номером 100.
а поспорим?
allow tcp from any to хост_RDP dst-port 3389
- располагаясь до правила с divert, оно не принесет вреда так как адрес назначения до divert еще публичный и оно работать на внешнем интерфейсе до divert не будет
- располагаясь после правила с divert, пакет подпадает под правило и пропускается
- при этом стоит заметить, что такой пакет после правила divert считается все еще входящим для внешнего интерфейса.
- повторюсь или другое пропускающее правило.
>а поспорим?
>allow tcp from any to хост_RDP dst-port 3389
>- располагаясь до правила с divert, оно не принесет вреда так как
>адрес назначения до divert еще публичный и оно работать на внешнем
>интерфейсе до divert не будетНет, вы определенно не обладаете должной мерой параноидальности :)))
Пакет который МОЖЕТ пройти по этому правилу - это пакет из сети провайдера прямо во внутреннюю сеть. Может же провайдер смаршрутизировать пакетик от себя в вашу серую сеть? Конечно может :)) Так что никакого публичного адреса там не будет.
Но поскольку остальные пакетики на этот порт мы публикуем в нате, то это правило лишнее.
Более того, в обратную сторону ответный пакет пойдет через нат.. и связь на этом прервется. Может с таком случае это правило тут безвредно? Нет, не безвредно.
Его можно использовать чтобы задосить машинку с РДП. Это потенциальная "трудно-обнаруживаемая дыра".Вобщем размещать это правило до ната- безсмысленно и зловредно.
>- располагаясь после правила с divert, пакет подпадает под правило и пропускается
>
>- при этом стоит заметить, что такой пакет после правила divert считается
>все еще входящим для внешнего интерфейса.
>- повторюсь или другое пропускающее правило.а тут это правило просто лишнее. все и так уже идет через правило нумер 65000.
>[оверквотинг удален]
>>allow tcp from any to хост_RDP dst-port 3389
>>- располагаясь до правила с divert, оно не принесет вреда так как
>>адрес назначения до divert еще публичный и оно работать на внешнем
>>интерфейсе до divert не будет
>
>Нет, вы определенно не обладаете должной мерой параноидальности :)))
>Пакет который МОЖЕТ пройти по этому правилу - это пакет из сети
>провайдера прямо во внутреннюю сеть. Может же провайдер смаршрутизировать пакетик от
>себя в вашу серую сеть? Конечно может :)) Так что никакого
>публичного адреса там не будет.Провайдер может, только только, можно еще до нат поместить правила
deny log logamount 1 ip from any to 192.168.0.0/16 in
deny log logamount 1 ip from any to 172.16.0.0/12 in
deny log logamount 1 ip from any to 10.0.0.0/8 in>Но поскольку остальные пакетики на этот порт мы публикуем в нате,
>то это правило лишнее.
>Более того, в обратную сторону ответный пакет пойдет через нат.. и связь
>на этом прервется. Может с таком случае это правило тут безвредно?
>Нет, не безвредно.
>Его можно использовать чтобы задосить машинку с РДП. Это потенциальная "трудно-обнаруживаемая дыра".
>
>
>Вобщем размещать это правило до ната- безсмысленно и зловредно.от того и говорилось чтобы поставить правило после ната
>
>>- располагаясь после правила с divert, пакет подпадает под правило и пропускается
>>
>>- при этом стоит заметить, что такой пакет после правила divert считается
>>все еще входящим для внешнего интерфейса.
>>- повторюсь или другое пропускающее правило.
>
>а тут это правило просто лишнее. все и так уже идет через
>правило нумер 65000.цитирую.
"- повторюсь или другое пропускающее правило"
>>>Возможно нужно добавить разрешающее правило в ipfw
>>
>>это ipfw show
>
>192.168.1.24 это не машина с рдп случаем?
>192.168.1.24 это машина с файл-сервером, но на нем тоже терминалы пашут. а проброс на машину 192.168.1.9
>[оверквотинг удален]
>строка дениинкомингс-обязательна,иначеваш файрвол ничего не зафайрволит
>
>Но есть одно обстоятельство: у вас странные строчки в файрволе... Доблирующие друг
>друга правила, ссылки указывающие в никуда... вероятно какието строчки исчезли... некоторые
>строчки вобще безсмысленны...а стандартно нужных- не хватает...
>Не исключено что в вашем сервере еще много сюрпризов.
>
>На самом деле лучше всего сделеать трасировку прохождения пакетов через файрвол (просмотреть
>глазами логи проследив какой пакетик куда не дошел) но для этого
>у вас вероятно нет опыта.RDP из локалки работает замечательно... снаружи никак
nat.d не работает совершенно....
em1 внутренний интерфейс
em0 внешний интерфейс
/etc/natd.conf
..
same_ports yes
interface em0
use_sockets yes
unregistered_only yes..
redirect_port tcp 192.168.1.149:3389 3389
..
-------------
Для того, чтобы правила не терялись - пропиши их в файле /etc/rc.firewall.local (так у меня)ipfw show:
.....
10000 divert 8668 ip from any to ВНЕШНИЙ_ИП in via em0
10100 divert 8668 ip from 192.168.1.0/24 to any out via em0
...
10200 allow tcp from any to 192.168.1.149 dst-port 3389 in recv em0
10300 allow tcp from any to 192.168.1.149 dst-port 3389 out via em1
...
Почему natd два правила? Честно - не знаю, но с одним "any to any" были тормоза на исходящий трафик, даже в шелле.
Делаешь этот конфиг, перезапускаешь natd и должно работать.
Всем спасибо.
Проблема решилась написанием:
./unixgate 3389 192.168.1.9 3389 &Тему можно закрывать
>Всем спасибо.
>Проблема решилась написанием:
>./unixgate 3389 192.168.1.9 3389 &
>
>Тему можно закрыватьВы не моглибы показать содержимое этого файла? А то гугл о существовании такой программы не знает...