» SQUID (только под *nix)

dene14
Да - действительно - соединение идёт через VPN с авторизацией по PPTP
т.е уменьшаем MTU и проблема решена?

kaurych
ну впринципе да, но на линухе вроде как мне выставление МТУ на интерфейсе не помогало, пмог именно clamp PMTU модуля TCPMSS в линухе... эксперементируй, результат тока отпиши, я сам в Бзде не силён, всё теплю мечту освоить, но думаю для истории и помощи другим - будет не плохо...



P.S. РЕБЯТ, НУ ПОМОГИТЕ МНЕ С МОЕЙ ПРОБЛЕМОЙ!!! ПЛИЗЗЗЗ!!! Не хочется плодить по сквиду на каждый внешний интерфейс!

dene14

Цитата:

то когда юзер прописывает себе прокси вида ip_городской_сети:80

Это как?

dene14
Тут на маршрутизацию надо смотреть
и вообще - зачем юзеру знать IP шлюза городской сети - он должен знать только IP твоего шлюза
у меня допустим отдельно маршрут для выхода во внутреннюю сеть (домовую) и в правилах фаирвола разрешено только двоим выходить туда!

Маршрутизация тут не при чём...
Юзер ваще не знает о существовании прокси...
Подсчёт через pcap видётся исходя из источника - получателя ip пакета... всё что идёт на 80й порт заворачивается на сквид, но происходит естественно после того как обсчитано через pcap... и когда юзер прописывает себе прокси вида ip из городской сети и порт прокси 80 траффик классифицируется как городской, но после этого он заворачивается на мой прозрачный прокси и отправляется на реальный адрес, который запрошен браузером (даже не из городской сети)...
Реальный пример:
Городская подсеть 172.16.0.0/16, прописан маршрут включён нат
Интернет, дефолтный гейт, включён нат.
Прозрачный сквид - заворачивается порт 80.
Пока юзер ничего не прописал в настройках прокси - считает нормально.
Как только прописывает прокси из сети 172.16.0.0/16 и порт 80 - к примеру 172.16.0.1:80 траффик учитывается как на 172.16.0.1:80 хотя конечно все запросы на моём роутере заворачиваются на squid и юзер может лазить в интернете, а считается как локальный городской траффик.
Повторяю, учёт ведётся не средствами squid, а через низкоуровневую сетевую библиотеку pcap.

Цитата:

Прозрачный сквид - заворачивается порт 80.

Правило заворота покажи...

Сдаётся мне что не надо заворачивать городскую сеть на сквид либо в сквиде валить по src

Ruza
собственно сам редирект такой:
-A PREROUTING -p tcp -m mark --mark 0x1 -m comment --comment "Transparent proxy redirect" -j REDIRECT --to-ports 3128

а маркировка в mangle вот такая:
-t mangle -I USERS -s IP/BITS -d ! x.x.0.0/16 -p tcp -m multiport --dports 80,81,8080,8081,8181 -j MARK --set-mark 1 -m comment --comment LOGIN

Да дело не в том какое правило заворота, тут всё типовое и дёт на уровне транспортного уровня... а нужно уже инкапсулированный из ip в http траффик блокировать при наличии такой бяки... инкапсуляцией занимается ессно сам squid.
Разница между заголовками запросов напрямую и через некий прокси весьма простая:
1. напрямую:

Код: Connection: keep-alive

dene14

Цитата:

Разница между заголовками запросов напрямую и через некий прокси весьма простая:

Ну так вроде это подойти должно:

Цитата:

acl aclname req_header header-name [-i] any\.regex\.here
# regex match against any of the known request headers. May be
# thought of as a superset of "browser", "referer" and "mime-type"
# ACLs.

Ruza
Спасибо за помощь, но что-то похоже не помогло, может неправильно что сделал:
добавил в конфиге в конце такие вот строки:
acl 3rd_party_proxy req_header Proxy-Connection keep-alive
http_access deny 3rd_party_proxy

Ура, получилось! Ключевая фраза была "добавил в конфиге в конце"... Забыл просто что приоритет ACL в squid читается по порядку с начала конфига и к концу, уменьшая приоритет...

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

Добавлено:
Вот сейчас тестирую...
Получилось так:
FlashGet при указании стронней прокси коннектится по методу CONNECT, запретил его (благо у меня сквид только как прокси для HTTP используется), перестал качать... Если выставляю в настройках прокси ФлэшГета метод Get качает снова без проблем с левой проксёй...

Ещё одно: с добавленным acl 3rd_party_proxy - Firefox выдаёт ожидаемую ошибку 403 при прописанной левой проксе, а IE пролазит без заминочки!
Идеи?

Добавлено:
Мне вот пришла идея...
Я где-то видел, что у сквида есть что-то вроде опции внешнего адреса tcp_outgoing
может как-то можно сделать, чтобы определённые списки подсетей ходили через определённые IP ??? хотя это вариант мне тоже не очень удобен, потому что используется динамический роутинг по скриптам...

