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

Проблема.

Всем привет,

Мне нужно, чтобы на определенном сервере было небольшое количество виртуальных машин. На каждой машине должна быть своя собственная конфигурация прокси, но запущенное на них программное обеспечение не имеет надлежащих возможностей настройки прокси, поэтому конфигурация прокси на гостевой машине невозможна. Моя цель - направить столько трафика, сколько позволяет мой внешний прокси, а не только HTTP.

Я использую VirtualBox, работающий на сервере Ubuntu, подключенный к маршрутизатору с прошивкой Tomato (представьте его как крошечный ящик Linux). Виртуальные машины подключены к маршрутизатору через мостовое соединение, поэтому маршрутизатор видит каждую из них независимо; Я бы настоятельно предпочел оставить это так, потому что очень удобно иметь возможность разговаривать с каждой из виртуальных машин по ее IP-адресу (я могу сделать его статическим). Я открыт для использования другого серверного программного обеспечения, но я не вижу причин, по которым моя текущая установка не работает. Я подумал о нескольких разных вариантах и ​​хотел бы знать, есть ли у кого-нибудь представление о том, какой из них лучше всего, или я вообще упускаю лучший вариант:

Опция 1.

Мне удалось успешно установить и настроить прокси-сервер squid3 на моем сервере Ubuntu (тот же, на котором работают виртуальные машины), который взаимодействует с проверенными прокси-серверами в дикой природе. По соображениям безопасности я включил только локальные подключения к прокси-серверу, и другие машины в той же сети могут использовать подключение к локальному прокси, который, в свою очередь, перенаправляет их на внешний прокси:

Local Machine -> Ubuntu Server (squid3) -> External Proxy

К сожалению, как я упоминал выше, виртуальные машины не имеют возможностей прокси-клиента. Я думал, что могу направить весь трафик сервера через его собственный сервер Squid, но, поскольку виртуальные машины имеют мостовое соединение, они обращаются к маршрутизатору напрямую. Чтобы смягчить эту проблему, я пытался перенаправить трафик виртуальных машин с маршрутизатора обратно на сервер Ubuntu:

Virtual Machine -> Tomato Router -> Ubuntu Server (squid3) -> External Proxy

До сих пор у меня не было большого успеха с этим подходом, так как я теряюсь в деталях, как перенаправить трафик для всех портов, и я никогда раньше не работал с iptables. Даже если бы мне удалось перенаправить весь трафик обратно на сервер squid3, я не знаю, как я смогу применить индивидуальные настройки прокси к каждой из виртуальных машин. Нужно ли мне настраивать сервер squid3 для каждой виртуальной машины? Я почти уверен, что squid3 позволяет мне фильтровать по входящему IP, но cache_peer "proxy-host" parent "proxy-port" 0 no-query default login=username:password вариант, который я использую для разговора с внешними прокси, похоже, ведет себя глобально.

Вариант 2.

Я мог бы установить прокси-сервер squid3 на маршрутизатор Tomato и сделать все то, что я описал в первом варианте, на самом маршрутизаторе, но я еще не смог установить прокси-сервер. Так же, как я задавался вопросом о первом варианте, нужен ли мне другой прокси-сервер для каждой из виртуальных машин? Макет был бы очень похож:

Virtual Machine -> Tomato Router (squid3) -> External Proxy

Вариант 3.

Несмотря на то, что я бы предпочел поддерживать мостовое соединение от виртуальных машин к маршрутизатору, возможно, есть способ подключиться к виртуальным машинам через NAT и использовать сервер squid3 либо на сервере Ubuntu, либо на маршрутизаторе Tomato (если я могу сделать это работает).

Вопрос.

Какой вариант будет лучшим решением моей проблемы? Есть ли лучший способ подойти к этому, который я не рассматривал?

Обновить.

Видимо, я ошибался насчет того, что кальмар не может справиться с cache_peer директиву на клиентской основе, а не глобально, я могу просто использовать cache_peer_access. В настоящее время я пытаюсь выбрать вариант 1, пока кто-нибудь не даст мне более вескую причину не делать этого. Это конфигурация, которая у меня есть для /etc/squid3/squid.conf:

Изменить: обновлен http_port в соответствии с предложением

# acl definitions here
acl localnet src 192.168.1.0/24
acl localhost src 127.0.0.1

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

# any client in the local network has access
http_access allow localhost
http_access allow localnet

# And finally deny all other access to this proxy
#http_access deny all
http_access allow all # test only

# external proxy settings
http_port 3128 transparent
cache_peer XXXX.XXXX.XXXX.XXXX parent 80 0 no-query default login=user:pass

# No direct access
never_direct allow all

# do not forward the IP address
forwarded_for off

Трафик перенаправляется с маршрутизатора Tomato на мой сервер Squid. Для этого я использую следующие iptables (виртуальные машины ограничены IP-адресами в диапазоне 192.168.1.50-192.168.1.100, что обеспечивается статической привязкой MAC-адреса к IP через DHCP-сервер):

PROXY_IP=192.168.1.115
REDIRECT_PORTS=443,80,21,70,210,1025:65535,280,488,591,777
iptables -t mangle -A PREROUTING -p tcp --dport 80 -s $PROXY_IP -j ACCEPT
iptables -t mangle -A PREROUTING -m iprange --src-range 192.168.1.50-192.168.1.100 -p tcp -m multiport --dport $REDIRECT_PORTS -j MARK --set-mark 3
iptables -t mangle -A PREROUTING -m iprange --src-range 192.168.1.50-192.168.1.100 -p udp -m multiport --dport $REDIRECT_PORTS -j MARK --set-mark 3
ip rule add fwmark 3 table 2 
ip route add default via $PROXY_IP dev br0 table 2

А затем снова на сервере Ubuntu:

iptables -A PREROUTING -t nat -p tcp -m multiport --dport $REDIRECT_PORTS -j REDIRECT --to 3128
iptables -A PREROUTING -t nat -p udp -m multiport --dport $REDIRECT_PORTS -j REDIRECT --to 3128