LINUX.ORG.RU
решено ФорумAdmin

squid и локальный /etc/hosts


0

1

Прозрачный прокси на базе FreeBSD 8 и Squid 3 и локальный компьютер на Ubuntu 9.10 за которым и работаю. Есть удаленный сервер с ip ххх.ххх.ххх.ххх но без dns-имени. Так как запоминать ip адрес лениво, добавил в /etc/hosts запись вида ххх.ххх.ххх.ххх remote.server.work, но когда забиваю в строку в браузере адрес сервера из /etc/hosts прокся выдает ошибку:

ОШИБКА Запрошенный URL не может быть доставлен

Во время доставки URL: http://remote.server.work/

Произошла следующая ошибка:

Невозможно определить IP адрес узла remote.server.work

вот конфиг сквида:

acl manager      proto cache_object
acl localhost    src   127.0.0.1/32
acl to_localhost dst   127.0.0.0/8 0.0.0.0/32
acl localnet     src   192.168.0.0/24
#acl all          src   0.0.0.0/0

acl white_dom  dstdomain "/usr/local/squid/lists/white.dom"
acl black_dom  dstdomain "/usr/local/squid/lists/black.dom"
acl trusted_ip src       "/usr/local/squid/lists/trusted.ip"
acl limited_ip src       "/usr/local/squid/lists/limited.ip"

acl SSL_ports  port 443
acl Safe_ports port 80        # http
acl Safe_ports port 21        # ftp
acl Safe_ports port 443        # https
acl Safe_ports port 70        # gopher
acl Safe_ports port 210        # wais
acl Safe_ports port 1025-65535    # unregistered ports
acl Safe_ports port 280        # http-mgmt
acl Safe_ports port 488        # gss-http
acl Safe_ports port 591        # filemaker
acl Safe_ports port 777        # multiling http

acl CONNECT method CONNECT

http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

http_access allow trusted_ip
http_access deny  black_dom
http_access allow limited_ip white_dom
http_access deny  limited_ip
http_access allow localnet
http_access deny  all

icp_access allow localnet
icp_access deny  all

htcp_access allow localnet
htcp_access deny  all

http_port 127.0.0.1:3128 transparent
http_port 192.168.0.106:3128

hierarchy_stoplist cgi-bin ?

emulate_httpd_log on
access_log /usr/local/squid/logs/access.log squid

cache_mem 0 MB
maximum_object_size 0 MB
maximum_object_size_in_memory 0 KB
cache_dir null /tmp
no_cache deny all
cache_store_log none

refresh_pattern ^ftp:            1440    20%    10080
refresh_pattern ^gopher:        1440    0%    1440
refresh_pattern -i (/cgi-bin/|\?)    0    0%    0
refresh_pattern .            0    20%    4320

icp_port 3130

coredump_dir /usr/local/squid/cache
error_directory /usr/local/etc/squid/errors/Russian-1251

есть ли возможность обойти эту ошибку?


Ответ на: комментарий от zunkree

Должно работать. Сам сейчас проверил с похожей конфигурацией.

uspen ★★★★★
()
Ответ на: комментарий от zunkree

клиент, работающий через прокси, не резолвит имена сам, а отдает урл из адресной строки Проксе, та уже сама с этим УРЛом разбирается

sdio ★★★★★
()

как выход - ставить проксю на своей машине никто не запрещает наверное ?

потом настроить его как sibling к шлюзовой и совсем захорошеет :)

MKuznetsov ★★★★★
()
Ответ на: комментарий от MKuznetsov

MKuznetsov> как выход - ставить проксю на своей машине никто не запрещает наверное ?

потом настроить его как sibling к шлюзовой и совсем захорошеет :)

Ужас! Просто букмарк в браузере добавить и все дела!

sdio ★★★★★
()
Ответ на: комментарий от sdio

букмарк не делал, решил сделать так создал на фре файлик /usr/local/etc/squid/hosts и прописал в нем:

ххх.ххх.ххх.ххх remote.server.work

а в конфиге прокси добавил запись

hosts_file /usr/local/etc/squid/hosts

рестартанул прокси и фигвам, не работает :(. Все равно та же ошибка.

zunkree
() автор топика

открываешь /etc/namedb/named.conf и прописываешь там зону для нужного домена

zone «remote.server.work» {
type forward;
forwarders {ххх.ххх.ххх.ххх; };
};




zup-rk27 ★★
()

у самого на работе прозрачный сквид на шлюзе.

очень часто приходится проверять работу каких-нибудь сайтов на удаленном виртуальном хостинге, поэтому всегда так делаю и 100% работает.

zup-rk27 ★★
()
Ответ на: комментарий от sdio

>клиент, работающий через прокси, не резолвит имена сам, а отдает урл из адресной строки Проксе, та уже сама с этим УРЛом разбирается

Прозрачный же прокси.

madcore ★★★★★
()
Ответ на: комментарий от madcore

madcore> Прозрачный же прокси
Упс, проглядел

sdio ★★★★★
()
Ответ на: комментарий от zup-rk27

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

zunkree
() автор топика
Ответ на: комментарий от madcore

>>клиент, работающий через прокси, не резолвит имена сам, а отдает урл из адресной строки Проксе, та уже сама с этим УРЛом разбирается

Прозрачный же прокси.

Да, но прокси получает пакеты через DNAT и не знает, на какой ip-адрес они шли, поэтому он берёт из заголовка запроса имя хоста и резолвит его сам.

ИМХО, без разницы, либо настраивать squid, либо DNS, все равно нужно изменять настройки сервера.

mky ★★★★★
()
Ответ на: комментарий от mky

Ну НАТ тут не причем, любой прокси так работает и непрозрачный.

Из-за одного урл огород городить, чем мысль с закладкой плоха?

lvi ★★★★
()
Ответ на: комментарий от lvi

Это точно, что из-за одного урля парить мозг не стоит, но зато походу разобрался получше в работе всего этого хозяйства. На данный момент проблема исчерпана, добавил урл просто в локальную зону днс. Всем кто откликнулся и помог — большое спасибо!!!

zunkree
() автор топика
Ответ на: комментарий от lvi

Разница есть. Прозрачный прокси подразумевает конфигурацию клиента на работу без прокси, то есть броузер должен резолвить имя в ip-адрес, а потом прокси получает запрос и опять резолвит его сам. То есть и клиент и прокси должны резолвить это имя. А в случае обычного прокси клиент не резолвит имена, поэтом насраивать нужно только прокси (для случаея, который хочет топикстартер).

mky ★★★★★
()
Ответ на: комментарий от mky

Мы говорим о прокси, в любом случае он должен резолвить. Если клиент не подозревает о существовании прокси, то прокси должен прикинуться веб-сервером, все конекты брать на себя. Вся разница в том как происходит конект с прокси, - сразу, либо всякий раз. А дальше http протокол, из 5-ти команд самая популярная GET, в которой урл в чистом виде. Оттуда он его и берет, выдернет из него имя хоста, отрезолвит, соединится с вэб-сервером, сверится с кэшем и так далее. И незачем ему лезть в НАТ, да и круто это как-то.

lvi ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.