URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID10
Нить номер: 4610
[ Назад ]

Исходное сообщение
"Странности ipfw"

Отправлено GlooM , 09-Июн-10 23:17 
Здравствуйте! Поясните непонятный мне момент плиз.

1) Дано: локальная сеть (192.168.1.0), подключенная через шлюз (FreeBSD 7.2) к инету. Используется ipfw. Есть три категории пользователей: а) только хттп трафик через транспарент сквид; б) пользователи, имеющие дополнительно весь открытый https (порт 443); в) пользователи которым открыто всё.
Задача: дописать исключение, которое позволит пользователям "а" заходить на один единственный хттпс сайт (онлайн банк, для проверки своих зарплат).
Реализация:

#Zavorot http zaprosov na squid
${fwcmd} add fwd ${iip},3128 tcp from ${MyLan} to any 80 via bce0
#Enable protocol "https"
${fwcmd} add divert natd tcp from 192.168.1.7 to any 443 out via bce0
${fwcmd} add divert natd tcp from 192.168.1.33 to any 443 out via bce0
${fwcmd} add divert natd tcp from 192.168.1.15 to any 443 out via bce0
#Enable "https" na bank dlya vsex
${fwcmd} add divert natd tcp from any to BANK_IP 443 out via bce0
# full access
${fwcmd} add divert natd tcp from 192.168.1.8 to any out via bce0
${fwcmd} add divert natd tcp from 192.168.1.66 to any out via bce0
${fwcmd} add divert natd tcp from 192.168.1.6 to any out via bce0

Проблема: при такой конструкции правила, доступ к банку через хттпс действительно появляется у пользователей "А". Однако, у пользователей "Б" хттпс пропадает весь целиком, в том числе и на сам банк (несмотря на глобальное, разрешающее весь ХТТПС правило), у пользователей "В" открыто все по прежнему.

Решение: поменять местами глобальные правила, разрешающее хттпс нескольким выбранным юзерам, и "точечное" правило, воздействующее на всех юзеров, но дающее доступ только на 1 сайт. В таком случае все работает как и должно!

#Zavorot http zaprosov na squid
${fwcmd} add fwd ${iip},3128 tcp from ${MyLan} to any 80 via bce0
#Enable "https" na bank dlya vsex
${fwcmd} add divert natd tcp from any to BANK_IP 443 out via bce0
#Enable protocol "https"
${fwcmd} add divert natd tcp from 192.168.1.7 to any 443 out via bce0
${fwcmd} add divert natd tcp from 192.168.1.33 to any 443 out via bce0
${fwcmd} add divert natd tcp from 192.168.1.15 to any 443 out via bce0
# full access
${fwcmd} add divert natd tcp from 192.168.1.8 to any out via bce0
${fwcmd} add divert natd tcp from 192.168.1.66 to any out via bce0
${fwcmd} add divert natd tcp from 192.168.1.6 to any out via bce0

Вопрос: почему перестановка правил вообще повлияла таким образом? Как два разрешающих правила (точечное и глобальное) превратились в одном случае в запрещающее? Поясните данный момент.


Содержание

Сообщения в этом обсуждении
"Странности ipfw"
Отправлено spammer , 10-Июн-10 04:54 
>[оверквотинг удален]
>${fwcmd} add divert natd tcp from 192.168.1.8 to any out via bce0
>
>${fwcmd} add divert natd tcp from 192.168.1.66 to any out via bce0
>
>${fwcmd} add divert natd tcp from 192.168.1.6 to any out via bce0
>
>
>Вопрос: почему перестановка правил вообще повлияла таким образом? Как два разрешающих правила
>(точечное и глобальное) превратились в одном случае в запрещающее? Поясните данный
>момент.

Все ваши пожелания реализуются с помощью сквида ipfw  тут не панацея


"Странности ipfw"
Отправлено GlooM , 10-Июн-10 11:00 

>
>Все ваши пожелания реализуются с помощью сквида ipfw  тут не панацея
>