Добавлено:
Мучения вроде как закончились. Ruza, подскажи как сделать ACL
acl 3rd_party_proxy req_header Proxy-Connection keep-alive
чтобы срабатывал не в зависимости от значения поля Proxy-Connection, а по самому наличию данного поля в запросе?
Т.е. чтобы у меня блокировалось при любых значениях Proxy-Connection

вот столкнулся с такой проблемой.
Можно ли как-то на прокси мониторить какой пользователь скока канала берет для себя ?
Delay pools настроен, но там тока ограничивает скорость для конкретного пользователя или группы. А хотелось, чтобы, так сказать, в режиме реального времени показывалось сколько каждый пользователь "потребляет инета" ?

Я так догадываюсь, что это надо копать в сторону mrtg и nagios

vovanj7
Поставь себе к примеру iptraf и слушай на внутреннем интерфейсе, выставив в фильтре конкретного юзера...

насколько я понял у iptraf нет вэб-интерфейса.
если у кого есть скинуть формат логов iptraf

vovanj7
так ты же говоришь тебе в реальном времени нужно...
подозреваю что готовых решений нет... нужно думать в сторону squid snmp support

Можете помочь?
Что делать?
Невозможно подключиться к прокси-серверу. Доступ запрещен

Стоит последний Squid.. порт 3128. все работало, но вот сегодня перестало.
Может хостер???


Но у меня root к vps.
Что "подкрутить"?

Цитата:

подозреваю что готовых решений нет... нужно думать в сторону squid snmp support

