Роутинг по хостам

[fisher74]

Как же не доходите, когда он Вам запрещает ходить на ya.ru? О чём Вам и говорит.

Вы в корне не понимаете структуру того что хотите построить. И тем более остаются за пределами понимания этапы пусконаладки.
Это фатально для проекта.
Извините за прямоту.

[Vady]

Как же не доходите, когда он Вам запрещает ходить на ya.ru? О чём Вам и говорит.

Вы в корне не понимаете структуру того что хотите построить. И тем более остаются за пределами понимания этапы пусконаладки.
Это фатально для проекта.
Извините за прямоту.

Поясните, почему с браузера свободно хожу по сайтам? К чему пишете про запрет на ya.ru?
Да всё просто - с браузера иду мимо squid. Мне бы сначала увидеть запрет попадания на ya.ru с браузера, чтобы убедиться в том, что попадаю на squid.
Я вначале думал, что можно решить проблему "белого списка сайтов" при помощи роутинга интерфейсов, а оказалось, что решения нет, поэтому пошел взяться за то, что не брался ранее, а именно iptables+squid. А тут некоторые личности принялись строго меня судить. Пойду изучать маны по iptables, а потом squid, но это дело не одного вечера.

[fisher74]

Ещё раз: неверный порядок.
Настройте сначала кальмара, заставив браузер принудительно ходить через него (настройками браузера). И только после этого решайте вопрос прозрачности кальмара (аки редирект редствами iptables)

И снова ещё раз: задача для прозрачного редиректа с локального браузера на локальный прокси несколько нетривиальна, потому и требует особого подхода. То есть нужно решить её так, что бы трафик от прокси не заворачивался снова на себя. Именно поэтому сначала нужно настроить сам прокси, а уже потом выкручиваться с правилами для netfilter.

[Vady]

В убунте пользовался браузером chromium. Искал настройки прокси. К моему удивлению, увидел сообщение о том, что браузер использует только системные настройки, нет полей для заполнения настроек вручную. По причине нехватки времени не стал гуглить на тему настройки прокси в браузере chromium в убунте. Подозреваю, Вы предлагаете мне уйти от решения проблемы перенаправления портов с локалхоста на кальмар путем прописывания настроек на браузере? На сервере планируется завести более 60 юзеров. На каждом аккаунте прописывать? Системные настройки? полагаю, вариант! Погуглю что да как там.
Вопрос: команда, запущенная на самом сервере (прокси-сервере), links -http-proxy 192.168.1.1:3128 ya.ru с какого интерфейса пытается открыть ya.ru? не с локалхоста? Если да, то, по правилам не должен пускать.

[fisher74]

Подозреваю, Вы предлагаете мне уйти от решения проблемы перенаправления портов с локалхоста на кальмар путем прописывания настроек на браузере?

Да, но только на время тестирования и отладки squid-а. Отладите список доступа, а дальше уже можно и редирект для пользовательских uid-ов ваять.
Кстати, появилась идея, что в правиле можно диапазон uid-ов зарядить. Например --uid-owner 1000-2000 Таким образом системные процессы не будут попадать под это правило и не будут страдать от ограничений прокси.

Вопрос: команда, запущенная на самом сервере (прокси-сервере), links -http-proxy 192.168.1.1:3128 ya.ru с какого интерфейса пытается открыть ya.ru? не с локалхоста? Если да, то, по правилам не должен пускать.

Да, с локалхоста. Он у Вас и не пускает, судя по выхлопу

[Vady]

Проделал следующие действия:
1) Система->Параметры->Сетевая прокси-служба.
Переключатель - Ручная настройка прокси-службы.
Прокси для HTTP: 192.168.1.1, порт - 3128.
Кнопка Закрыть.
2) Запустил браузер chromium, интернет работает без проблем. Отключил кальмар, тоже работает интернет. Настройки сетевой прокси-службы не сработали.
3) Запустил кальмар. Создал ярлык на рабочем столе с chromium-browser --proxy-server=192.168.1.1:3128. Увидел: доступ запрещен! Скорее всего, с локалхоста пытался попасть на прокси.
Пользователь решил продолжить мысль [time]20 Март 2015, 11:34:16[/time]:Взял другой компьютер, который находится в одной подсети с интерфейсом eth0 сервера.
Условно говоря, его ip 192.168.1.2.
В настройках браузера прописал прокси 192.168.1.1:3128. Шлюз в настройках - как обычно, шлюз интернета. Результат: доступ запрещен кальмаром.
Убрал прокси из браузера. Поменял ip шлюза на ip прокси-сервера. Результат: работает интернет. На прокси-сервере отключил кальмар. Проверил: перестал работать интернет.
Как понять, почему первый вариант не сработал? Из-за того, что прокси настроил как прозрачный? То есть никакие настройки браузеров не решат проблему?