Транспарент сквид не проксирует ХТТПС.


"Странности ipfw"
Отправлено spammer , 10-Июн-10 11:48 
>
>>
>>Все ваши пожелания реализуются с помощью сквида ipfw  тут не панацея
>>
>
>Транспарент сквид не проксирует ХТТПС.

а кто сказал про прозрачный прокси, создаются acl-списки кому куда можно, а кому нет, и с портами тоже самое.


"Странности ipfw"
Отправлено GlooM , 10-Июн-10 15:34 

>а кто сказал про прозрачный прокси, создаются acl-списки кому куда можно, а
>кому нет, и с портами тоже самое.

Acl списки в чем? В сквиде? Сквид это и есть прокси, работающий, в моем случае, в прозрачном режиме.
В общем суть не в сквиде, и не в решении проблемы предоставления доступа. В этом я разобрался.

Вопрос в поведении ipfw, почему от перестановки мест двух разрешающих правил, происходит запрещающая ситуация?


"Странности ipfw"
Отправлено DenSha , 16-Июн-10 10:42 
Для справки:
1. bce0 - внешний интерфейс?
2. Последнее правило - enable all/disable all?
3. Приведены все правила, касающиеся https?
4. Нат с какими ключами запущен?

"Странности ipfw"
Отправлено GlooM , 16-Июн-10 23:13 
>Для справки:
>1. bce0 - внешний интерфейс?
>2. Последнее правило - enable all/disable all?
>3. Приведены все правила, касающиеся https?
>4. Нат с какими ключами запущен?

1) Так точно.

2) Никакое -)))) Там все правила состоят из целевых пробросов дивертов. Т.е. пакеты проходят туда, куда диверт предусматривает, а если правила нет, то они не натятся вообще. Помоему, логика человека, настраивающего этот фаервол до меня, такая.

3) Относительно целевого разрешения хттпс - да, больше правил нет. Но, есть еще одно правило, через которое хттпс тоже работает - разрешающее вообще все порты на один из наших внешних айпи - почтовый сервер.

4) Через рц.конф
natd_enable="YES"
natd_interface="bce0"
natd_flags="-f /etc/natd.conf"


"Странности ipfw"
Отправлено GlooM , 16-Июн-10 23:42 

>
>2) Никакое -)))) Там все правила состоят из целевых пробросов дивертов. Т.е.
>пакеты проходят туда, куда диверт предусматривает, а если правила нет, то
>они не натятся вообще. Помоему, логика человека, настраивающего этот фаервол до
>меня, такая.
>

ipfw list выдает
65535 allow ip from any to any


"Странности ipfw"
Отправлено DenSha , 17-Июн-10 10:13 

>natd_flags="-f /etc/natd.conf"

А содержимое natd.conf можно привести (замазав реальный ip)?


"Странности ipfw"
Отправлено GlooM , 17-Июн-10 12:34 
>
>>natd_flags="-f /etc/natd.conf"
>
>А содержимое natd.conf можно привести (замазав реальный ip)?

Конечно можно!
same_ports yes
use_sockets yes
unregistered_only yes
interface bce0



"Странности ipfw"
Отправлено DenSha , 22-Июн-10 11:29 
>>
>>>natd_flags="-f /etc/natd.conf"
>>
>>А содержимое natd.conf можно привести (замазав реальный ip)?
>
>Конечно можно!
>same_ports yes
>use_sockets yes
>unregistered_only yes
>interface bce0

Не, не проЯснивается :) Собака, надо понимать, порылась в возврате пакета после диверта на следующее правило для дальнейшего прохода по ipfw (хорошо бы уточнить значение net.inet.ip.fw.one_pass) и, возможно, некорректной отработке банковского, в которое попадают все на 443 порт. Как-то, чтоли, прикрутить логи на диверты, включить отладку ната, tcpdump-ить и смотреть... И еще: есть правило "диверт", которое встречает входящие извне пакеты?

ЗЫ. Я то тоже сильно "не волшебник". Просто интересно :)