Хм..... плохо ((( Буду гуглить может кто сталкивался с подобной задачей...





maksjis

Цитата:

Невозможно подключиться к прокси-серверу. Доступ запрещен

в списке процессов есть squid ? Что там с acl ?

vovanj7

Цитата:

Хм..... плохо ((( Буду гуглить может кто сталкивался с подобной задачей...

sqstat посмотри
http://samm.kiev.ua/sqstat/

maksjis

Цитата:

Но у меня root к vps.
Что "подкрутить"?

Руки...
Чего ты ждёш от форума с таким вопросом? Вообще не понятно что у тебя настроено и как...
Для начала /var/log/squid/squid.out и /var/log/squid/cache.log


Добавлено:
dene14
Упс... не заметил вопроса...
Вот тут вспомнил про одну фишку на досуге...
Почитай может так проще:
http://www.squid-cache.org/Versions/v2/2.7/cfgman/header_access.html
Т.к. не знаю версию линка для 2.7
А acl пишется скорее всего так (не проверено)

Цитата:

Synopsis
Regular Expression match against any of the known request headers.
May be thought of as a superset of "browser", "referer" and "mime-type" ACLs.

Arguments
aclname
     Access list name
header-name
     Name at the requesting side
Example(s)
acl myheader req_header text
This acl looks for the pattern "text" in request header.

acl 3rd_party_proxy req_header Proxy-Connection -i Proxy

Ruza
Это я уже решил... прописал вообще вот так:

Код: acl 3rd_party_proxy req_header Proxy-Connection /*
http_access deny 3rd_party_proxy

dene14
Я же написал попробуй пересобрать squid с параметром --enable-http-violations
И далее
header_access Proxy-Connection deny all

Ruza
Делал - это вообще не помогает...

Давай мот в аську пообщаемся? я попытался авторизоваться, но ты не ответил... мот ты меня добавишь???

Добавлено:
Перечитал ещё раз RFC )
Нашёл собственно отличие задокументированное...
Всё дело в URI метода GET при работе напрямую и через прокси...
когда через прокси то URI=URL (т.е. полная ссылка на запрашиваемый объект), когда же напрямую, то URI - относительная ссылка на сайте...
т.е. в первом случае это http://site.domain/path/to/file.ext
а во втором это /path/to/file.ext

Соответственно у меня вопрос, какими средствами можно составить ACL на основе URI ???

dene14
В ICQ не проблема но с понедельника... Т.к. на работе плановая инвентаризация.

Вот немного репу почесал придумал/нашёл ещё пару:

acl proxy_headers req_header X-Forwarded-For .
acl proxy_headers req_header Via .
Походу если не пароноидальный анонимус то должно блокировать.


Цитата:

Всё дело в URI метода GET при работе напрямую и через прокси...

не факт - тут передача реферер замешена. И это идеал, а если к примеру линка на стронний ресурс.

Добавлено:
2 ALL
В свете появления ветки 3.1.0.1 и новой фитче ecap.
Кто нибудь видел более-менее полную доку по этой фитче? А то найденные мной описания довольно туманные и дальше example ничего нету.

Ruza
Referer ни при чём... это для сайта рефереры важны и прочее...
X-Forwarded-For, Via - вообще отдаются в мир, чтоб типа разделить юзеров из внутренней локалки... к примеру юзера с ip 192.168.1.1 и 192.168.1.2

Я уже разными способами проверил... только через прокси URI получается полный да и в RFC прописано, без этого собственно коммутации не будет...


Цитата:

а если к примеру линка на стронний ресурс

До сереневой звезды... Сначала подключение к самому сайту, а потом ссылки относительые... Перепробовал во всех браузерах и прямы ссылки и кривые )) - всегда одинаково... RFC, как грится, он и в африке RFC.

Цитата:

X-Forwarded-For, Via - вообще отдаются в мир, чтоб типа разделить юзеров

А тебе что надо?

Ruza
Если бы мне надо было анонимайзер сделать - то в и-нете полно инфы и не составило труда, а мне нужно заблокировать все запросы, если юзер прописывает себе какой либо proxy из интернета.
траффик конечно всё равно завернётся на мой проксик и не пойдёт на указанный юзером прокси, но мне нужно, чтобы коннекта не произошло и выдалась ошибка Доступ запрещён.

Всё что мне нужно на данный момент закрыть: это RegExp "^http://", т.е. наличие http:// в URI. Такие запросы нужно заблокировать и отвергнуть.

Вот глянь ещё эту ссылку, тут описан принцип работы, который мне нужно отсечь )) безо всяких RFC. нормальным русским языком:
http://freeproxy.ru/ru/free_proxy/faq/classical_proxy_chaining.htm

Цитата:

Всё что мне нужно на данный момент закрыть: это RegExp "^http://", т.е. наличие http:// в URI. Такие запросы нужно заблокировать и отвергнуть.

Ну так что мешает:
acl aclname url_regex [-i] ^http://
или
acl aclname urlpath_regex [-i] http://

dene14
На фряхе выставил mtu 1400 такое же как и на zyxel который создаёт соединение по pptp
но и при других значениях работает нормально ниже 1500 просто у меня VPN на IPsec проходит внутри PPTP - при других значениях mtu некоторые соединения внутри VPN IPsec работают не устойчиво. И вообще у меня squid на виртуалке vmware server2 c с одной сетевой - работает отлично

Вопрос знатокам.

Для ИСЫ есть такой фильтр: Перед тем как пользователь начнет сессию - ему выдается страничка "license agreement". Он щелкает ОК - и начинает серфить инет. Наверняка для SQUID тоже есть такие решения, у многих провайдеров выставляется своя стартовая страница. Подскажите куда посмотреть. Глубокое вам мерси.

capitannemo

Можно проверить сессию пользователя - что то подобное:

Цитата:

EXAMPLE
Configuration example using the default automatic mode

external_acl_type session ttl=300 negative_ttl=0 children=1 concurrency=200 \
%LOGIN /usr/local/squid/libexec/squid_session

acl session external session

http_access deny !session

deny_info http://your.server/bannerpage?url=%s session

Then set up http://your.server/bannerpage to display a session startup
page and then redirect the user back to the requested URL given in the
url query parameter.

Добавлено:
вот ещё есть редиректор, но не проверял... Проверь отпишись что к чему.
http://guifi.net/en/node/14092

Спасибо большое. Проверю - напишу. Пауза - пару дней.

kaurych
Нужно считать размер заголовков... у разных протоколов итоговый размер заголовка разный...
К примеру в обычной сети это: Ethernet (Arp), ip.
Получается что, твой пакет с данными оборачивается сначала в слой IP, потом в Ethernet (чтобы была возможность передать по Ethernet интерфейсу и среде), т.о. получается что заголовок конечный увеличивается...
Точно также и с вложенными соединениями... Т.е. ты можешь сделать достаточно большую вложенность VPN туннелей, но при этом с увеличением вложенности туннеля должен быть уменьшен MTU, потому как получается к примеру что MTU туннеля 1328, а пакет отправляется 1500 байт... в нормальной ситуации он конечно будет фрагментирован и передан двумя пакетами (1320+8) + (1500-1320+8) (я тут не учёл инкапсуляцию на роутере, предположив что 1500 байт - это всё полезные данные уже без заголовков), но насколько я знаю SYN пакет фрагментирован быть не может автоматически, потому что он несёт в себе что-то вроде инициализации сессии и никаких алгоритмов реассемблирования к ним не применяется, только разрешить или отклонить. Как правило SYN пакеты очень малы, но некоторые протоколы как MSN или ICQ могут отсылать достаточно большой SYN пакет, что собственно и вызывает проблемы.

Ruza
Так что насчёт аськи? Совсем не хочется чтобы Nep расстрелял за засранный форум ))

dene14

Цитата:

Ruza
Так что насчёт аськи? Совсем не хочется чтобы Nep расстрелял за засранный форум ))

Протупил... Отправил в профильную аську запрос...