[fisher74]

Поменял ip шлюза на ip прокси-сервера.

А для 192.168.1.0/24 это не одно и тоже разве???

[Vady]

Поменял ip шлюза на ip прокси-сервера.

А для 192.168.1.0/24 это не одно и тоже разве???

И что? Шлюз интернета, прокси-сервер, клиентский компьютер в одной подсети 192.168.1.0/24.
Если не поняли, в настройках сети клиентского компьютера поменял ip-адрес шлюза по умолчанию и сделал шлюзом для клиентского компьютера прокси-сервер. Пишу к тому, что squid работает исправно. Прописал в squid.conf белый список сайтов. На клиентском компьютере вижу только "белые" сайты. На остальных сайтах - "доступ запрещен by squid".
Вопрос по настройке доступа к прокси с локального интерфейса еще остается в силе.

[fisher74]

И что? Шлюз интернета, прокси-сервер, клиентский компьютер в одной подсети 192.168.1.0/24.

А то что я ещё в самом начале просил предоставить схему. А Вы всё в шпионов играете.
Если шлюз интернета и прокси-сервер разные хосты, то и алгоритмы организации прозрачного прокси несколько другие.

Чтобы локалхост проксисервера мог работать через прокси-сервер, нужно добавить его в acl.

[Vady]

А то что я ещё в самом начале просил предоставить схему. А Вы всё в шпионов играете.

Я схему уже предоставил: https://forum.ubuntu.ru/index.php?topic=258575.msg2046905#msg2046905
Имейте ввиду, что у шлюза не один порт - по этой причине мог подключить для теста одного клиента.

Чтобы локалхост проксисервера мог работать через прокси-сервер, нужно добавить его в acl.

Как это реализовать? пробовал следующие варианты:
acl local src 127.0.0.0/8
потом менял на
acl local src 127.0.0.1
затем:
acl local src localhost
Ни один из вышеприведенных не помог.
Разумеется, про строчку http_access allow local не забыл.
http_port по-прежнему стоит 192.168.1.1:3128 transparent

[2Casp]

Vady,
книгу нашел? Две главы прочитал?

дело в том, что тебя сейчас не направить надо в нужное русло, а предварительно рассказать азы, а потом уже вторым заниматься.
в данном случае тебе нужно или просто сделать, что советуют без каких либо своих изменений. либо сначала почитать, а потом, как я говорил отпадет 80% вопросов.

[Vady]

Vady,
книгу нашел?

Конечно, нет. Гуглю.
http://www.opennet.ru/base/net/squid_inst.txt.html
По этой ссылке ни слова про локалхост. Дальше гуглю.

[fisher74]

Я схему уже предоставил: https://forum.ubuntu.ru/index.php?topic=258575.msg2046905#msg2046905

С каких это пор схема только из слов состояла? Литературный кружок?
По ней "интернет-шлюз" имеет адрес 192.168.1.255. Для сети 192.168.1.0/24 это очень даже некорректно

Имейте ввиду, что у шлюза не один порт - по этой причине мог подключить для теста одного клиента.

Это Вы сами там имейте ввиду. Если отклоняетесь от основной схему, то и говорите об этом, а не оставляйте нам на домысливание. То у Вас клиенты со стороны eth0, а тут вдруг вкладываете его сто стороны p7p1 (судя по адресу)

http_port по-прежнему стоит 192.168.1.1:3128 transparent

Зачем Вы вообще используете интерфейс смотрящий в интернет для прослушки прокси-сервером? У Вас же все клиенты со стороны локалхоста и со стороны 10.0.0.0/24. Что мешает слушать на всех интетфейсах?

Код: [Выделить]

http_port 3128 transparent

[Vady]

Зачем Вы вообще используете интерфейс смотрящий в интернет для прослушки прокси-сервером? У Вас же все клиенты со стороны локалхоста и со стороны 10.0.0.0/24. Что мешает слушать на всех интетфейсах?

Код: [Выделить]

http_port 3128 transparent

Корпоративная сеть на время теста отключена от прокси по соображениям безопасности. То есть 10.0.0.0/24 пока не работает на прокси. Вот и временно использую 192.*
Не считаю разумным слушать на всех трех интерфейсах. Нужны только два. С внешнего на внутренний позже поменяю, когда закончу - в будущем внешний не нужно слушать.
Так что имеем сеть из 3 машин: прокси, клиент, шлюз. Про остальных не буду говорить, дабы не раздувать из мухи слона.

[fisher74]

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

Перенесите клиента на eth0 с предполагаемой там адресацией (10.0.0.0/24) и тестируйте в том виде, в котором будет эксплуатироваться. Иначе кажущиеся удачи могут стать большой проблемой.