Jump to content

Поясните


Recommended Posts

Доброго времени суток.

 

Собираюсь делать апгрейд недосервера на 80486 (3 компа в локалке через него ходят в инет, Волякабель) на более другое железо, сейчас интенсивно читаю литературку по линуксу, сквиду, стг, и т.п., может баян уже, но все же вот какой вопрос мне интересен:

 

Хочу поставить сквид и стг, и допустим настраиваю я стг и ставлю прозрачный прокси, стг считает внешний трафик, локальный до роутера, и внутрисеть Воли. Допустим из локалки идет запрос наружу, запрашиваемое есть в кеше прокси. При этом клиентская машина видит получаемое как если бы оно было получено снаружи, на самом же деле оно было отдано с сервера, и внешнего трафика не имело место быть. Как квалифицирует стг подобный трафик - как внешний, или как локальный ?

Link to post
Share on other sites
смотря как пропишешь rules

если трафик сквидовский считается, то будет считаться и то, что с кеша пошло

Что есть сквидовский трафик ? Насколько я въехал в принцип работы прозрачного прокси - средствами ОС все пакеты просто заворачиваются на порт сквида, и оттуда уже либо идут наружу, либо не идут.

 

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

Link to post
Share on other sites

Сейчас у стг есть 2 способа подсчета пакетов.

Во всяком случае на линуксе.

При первом способе, если прокси прозрачен, то он прозрачен и для стг.

Т.е. файл, взятый из кеша, стг посчитает, как скачаный с инета.

При втором способе... хз)

Как я понимаю, как настроишь, так и будет )

Хотя нет. Хотя да ) Хотя нет.

В общем при втором способе можно попробовать помудрить.

А при первом способе помудрить нельзя, если прокси прозрачный и работает нат.

Link to post
Share on other sites
Сейчас у стг есть 2 способа подсчета пакетов.

Во всяком случае на линуксе.

Об этих способах написано где-то ?

 

Сама собой напрашивается логическая цепочка "Внутренний интерфейс - прокси - стг - внешний интерфейс", то есть как-то сделать, чтобы стг считал пакеты, исходящие от прокси, но в таком случае он их уже не персонализирует по конкретному юзеру. Я прав ?

Link to post
Share on other sites

Правильная цепочка такая [if]-[stg]-[firewall]-[user-level(squid, nat)]-[firewall]-[stg]-[if]

но в таком случае он их уже не персонализирует по конкретному юзеру. Я прав ?

Да

Тут выход только отказаться от прозрачного проксирования.

Link to post
Share on other sites

Тут выход только отказаться от прозрачного проксирования.

Отказались. То есть я средствами ОС закрываю все порты, кроме 3128.... а дальше ?

Link to post
Share on other sites

не совсем... Отказаться от проксирования вовсе! Иначе у вас не будет совпадать объём внешнего трафика со сведениями в биллинге.

 

Как выход, это вынос прокси на другую физическую машину. До биллинга со стороны интернета.

Link to post
Share on other sites

Попробовал реализовать прозрачное проксирование на Squid + SG. Работает, хотя точность подсчета трафика проверить не могу. Вопрос по настройке учета HTTP - трафика. Допустим, внутренний интерфейс роутера со всей начинкой 10.3.3.250. Прописываем всю сеть 10.3.3.0/24 в рулесах как внутреннюю. Пока в обозревателях пользователя НЕ настроен прокси - все красиво. HTTP запросы идут на шлюз по умолчанию (наш роутер), он форвардит порт x.x.x.80 на 127.0.0.1:3128 (squid) не изменяя адрес назначения пакета, и трафик нормально считается, разделяясь на местный и прочий. Но если пользователь в настройках обозревателя принудитеольно прописывет работу через прокси (10.3.3.250:3128) пакеты считаются идущими во внутерннюю сеть и трафик получается внутренним. Казалось бы можно 250-й IP в рулесах прописать на другое направление, но как-то неправильно. Тем более, что не роутере стоит еще и почта, и хотелось бы почтовый трафик считать внутренним.

Посоветуйте, как правильно настроить?

Link to post
Share on other sites

Тю.... проблему нашли.... закрывайте порт прокси (3128) от клиентов и разрешайте на прокси идти только 127.0.0.1 редирект работать будет а клиент не пойдёт на прокси

 

для верности можно и портик поменять на левый.... хотя сканер портов в умелых руках найдёт :)

Link to post
Share on other sites

Может не в тему, но очень всем благодарен за быструю реакцию по ответам на вопросы. Это еще одна составляющая хорошего продукта.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...