Здрасьти!
Давно использую squid на корпоративном шлюзе в инет.
Теперь задался вопросом: можно ли организовать прозрачное проксирование запросом БЕЗ NAT?Т.к. у клиентов сейчас белые адреса.
>Теперь задался вопросом: можно ли организовать прозрачное проксирование запросом БЕЗ NAT?Т.к. у
>клиентов сейчас белые адреса.А Вам кто-то сказал, что NAT можно делать только из "серых" адресов в "белые"?
Передайте ему, что он не прав.Про сквид: можно, наверное. Только исходящие соединеия будут (без дополнительных приседаний?) идти с адреса сквида, а не клиента... Или нет?
Ничего не понимаю в прозрачных осьминогах. На кой оно _такое_ http:/openforum/vsluhforumID12/5890.html#3 надо?
>[оверквотинг удален]
>
>А Вам кто-то сказал, что NAT можно делать только из "серых" адресов
>в "белые"?
>Передайте ему, что он не прав.
>
>Про сквид: можно, наверное. Только исходящие соединеия будут (без дополнительных приседаний?) идти
>с адреса сквида, а не клиента... Или нет?
>
>Ничего не понимаю в прозрачных осьминогах. На кой оно _такое_ http:/openforum/vsluhforumID12/5890.html#3 надо?
>Дело в том что хочется чтобы у запросов на выходе оставлись клиентские адреса. Задача ввообще в том, чтобы использовать кэш без изменения информации об адресе запроса.
типа клиент послал запрос, запрос попал в squid, он пошарлся в кэше, если есть - выдал, если нет - то нет, и запрос пошел уже дальше но НЕ от имени squid
вот думаю какбы так извернутся
>Задача ввообще в том, чтобы использовать кэш без изменения информации об адресе запроса.
>типа клиент послал запрос, запрос попал в squid, он пошарлся в кэше,
>если есть - выдал, если нет - то нет, и запрос
>пошел уже дальше но НЕ от имени squidМыслей две. Во-первых, прозрачный сквид, как Вы, возможно, заметили, -- "костыль страшный"(тм). А то, чего Вы желаете (да, оно возможно - теоретически...(1)), это костыль даже не двойной, а в квадрате. Хотя, может, это я злобствую -- всем надо, а я не даю. Во-вторых, Если ответа не было в кеше и запрос "не через сквид", откуда бы ответам вообще %) в кеше взяться. (Предполагаю, что не кешированные ответы надо в кеш класть...)
(1)Какие-нибудь "апаратные" кеши от проприертарных разработчиков м.б. что-то подобное и умеют... Чтоб на сквиде такое делали - не слышал. М.б. - недостаок образования.
(1'бис)Кто тут чаще про ядро читает -- не пытались ли что-то такое (или функции для поддержки) делать для ядра (и сквида - тоже, ведь в нём же нужно или соединение с чужого адреса создавать, или сказать ядру, чтобы раз-редиректило назад, и слушать-писать ответ)? Навскидку как-то сложно получается - очень сложный код для очень небольшого числа пользователей. ~"Эт-т вряд ли."
В *BSD B-) как с такими авангардными начинаниями, BTW?
> вот думаю какбы так извернутся
Ну, как обычно: компилятор, исходники сквида и ядра в руки и пилить**3. |-?
>можно ли организовать прозрачное проксирование запросом БЕЗ NAT?
>Т.к. у клиентов сейчас белые адреса.Ещё комментарий: Тот NAT, что _нужен_ для прозрачного сквида, есмь [подвид] redirect. А тот, что "для серых - в белые" -- SNAT и/или MASQUERADE. Два разных NAT-а.
И "белый" адрес при запросе ч/з прозрачный сквид прояаляется, когда он, сквид, открывает своё _внешнее_ соединение, которое идёт с его, сквида, "белого" адреса. Не NAT, но "прокси уровня приложения".