форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[ Отслеживать ]

"Редирект соединения в PF"		+/–
Сообщение от niksonnnn (??) on 28-Янв-07, 17:13
Доброго времени суток всем. Столкнулся с интересной проблемой, не получается сделать редирект из внешней сети на внутренние IP. Что имеем- 1) FreeBSD 6.0-RELEASE 2) pf фильтр (ядро компилировал с опциями) options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ device pf device pflog device pfsync Кури маны.... http://www.opennet.me/base/net/pf_faq.txt.html http://www.opennet.me/base/sec/pf_openbsd_altq.txt.html Всё работает на ура, вот только не удается перебросить траффик скажем с какого-нибудь внешнего адреса для протокола RDP (порт 3389) на внутренний сервер, обратное соединение работает. Может для редиректа нужно что нибудь указывать в ядре? ПОмогите ПОЖАЛУЙСТА, с утра бьюсь и ничего, перекурил множество манов и нифига.... Знаю что руки кривые, но не настолько же... pf.conf cat /etc/pf.conf . ext_if="rl0"    #  external interface int_if="fxp0"   # internal interface internal_net="192.168.0.0/24" external_addr="192.168.*.*" # СЕРАЯ СЕТЬ ПРОВА table <boss> { 192.168.0.70, 192.168.0.1, 192.168.0.110, 192.168.0.112, 192.168.0.2, 192.168.0.10 } # Options: tune the behavior of pf, default values are given. set timeout { interval 10, frag 30 } set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 } set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 } set timeout { udp.first 60, udp.single 30, udp.multiple 60 } set timeout { icmp.first 20, icmp.error 10 } set timeout { other.first 60, other.single 30, other.multiple 60 } set timeout { adaptive.start 0, adaptive.end 0 } set limit { states 10000, frags 5000 } set loginterface none set optimization normal set block-policy drop set require-order yes set fingerprints "/etc/pf.os" scrub in all nat on $ext_if from <boss> to any -> *.*.*.* # ВНЕШНИЙ ip организации rdr on $ext_if proto tcp from any to *.*.*.* # ВНЕШНИЙ ip организации port 3389 -> 192.168.0.10 port 3389 pass in all pass out all Как видно всё и всем разрешено. (ПОКА)))) Надеюсь на помощь OpenSource братии.
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Редирект соединения в PF"		+/–
Сообщение от kam (ok) on 28-Янв-07, 17:54
>Доброго времени суток всем. > >Столкнулся с интересной проблемой, не получается сделать редирект из внешней сети на >внутренние IP. >Что имеем- >1) FreeBSD 6.0-RELEASE >2) pf фильтр (ядро компилировал с опциями) > > >options ALTQ >options ALTQ_CBQ >options ALTQ_RED >options ALTQ_RIO >options ALTQ_HFSC >options ALTQ_CDNR >options ALTQ_PRIQ > >device pf >device pflog >device pfsync > >Кури маны.... >http://www.opennet.me/base/net/pf_faq.txt.html >http://www.opennet.me/base/sec/pf_openbsd_altq.txt.html > >Всё работает на ура, вот только не удается перебросить траффик скажем с >какого-нибудь внешнего адреса для протокола RDP (порт 3389) на внутренний сервер, >обратное соединение работает. > >Может для редиректа нужно что нибудь указывать в ядре? >ПОмогите ПОЖАЛУЙСТА, с утра бьюсь и ничего, перекурил множество манов и нифига.... >Знаю что руки кривые, но не настолько же... > >pf.conf > >cat /etc/pf.conf >. >ext_if="rl0"    #  external interface >int_if="fxp0"   # internal interface >internal_net="192.168.0.0/24" >external_addr="192.168.*.*" # СЕРАЯ СЕТЬ ПРОВА > >table <boss> { 192.168.0.70, 192.168.0.1, 192.168.0.110, 192.168.0.112, 192.168.0.2, 192.168.0.10 } > ># Options: tune the behavior of pf, default values are given. >set timeout { interval 10, frag 30 } >set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 } >set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 } >set timeout { udp.first 60, udp.single 30, udp.multiple 60 } >set timeout { icmp.first 20, icmp.error 10 } >set timeout { other.first 60, other.single 30, other.multiple 60 } >set timeout { adaptive.start 0, adaptive.end 0 } >set limit { states 10000, frags 5000 } >set loginterface none >set optimization normal >set block-policy drop >set require-order yes >set fingerprints "/etc/pf.os" > >scrub in all > >nat on $ext_if from <boss> to any -> *.*.*.* # ВНЕШНИЙ ip организации > >rdr on $ext_if proto tcp from any to *.*.*.* # ВНЕШНИЙ ip организации port 3389 -> 192.168.0.10 port 3389 > >pass in all >pass out all > >Как видно всё и всем разрешено. (ПОКА)))) > > >Надеюсь на помощь OpenSource братии. Приветствую! Посмотри tcpdump-ом на интерфейсах что происходит?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Редирект соединения в PF"		+/–
Сообщение от EL (??) on 28-Янв-07, 19:28
>Всё работает на ура, вот только не удается перебросить траффик скажем с >какого-нибудь внешнего адреса для протокола RDP (порт 3389) на внутренний сервер, >обратное соединение работает. > >rdr on $ext_if proto tcp from any to *.*.*.* # ВНЕШНИЙ ip организации port 3389 -> 192.168.0.10 port 3389 в 6.0-release должно работать и так, если более свежая, то rdr pass далее по тексту
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Редирект соединения в PF"		+/–
Сообщение от yuriy (??) on 28-Янв-07, 19:44
> >nat on $ext_if from <boss> to any -> *.*.*.* # ВНЕШНИЙ ip организации > >rdr on $ext_if proto tcp from any to *.*.*.* # ВНЕШНИЙ ip организации port 3389 -> 192.168.0.10 port 3389 rdr on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 port 3389 точно будет работать, в доке написано, что сначала идет nat и только потом правило перенаправления потока. Можно попробовать такое правило перенаправление rdr on $ext_if proto tcp from any to 192.168.0.10 port 3389 -> 192.168.0.10 port 3389
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Редирект соединения в PF"		+/–
	Сообщение от niksonnnn (??) on 29-Янв-07, 07:45
	>> >>nat on $ext_if from <boss> to any -> *.*.*.* # ВНЕШНИЙ ip организации >> >>rdr on $ext_if proto tcp from any to *.*.*.* # ВНЕШНИЙ ip организации port 3389 -> 192.168.0.10 port 3389 >rdr on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 port 3389 > >точно будет работать, в доке написано, что сначала идет nat и только >потом правило перенаправления потока. >Можно попробовать такое правило перенаправление >rdr on $ext_if proto tcp from any to 192.168.0.10 port 3389 -> 192.168.0.10 port 3389 К сожалению не работает((((
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Редирект соединения в PF"		+/–
	Сообщение от niksonnnn (??) on 29-Янв-07, 10:09
	Я понимаю, что это не проблема для спецов .... Ни один из вышеуказанных вариантов не работает... Ткните мордой на ошибку пожалуйста ))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Редирект соединения в PF"		+/–
	Сообщение от Саша (??) on 29-Янв-07, 10:11
	>Я понимаю, что это не проблема для спецов .... Ни один из >вышеуказанных вариантов не работает... Ткните мордой на ошибку пожалуйста )) rdr pass on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 port 3389
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Редирект соединения в PF"		+/–
	Сообщение от niksonnnn (??) on 29-Янв-07, 10:40
	>>Я понимаю, что это не проблема для спецов .... Ни один из >>вышеуказанных вариантов не работает... Ткните мордой на ошибку пожалуйста )) > > >rdr pass on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 port 3389 интересно, чем отличается приведенное правило от приведенных выше? Не работает оно.... что еще можно подкрутить? как проверить? Нужно чтобы извне при подключении на <ext IP> можно было зайти на внутренний сервер скажем 192.168.0.1 по протоколу RDP.... Таких серверов у меня 4 (для каждого было правило в Винроуте Керио... работало на ура....) и pf почемуто не хочет редиректить пакеты к ним... Если нужно еще какую нибудь информацию я предоставлю... Мне нужен совет. Добры люди ПОМОГИИТЕ!!!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Редирект соединения в PF"		+/–
	Сообщение от Саша (??) on 29-Янв-07, 10:44
	>>>Я понимаю, что это не проблема для спецов .... Ни один из >>>вышеуказанных вариантов не работает... Ткните мордой на ошибку пожалуйста )) >> >> >>rdr pass on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 port 3389 > > >интересно, чем отличается приведенное правило от приведенных выше? > >Не работает оно.... что еще можно подкрутить? как проверить? Блин, чем отличается написано в man pf.conf:      If the pass modifier is given, packets matching the translation rule are      passed without inspecting the filter rules:      rdr pass on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 \            port 8080 Тем и отличается, что не фильтруется, а сразу выполняется. Смотреть надо, может с чем другим напутано
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Редирект соединения в PF"		+/–
	Сообщение от niksonnnn (??) on 29-Янв-07, 11:39
	>>>>Я понимаю, что это не проблема для спецов .... Ни один из >>>>вышеуказанных вариантов не работает... Ткните мордой на ошибку пожалуйста )) >>> >>> >>>rdr pass on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 port 3389 >> >> >>интересно, чем отличается приведенное правило от приведенных выше? >> >>Не работает оно.... что еще можно подкрутить? как проверить? >Блин, чем отличается написано в man pf.conf: >     If the pass modifier is given, packets >matching the translation rule are >     passed without inspecting the filter rules: > >     rdr pass on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 \ >           port >8080 > >Тем и отличается, что не фильтруется, а сразу выполняется. Пробовал и так и эдак не работает и всё.... Как начать проверку системы или какие контрольные точки нужно проверить? >Смотреть надо, может с чем другим напутано
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Редирект соединения в PF"		+/–
	Сообщение от Саша (??) on 29-Янв-07, 12:05
	>>>>>Я понимаю, что это не проблема для спецов .... Ни один из >>>>>вышеуказанных вариантов не работает... Ткните мордой на ошибку пожалуйста )) >>>> >>>> >>>>rdr pass on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 port 3389 >>> >>> >>>интересно, чем отличается приведенное правило от приведенных выше? >>> >>>Не работает оно.... что еще можно подкрутить? как проверить? >>Блин, чем отличается написано в man pf.conf: >>     If the pass modifier is given, packets >>matching the translation rule are >>     passed without inspecting the filter rules: >> >>     rdr pass on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 \ >>           port >>8080 >> >>Тем и отличается, что не фильтруется, а сразу выполняется. > >Пробовал и так и эдак не работает и всё.... Как начать проверку >системы или какие контрольные точки нужно проверить? >>Смотреть надо, может с чем другим напутано tcpdump-ом внешний интерфейс послушать для начала, наверное. Убрать все из pf.conf, кроме rdr .... и слушать. Хотя там и убирать-то вроде нечего, одни опции, тем не менее оставить только rdr. pftop запустить в отдельной консоли.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Редирект соединения в PF"		+/–
	Сообщение от niksonnnn (??) on 29-Янв-07, 14:25
	>>>>>>Я понимаю, что это не проблема для спецов .... Ни один из >>>>>>вышеуказанных вариантов не работает... Ткните мордой на ошибку пожалуйста )) >>>>> >>>>> >>>>>rdr pass on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 port 3389 >>>> >>>> >>>>интересно, чем отличается приведенное правило от приведенных выше? >>>> >>>>Не работает оно.... что еще можно подкрутить? как проверить? >>>Блин, чем отличается написано в man pf.conf: >>>     If the pass modifier is given, packets >>>matching the translation rule are >>>     passed without inspecting the filter rules: >>> >>>     rdr pass on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 \ >>>           port >>>8080 >>> >>>Тем и отличается, что не фильтруется, а сразу выполняется. ничего не нарыл(((( вернее ничего странного не нашел... Есть идеи? >> >>Пробовал и так и эдак не работает и всё.... Как начать проверку >>системы или какие контрольные точки нужно проверить? >>>Смотреть надо, может с чем другим напутано > >tcpdump-ом внешний интерфейс послушать для начала, наверное. >Убрать все из pf.conf, кроме rdr .... и слушать. >Хотя там и убирать-то вроде нечего, одни опции, >тем не менее оставить только rdr. >pftop запустить в отдельной консоли.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Редирект соединения в PF"		+/–
	Сообщение от yuriy (ok) on 29-Янв-07, 18:08
	>rdr pass on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 port 3389 > > >     rdr pass on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 \ >           port 8080 > Вполне возможно ты не видишь, или мы не видим твоей ошибки. Но судя по описанной конфигурации pf.conf у тебя два интерфейса один внешний и смотрит в Internet, другой держит внутренную сеть. Вернемся к исходной конфигурации. сначала nat log on $ext_if from <boss> to nay -> ($ext_if) потом rdr on $ext_if proto tcp from any to $ext_if port 3389 -> 192.168.0.10 port 3389 pass in log all pass out log all короче давай попробуем журналировать пакеты и соответственно проанализировать данные пакета адресс источника и адресс назначения, то есть проверить работу фильтра. rc.conf pflog_enable="YES" и еще, переменная ядра net.inet.ip.forwarding=1 обязательно. второе обязательно должен быть маршрут по умолчанию на внешную карту, ну и твоя сеть тоже должен иметь маршрут с интерфейсов внутренней карты. ( вроде ты говорил, что во вне соединения проходять проверь)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Редирект соединения в PF"		+/–
	Сообщение от niksonnnn (??) on 30-Янв-07, 10:55
	Спасибо за ответ) >>rdr pass on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 port 3389 >> >> >>     rdr pass on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 \ >>           port 8080 >> >Вполне возможно ты не видишь, или мы не видим твоей ошибки. >Но судя по описанной конфигурации pf.conf у тебя два интерфейса один внешний > >и смотрит в Internet, другой держит внутренную сеть. >Вернемся к исходной конфигурации. > > >сначала >nat log on $ext_if from <boss> to nay -> ($ext_if) > >потом >rdr on $ext_if proto tcp from any to $ext_if port 3389 -> 192.168.0.10 port 3389 > >pass in log all >pass out log all > >короче давай попробуем журналировать пакеты и соответственно проанализировать >данные пакета адресс источника и адресс назначения, то есть проверить >работу фильтра. Как проанализировать пакеты? смотрел файл однако ничего кроме кривулек непонятных не увидел.... >rc.conf >pflog_enable="YES" >и еще, >переменная ядра net.inet.ip.forwarding=1 обязательно. Это включено.... Также включено gateway_enable="YES" нужно это или нет? >второе обязательно должен быть маршрут по умолчанию на внешную карту, Как проверить этот маршрут? Я просто не знаю как это сделать ((( >ну и твоя сеть тоже должен иметь маршрут с интерфейсов внутренней карты. >( вроде ты говорил, что во вне соединения проходять проверь) Внутреняя сеть прекрасно НАТится во внешнюю, однако ничего боле... Надеюсь на помошь начинающему ))))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Редирект соединения в PF"		+/–
	Сообщение от niksonnnn (??) on 30-Янв-07, 18:26
	>Спасибо за ответ) >>>rdr pass on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 port 3389 >>> >>> >>>     rdr pass on $ext_if proto tcp from any to any port 80 -> 127.0.0.1 \ >>>           port 8080 >>> >>Вполне возможно ты не видишь, или мы не видим твоей ошибки. >>Но судя по описанной конфигурации pf.conf у тебя два интерфейса один внешний >> >>и смотрит в Internet, другой держит внутренную сеть. >>Вернемся к исходной конфигурации. >> >> >>сначала >>nat log on $ext_if from <boss> to nay -> ($ext_if) >> >>потом >>rdr on $ext_if proto tcp from any to $ext_if port 3389 -> 192.168.0.10 port 3389 >> >>pass in log all >>pass out log all >> >>короче давай попробуем журналировать пакеты и соответственно проанализировать >>данные пакета адресс источника и адресс назначения, то есть проверить >>работу фильтра. >Как проанализировать пакеты? смотрел файл однако ничего кроме кривулек непонятных не увидел.... > >>rc.conf >>pflog_enable="YES" >>и еще, >>переменная ядра net.inet.ip.forwarding=1 обязательно. >Это включено.... >Также включено gateway_enable="YES" нужно это или нет? >>второе обязательно должен быть маршрут по умолчанию на внешную карту, >Как проверить этот маршрут? Я просто не знаю как это сделать ((( > >>ну и твоя сеть тоже должен иметь маршрут с интерфейсов внутренней карты. >>( вроде ты говорил, что во вне соединения проходять проверь) >Внутреняя сеть прекрасно НАТится во внешнюю, однако ничего боле... > > >Надеюсь на помошь начинающему )))) HELP!!!!!!!!!!!!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Редирект соединения в PF"		+/–
	Сообщение от yuriy (??) on 30-Янв-07, 18:35
	>>сначала >>nat log on $ext_if from <boss> to nay -> ($ext_if) >> >>потом >>rdr on $ext_if proto tcp from any to $ext_if port 3389 -> 192.168.0.10 port 3389 >> >>pass in log all >>pass out log all >> >>Как проанализировать пакеты? смотрел файл однако ничего кроме кривулек непонятных не >>увидел.... Вообще-то, надо что-нибудь почитать по pf. ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf По журналированию в документе отдельная глава. просмотр файла pf.log tcpdump -n -tttt -e -r pf.log | more или tcpdump -n -tttt -e -i /dev/pflog0 или tail -f pf.log | tcpdump -n -tttt -e -r - | more вывод заголовка пакетов, соответственно можно посмотреть адресса источника и назначения. и еще попробуй такое правило перенаправления rdr on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 именно такое не как иначе. Как я понимаю, твой рутер уже смотрит в инет. Короче предложение такое: отключи свой рутер от инета возми тачку с той-же freebsd установи соответствующий адрес ( в той-же подсети внешней карты) соедини их кросс-овером. и теперь можно спокойно все потестить самому, а не просить кого-то запустить что-нибудь. Тесты. С внешней тачки проверить соединения с тестируемым сервером, соответственно послушать интерфейсы, посмотреть входящие пакеты, соответственно посмотреть исходящие пакеты на интерфейсе внутренней сети, используй прогамму nc (net cat) на соответствующем порту. Такая схема используется для проверки правил firewall различными пакетами как nmap и т.д. вообщем ты тоже этом можешь сделать.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Редирект соединения в PF"		+/–
	Сообщение от niksonnnn (??) on 31-Янв-07, 06:58
	>>>сначала >>>nat log on $ext_if from <boss> to nay -> ($ext_if) >>> >>>потом >>>rdr on $ext_if proto tcp from any to $ext_if port 3389 -> 192.168.0.10 port 3389 >>> >>>pass in log all >>>pass out log all >>> >>>Как проанализировать пакеты? смотрел файл однако ничего кроме кривулек непонятных не >>увидел.... >Вообще-то, надо что-нибудь почитать по pf. ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf >По журналированию в документе отдельная глава. >просмотр файла pf.log >tcpdump -n -tttt -e -r pf.log | more >или tcpdump -n -tttt -e -i /dev/pflog0 >или tail -f pf.log | tcpdump -n -tttt -e -r - | >more > >вывод заголовка пакетов, соответственно можно посмотреть адресса источника и назначения. > >и еще попробуй такое правило перенаправления >rdr on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 >именно такое не как иначе. > >Как я понимаю, твой рутер уже смотрит в инет. Короче предложение такое: > >отключи свой рутер от инета >возми тачку с той-же freebsd установи соответствующий адрес ( в той-же подсети >внешней карты) >соедини их кросс-овером. >и теперь можно спокойно все потестить самому, а не просить кого-то запустить >что-нибудь. > >Тесты. >С внешней тачки проверить соединения с тестируемым сервером, соответственно послушать интерфейсы, посмотреть >входящие пакеты, соответственно посмотреть исходящие пакеты на интерфейсе внутренней сети, используй >прогамму nc (net cat) на соответствующем порту. >Такая схема используется для проверки правил firewall различными пакетами как nmap и >т.д. >вообщем ты тоже этом можешь сделать. ОК спасибо))) Буду ковырять...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Редирект соединения в PF"		+/–
	Сообщение от niksonnnn (??) on 08-Фев-07, 22:39
	>>>>сначала >>>>nat log on $ext_if from <boss> to nay -> ($ext_if) >>>> >>>>потом >>>>rdr on $ext_if proto tcp from any to $ext_if port 3389 -> 192.168.0.10 port 3389 >>>> >>>>pass in log all >>>>pass out log all >>>> >>>>Как проанализировать пакеты? смотрел файл однако ничего кроме кривулек непонятных не >>увидел.... >>Вообще-то, надо что-нибудь почитать по pf. ftp://ftp.openbsd.org/pub/OpenBSD/doc/pf-faq.pdf >>По журналированию в документе отдельная глава. >>просмотр файла pf.log >>tcpdump -n -tttt -e -r pf.log | more >>или tcpdump -n -tttt -e -i /dev/pflog0 >>или tail -f pf.log | tcpdump -n -tttt -e -r - | >>more >> >>вывод заголовка пакетов, соответственно можно посмотреть адресса источника и назначения. >> >>и еще попробуй такое правило перенаправления >>rdr on $ext_if proto tcp from any to any port 3389 -> 192.168.0.10 >>именно такое не как иначе. >> >>Как я понимаю, твой рутер уже смотрит в инет. Короче предложение такое: >> >>отключи свой рутер от инета >>возми тачку с той-же freebsd установи соответствующий адрес ( в той-же подсети >>внешней карты) >>соедини их кросс-овером. >>и теперь можно спокойно все потестить самому, а не просить кого-то запустить >>что-нибудь. >> >>Тесты. >>С внешней тачки проверить соединения с тестируемым сервером, соответственно послушать интерфейсы, посмотреть >>входящие пакеты, соответственно посмотреть исходящие пакеты на интерфейсе внутренней сети, используй >>прогамму nc (net cat) на соответствующем порту. >>Такая схема используется для проверки правил firewall различными пакетами как nmap и >>т.д. >>вообщем ты тоже этом можешь сделать. > > >ОК спасибо))) Буду ковырять... Всё дошло до того, что снес всё на ноль... работает в предыдущей конфигурации без проблем..... НЕПОНЯТНО, но можно закрыть тему ...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Редирект соединения в PF"		+/–
	Сообщение от yuriy (??) on 10-Фев-07, 17:41
	> >Всё дошло до того, что снес всё на ноль... работает в предыдущей >конфигурации без проблем..... НЕПОНЯТНО, но можно закрыть тему ... Точно все заработало или все таки нет. Ты смог протестить свой межсетевой экран? Сначала ты говорил что не работает. Или причина была в другом, типа настройки винды по безопасности для работы с удаленным столом. Если так, то так и скажи, это просто означает, что правила pf фильтра ты сразу понял и правильно написал, а винда это винда, бывает на простой проблемой тратишь кучу времени что-бы это заставить работать и непонятно, почему делаешь правильно, а не работает. This is a Windows. А методика тестирования, которую я описал, не я придумал, придумали люди, до которой я тоже дошел сам и с помощью других. Это нормально. Для изучения DNS системы я дома построил свою собственную распределенную систему DNS получил огромный кайф, когда все заработало. Это свое рода секс. Пока, если есть что сказать скажи, тему закроем.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Редирект соединения в PF"		+/–
	Сообщение от niksonnnn (??) on 14-Фев-07, 19:32
	>> >>Всё дошло до того, что снес всё на ноль... работает в предыдущей >>конфигурации без проблем..... НЕПОНЯТНО, но можно закрыть тему ... > >Точно все заработало или все таки нет. Ты смог протестить свой межсетевой >экран? >Сначала ты говорил что не работает. Или причина была в другом, типа > >настройки винды по безопасности для работы с удаленным столом. >Если так, то так и скажи, это просто означает, что правила pf >фильтра >ты сразу понял и правильно написал, а винда это винда, бывает >на простой проблемой тратишь кучу времени что-бы это заставить работать >и непонятно, почему делаешь правильно, а не работает. This is a Windows. > >А методика тестирования, которую я описал, не я придумал, придумали люди, >до которой я тоже дошел сам и с помощью других. Это нормально. >Для изучения >DNS системы я дома построил свою собственную распределенную систему DNS >получил огромный кайф, когда все заработало. Это свое рода секс. >Пока, если есть что сказать скажи, тему закроем. Извиняюсь за долгое молчание но я просто переезжал в Москву))) Нет ничего не получилось у меня для того чтобы поднять pf под конкретную сеть... НАТ работал... причем НАТ работал так, что или для всех или не для кого... немного странно, однако аналогичная схема сейчас работает под винду... ИМХО я просто недоглядел, и в связи с очень ограниченным интервалом времени (у меня было всего несколько часов чтобы поднять сервер на freeBSD ) просто что-то не срослось. На днях буду крутить другой сервер, и вполне возможно будет ясно почему не работал этот злополучный редирект. Могу сказать одно, что не нашел конкретного описания поднятия файрволла на основе pf именно для новичков (step-by-step)... ИМХО это нужно менять, ведь чем больше людей будут заниматься BSD системами, тем больше будет прогресс и скорее эволюция этой действительно замечательной ОС. Если у кого есть что добавить, добавляйте... )))) Всем спасибо. А насчет секса то это верно, испытывал множество раз аналогичное)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Редирект соединения в PF"		+/–
	Сообщение от bakake on 15-Фев-07, 20:34
	>rdr on $ext_if proto tcp from any to $ext_if port 3389 -> 192.168.0.10 port 3389 Вобщем дело плохо, если я правильно понимаю: пакеты приходящие на внешний ип имеют адрес_источника:порт_источника->внешний_адрес_шлюза:3389. После получения пакеты без изменений переправляются на 192.168.0.10:3389. Что происходит дальше: 192.168.0.10:3389 получает пакет с адресом назначения НЕ 192.168.0.10 а внешний_адрес_шлюза. Если интерфейс 192.168.0.10 не настроен на "неразборчивый (promiscuous) режим", что строго говоря является обычным состоянием интерфейса, и не является интерфейсом роутера (что тоже вероятнее всего),  то пакеты просто сбрасываются как предназначенные не для 192.168.0.10. В итоге -- такая схема просто не будет работать никогда, потому что принципиально неверная. Чтобы это заработало, необходимо настроить либо destination nat (что наверно можно сделать средствами pf), либо реверсный прокси, например rinetd, что гораздо проще
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Редирект соединения в PF"		+/–
	Сообщение от bakake on 15-Фев-07, 23:07
	А вот еще вариант, на фре кажется работало, как будет на винде не знаю. К 192.168.0.10 прописать алиас в виде внешнего ип и маски 255.255.255.255, ну может быть еще ip форвардинг включить. В теории должно работать, хотя это по моему полный изврат.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Редирект соединения в PF"		+/–
	Сообщение от niksonnnn (??) on 16-Фев-07, 10:34
	>>rdr on $ext_if proto tcp from any to $ext_if port 3389 -> 192.168.0.10 port 3389 > >Вобщем дело плохо, если я правильно понимаю: пакеты приходящие на внешний ип имеют адрес_источника:порт_источника->внешний_адрес_шлюза:3389. После получения пакеты без изменений переправляются на 192.168.0.10:3389. Что происходит дальше: 192.168.0.10:3389 получает пакет с адресом назначения НЕ 192.168.0.10 а внешний_адрес_шлюза. Если интерфейс 192.168.0.10 не настроен на "неразборчивый (promiscuous) режим", что строго говоря является обычным состоянием интерфейса, и не является интерфейсом роутера (что тоже вероятнее всего),  то пакеты просто сбрасываются как предназначенные не для 192.168.0.10. В итоге -- такая схема просто не будет работать никогда, потому что принципиально неверная. >Чтобы это заработало, необходимо настроить либо destination nat (что наверно можно сделать >средствами pf), либо реверсный прокси, например rinetd, что гораздо проще Спасибо за совет, попробую на выходных))) Обязательно отпишусь... rinetd поднять не получилось. (((
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Редирект соединения в PF"		+/–
	Сообщение от yuriy (??) on 16-Фев-07, 21:57
	> >Спасибо за совет, попробую на выходных))) Обязательно отпишусь... > >rinetd поднять не получилось. ((( Как я понял, ты хочешь управлять виндой с помощью удаленного стола или The Terminal client or Server. На прошлой неделе я столкнулся с этим зверем. Пришлось решать задачу, подобную твоей. Отличия болшьшие но я не вижу большой разницы. Короче, я не знаю Windows 2003 и так далее, но я знаю точно, что винда дура, и работает (во многих случаех) по своему (старому) протоколу NetBIOS. Который до сих пор поддерживается и все современные навороты (домен-контролер и вся безопасность) работает через него. Поэтому, я думаю что твой редирект работает, а не работает бля дурацкая бля аутентификация NetBIOS бля разрешения имен Windows. Проверить прохождение пакетов можно с помощью LiveCD FreeBSD Frenzy прог NC которая открывает порт какой тебе нужен и ловит пакеты и ты можешь легко проверить твой роутер, если все хорошо, дальше винда, с ее замысловатыми проблемами. Одно могу сказать, что NeтBios не маршрутизируемый протокол, для обеспечения разрешения имен NetBIOS необходимо иметь файл lmhosts (%WINHOME/system32/drivers/etc) или сервер с базой WINS. Уверяю, на этом не мало людей сломало копий. И я в том числе. Если у тебя есть в этой сети домен-контроллер, обязательно надо иметь разрешения имен NetBIOS. Иначе нихрена не работает. Пока. Пятница День программиста и системного администратора.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Редирект соединения в PF"		+/–
	Сообщение от niksonnnn (??) on 24-Фев-07, 11:14
	Всем огромное спасибо в оказанной помощи. Сегодня вопрос окончательно закрыт с помощью rinetd. Однако возник вопрос, как замаскировать сервис на 3389 порту... от сканирования и вообще от всяких хулиганов Огромное спасибо всем кто помог разобраться))))
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Редирект соединения в PF"		+/–
	Сообщение от zavad (??) on 04-Июл-08, 10:20
	>Всем огромное спасибо в оказанной помощи. Сегодня вопрос окончательно закрыт с помощью >rinetd. Однако возник вопрос, как замаскировать сервис на 3389 порту... от >сканирования и вообще от всяких хулиганов > >Огромное спасибо всем кто помог разобраться)))) Можно и без rinetd rdr inet proto tcp from any to 192.168.5.1 port 9080 -> 192.168.5.3 port 80 nat inet proto tcp from any to 192.168.5.3 port 80 -> 192.168.5.1
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Редирект соединения в PF"		+/–
	Сообщение от niksonnnn (??) on 04-Июл-08, 18:10
	>>Всем огромное спасибо в оказанной помощи. Сегодня вопрос окончательно закрыт с помощью >>rinetd. Однако возник вопрос, как замаскировать сервис на 3389 порту... от >>сканирования и вообще от всяких хулиганов >> >>Огромное спасибо всем кто помог разобраться)))) > >Можно и без rinetd > >rdr inet proto tcp from any to 192.168.5.1 port 9080 -> 192.168.5.3 port 80 >nat inet proto tcp from any to 192.168.5.3 port 80 -> 192.168.5.1 Спасибо за совет. Но: 1) Разговор шел про 3389.... 2) вЕнда есть вЕнда... не всё гладко было и с ней. 3) Ваш вариант ИЗНАЧАЛЬНО не прошел. 4) Вопрос закрыт 5) Спасибо за отклик. Хороших выходных.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Редирект соединения в PF"		+/–
	Сообщение от syn on 11-Ноя-09, 02:29
	>>rdr on $ext_if proto tcp from any to $ext_if port 3389 -> 192.168.0.10 port 3389 > >Вобщем дело плохо, если я правильно понимаю: пакеты приходящие на внешний ип имеют адрес_источника:порт_источника->внешний_адрес_шлюза:3389. После получения пакеты без изменений переправляются на 192.168.0.10:3389. Что происходит дальше: 192.168.0.10:3389 получает пакет с адресом назначения НЕ 192.168.0.10 а внешний_адрес_шлюза. Если интерфейс 192.168.0.10 не настроен на "неразборчивый (promiscuous) режим", что строго говоря является обычным состоянием интерфейса, и не является интерфейсом роутера (что тоже вероятнее всего),  то пакеты просто сбрасываются как предназначенные не для 192.168.0.10. В итоге -- такая схема просто не будет работать никогда, потому что принципиально неверная. >Чтобы это заработало, необходимо настроить либо destination nat (что наверно можно сделать >средствами pf), либо реверсный прокси, например rinetd, что гораздо проще неправильно понимаете, это не iptables, rdr само делает днат, собственно ссылка на страницу мануал http://openbsd.org/faq/pf/rdr.html
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема