Здрасьти!
Давно использую squid на корпоративном шлюзе в инет.
Теперь задался вопросом: можно ли организовать прозрачное проксирование запросом БЕЗ NAT?Т.к. у клиентов сейчас белые адреса.

• не NAT :-O,Andrey Mitrofanov, 11:32 , 23-Дек-08
  • не NAT :-O,bodom, 12:09 , 23-Дек-08
    • не NAT :-O,Andrey Mitrofanov, 14:41 , 23-Дек-08
• Tranparently Crutched Squid,Andrey Mitrofanov, 20:28 , 23-Дек-08

>Теперь задался вопросом: можно ли организовать прозрачное проксирование запросом БЕЗ 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, но "прокси уровня приложения".