Здравствуйте! Поясните непонятный мне момент плиз.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Вопрос: почему перестановка правил вообще повлияла таким образом? Как два разрешающих правила (точечное и глобальное) превратились в одном случае в запрещающее? Поясните данный момент.
>[оверквотинг удален]
>${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 тут не панацея
>Транспарент сквид не проксирует ХТТПС.
>
>>
>>Все ваши пожелания реализуются с помощью сквида ipfw тут не панацея
>>
>
>Транспарент сквид не проксирует ХТТПС.а кто сказал про прозрачный прокси, создаются acl-списки кому куда можно, а кому нет, и с портами тоже самое.
>а кто сказал про прозрачный прокси, создаются acl-списки кому куда можно, а
>кому нет, и с портами тоже самое.Acl списки в чем? В сквиде? Сквид это и есть прокси, работающий, в моем случае, в прозрачном режиме.
В общем суть не в сквиде, и не в решении проблемы предоставления доступа. В этом я разобрался.Вопрос в поведении ipfw, почему от перестановки мест двух разрешающих правил, происходит запрещающая ситуация?
Для справки:
1. bce0 - внешний интерфейс?
2. Последнее правило - enable all/disable all?
3. Приведены все правила, касающиеся https?
4. Нат с какими ключами запущен?
>Для справки:
>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"
>
>2) Никакое -)))) Там все правила состоят из целевых пробросов дивертов. Т.е.
>пакеты проходят туда, куда диверт предусматривает, а если правила нет, то
>они не натятся вообще. Помоему, логика человека, настраивающего этот фаервол до
>меня, такая.
>ipfw list выдает
65535 allow ip from any to any
>natd_flags="-f /etc/natd.conf"А содержимое natd.conf можно привести (замазав реальный ip)?
>
>>natd_flags="-f /etc/natd.conf"
>
>А содержимое natd.conf можно привести (замазав реальный ip)?Конечно можно!
same_ports yes
use_sockets yes
unregistered_only yes
interface bce0
>>
>>>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-ить и смотреть... И еще: есть правило "диверт", которое встречает входящие извне пакеты?
ЗЫ. Я то тоже сильно "не волшебник". Просто интересно :)