Привет,
хорошая статья была (руководство для начинающего web-hackera)
http://www.sanctuminc.com/pdf/WhitePaper_HTTPResponse.pdf Там есть параграф
"Cache Poisoning with Squid 2.4 - Practical Considerations"
Интересно, починили ли они это в Squid 2.5 Stable?
>Вопрос к админам: зачем использовать какие-то сквиды, когда есть IP Masquerading?
А кэшировать, рекламу и порнушку фильтровать? А отчеты по юзерам и пользованию Инетом получать?
Или у Вас халявный Инет, юзеры чего хотят, то и творят?
Зачем НАТ? Можно абсолютно все сделать и без него через разного рода прокси и туннели...
>NAT - некэширующий пркси с широчайшими возможностями
>squid - кэширующий прокси для ограниченного набора протоколов
Полное непонимание принципиального отличия NAT и proxy.
Первый просто форвардит оригинальные пакеты, на проходе подменяя поле src ip и, возможно, src port.
Второй выступает со стороны клиента в качестве сервера, а снаружи прикидывается клиентом. Т.е. исходные пакеты "поглощаются" проксей, а наружу выходят совершенно новые пакеты.
Из этого вытекает достаточно много следствий.
В принципе, NATу все равно какой протокол прикладного уровня пропускать (исключения - специфические протоколы, типа FTP, которые передают ip адреса в поле данных. Для таких протоколов нужна специальная поддержка). Прокси же всегда рассчитан на работу с конкретными протоколами 7-го уровня. И если для специфического протокола прокси еще не написан - труба! (Например PPTP. Я не знаю прокси для gre)
Со стороны клиента NAT абсолютно "прозрачен". В случае прокси - обязательна поддержка конкретного типа проксей в клиенте, что не всегда осуществимо.
Для NATa существует проблема фрагментации. У любого прокси - отсутствует.
Если на интерфейсах разные MTU, NAT может вовсе перестать работать, т.к. не способен пересобирать пакеты. Для любого прокси эта проблема решается естественным образом.
Т.о. у обеих технологий есть свои сильные и слабые стороны. Вопрос, когда что применять, не решается однозначно.
Re: Re: Re: Re: Re: Re: Squid подвержен remote DOS
Поверь на слово есть проблемы с MTU
Классический пример:
Локалка 192.168.x.x, на рутере реальный IP и туннель gre через который гонится весь трафик.
Моментально огребаешься граблями по самое небалуйся.
Помогает
-A POSTROUTING -o tunnel -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360
>Поверь на слово есть проблемы с MTU Классический пример
теорию объяснить слабО? Может всё дело в том, что некоторые "эксперты по безопасности" блокируют icmp? У меня с NAT и тоннелями никогда таких проблем не было.
2anonymous (*) (15.10.2004 5:59:17)
>Первый просто форвардит оригинальные пакеты, на проходе подменяя поле
> src ip и, возможно, src port.
>Второй выступает со стороны клиента в качестве сервера, а снаружи
> прикидывается клиентом. Т.е. исходные пакеты "поглощаются" проксей, а
> наружу выходят совершенно новые пакеты.
Сюда еще добавить, что прокси организовывает ДВА ОТДЕЛЬНЫХ соединения.
От клиента до себя и от себя до сервера.
NAT же, акромя подмены в заголовке пакета, ничего делать не должОн.
Все остальные навороты NAT-ов это свойства конкретных реализаций ;-)
Посему на firewall (не путайте с фильтрующим роутером) и возможно
применения только проксирования. ;-)
>У меня с NAT и тоннелями никогда таких проблем не было.
Попробуй на своих виндовых клиентах выключить "Path MTU Discovery" и поставь фиксированное значение MTU=1500 (для ethernet). Тогда и поймешь, почему у тебя, якобы, нет проблем с тоннелями.
А представляешь себе, как "Path MTU Discovery" тормозит TCP стэк.
ну у меня сквид снаружи не прикрыт фиреволом
и что?
мне удобно когда клиенты подсоединяются к конкурирующему провайдеру
и видят сообщение об ошибке на русском языка
а что касается нат так попробуйте сквозь прокси какойнибудь real-time протокол типа rpd - полная лажа.