Как настроить HTTP-кеширующий прокси внутри NAT, который не является шлюзом?

У меня есть следующая настройка устройств уровня 2 и 3 OSI в моей IPv4-LAN с подключением к Интернету за NAT (все клиенты и серверы находятся в 192.168.1.0/24)

Internet
    |
Gateway (WiFi-"Router")/NAT
    |---------------------------------------------------------|
Switch                                                        |
    |--------------|-----------------------|                  |
Proxy client 1  Proxy client 2         Proxy server      untouchable
 (iptables)      (iptables)             (iptables)        client(s)

то есть некоторые машины, которые должны работать в настройке без необходимости касаться конфигурации их сети (неприкасаемые клиенты). Proxy client N а также Proxy server запустить Linux и полностью настраивается (например, с iptables).

Я хотел бы настроить Proxy server а также Proxy client 1 так что каждый HTTP-запрос Proxy client 1 делает сделано через Proxy server где ранее извлеченные запросы кэшируются и в конечном итоге обслуживаются, чтобы избежать извлечения из Интернета. Все устройства, кроме шлюза, имеют только одну сетевую карту.

Что я пробовал (для Proxy client 1 чтобы заставить его работать один день и для большего количества клиентов):

• настройка NAT на Proxy Server с помощью fwbuilder и это средства перенаправления, как описано в руководстве пользователя fwbuilder, перенаправляя все с 192.168.1.0/24 на порт 80 до Proxy server на порт 3128, где squid 3.5.3 экземпляр с http_port transparent Директива настроена на прослушивание.
• установить маршрут по умолчанию Proxy client 1 быть Proxy server и настроил виртуальный интерфейс на основе единственного физического интерфейса Proxy server,
• выясните, относится ли "DNAT к той же сети" в руководстве пользователя fwbuilder к моему случаю, но, насколько я понимаю, он настроил настройку NAT на шлюзе.

squid журналы не показывают никакой активности.

Если есть способ создать такую ​​установку с другим программным обеспечением, чем squid проще, я был бы рад предложениям.

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