CityCat4

У серверов общий корневой центр выдачи, но разные промежуточные центры выдачи сертификатов.

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

Что можно сделать?

Можно конфиг показать. И вывод лога cache.log.

без необходимости каких либо манипуляций с браузером у сотрудников

нужно про кто куда заходит

Данная задача не имеет решения.

Чтобы раскрывать https-соединения, нужен bumping. Bumping не настроить без доверенного сертификата. Довернный сертификат нужно распространять по всем компьютерам. Первое условие - оно ведь на самом деле читается как "я не хочу заниматься инструктированием юзеров/я не умею настраивать глобальные политики/у меня нет авторитета и юзера меня шлют на ... юг", потому что какая бы ни была большая контора - все это делается достаточно быстро - если конечно на это есть распоряжение начальства, а не собственная хотелка.

Технического решения нет, потому что задача не техническая, а административная.

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

Завести еще один VPN, куда будет коннектиться первый VPN и через кого будет выходить трафик....

Понять, что это все было бесполезно, когда придут и положат "на лице свое" :)
(Впрочем, если в модели нарушителя нет государства - может и сработать)

Зачем? (Ну в смысле - зачем каждому юзеру свой порт?)
Есть предположение, что Вы решаете задачу неверно :)

Зачем Вам прозрачный прокси? В обычном режиме обычные юзеры получают настройки прокси через GPO или руками админа и обычно работают.

А что смущает? squid все правильно пишет - сейчас практически всюду, даже там где и не надо https, а в нем все запросы внутри туннеля.
Чтобы видеть содержимое туннелей, squid должен работать с бампингом.

Нет там ничего сложного.

Кэш - в зависимости от потребностей - один юзер много ли сожрет?
cache_dir diskd /var/spool/squid 5000 32 32
5Gb мне по крайней мере хватает.

Аутентификации никакой - нафиг она? Контроль доступа примитивный по IP:

acl scat           src             10.1.1.1
acl ltroll         src             10.1.1.2

http_access allow scat
http_access allow ltroll

# And finally deny all other access to this proxy
http_access deny all

Из всех остальных параметров ну еще может пара меняется

Ищи статью из журнала "Системный администратор" #7-8 за 2019 год под названием "Особенности корпоравтиного применения squid контроль https-соединений"

Где-то в районе прошлой осени в "Системном администраторе" была статья на тему настроек squid и доступа по группам

В конце 2019 года незадолго до того, как сдохнуть в "Системном администраторе" была пара статей по настройке squid по аутентиифкации через керберос и управлении группами через AD. Задача вполне решаема на одном прокси. Она решаема даже без управления группами, но там в статье еще про бампинг, без которого нынче весь контроль доступа сьеживается до контроля первичного захода и то при условии, что DoH не задействован или сервера DoH заблокированы.

Для обычного сквида достаточно блокировки выхода в обход прокси.
Сквид без бампинга сейчас практически бесполезен - все на https. Без бампинга захватывается сайт из CONNECT, что может быть совсем не то, куда пошел юзер.
Я приводил уже пример:
юзер создает сайт с унылым производственным именем metricheskiy-krepeg.ru (или еще каким, но таким, чтобы соответствовал тематике производства и вызывал у админов чувство уныния :) ). А внтури делает страничку с переходами на ВКонтактик, love.mail.ru и tightwetholes.com :)
Вопрос: что увидит админ в логе прокси

Пардон, вот это классический пример того, что бывает, когда вместо вникания в суть - ограничиваемся копипастом :)

Авторизация в сквиде - это отдельная тема десятка статей :) Она делается не менее чем тремя способами, но актуален в настоящее время только один - через negotiate_kerberos_auth. Там довольно длинная процедура, я ее уже плохо помню, была статья в "Системном администраторе", давненько правда, еще в 2012 году. Статья называлась "Squid + AD - samba"
Создается учетка в AD
К ней вяжется принципал через ktpass (это виндовая команда)
Этот принципал указывается в конфиге сквида и получается что-то типа:

auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -k /etc/proxy.keytab -s HTTP/fat.zhopa.ruchka@ZHOPA.RUCHKA
auth_param negotiate children 30 startup=0 idle=1
auth_param negotiate keep_alive on

Если нужно рулить еще и группами (а иначе зачем wbinfo_group.pl?) - то в том же Системном администраторе в прошлом году незадолго до того, как ему сдохнуть - была статья про управление группами

Не вижу применения ACL NoSSLIntercept.
Возможно, там принципиально нестандартный протокол, тика как в QUIK (который на любую попытку бампинга просто дропает соединение и все)

Едрить, negotiate_kerberos_auth работает с неведомо лохматых времен, года ... ну у же не помню, с 2010 наверное... Еще есть ext_kerberos_ldap_group_acl - что эа любовь к некрософту? Разве SquidGuard еще жив?

В кидательном журнале "Системный администратор" (который в прошлом году меня знатно кинул, потом вроде пообещал исправиться, но не исправился) была пара статей по настройке сквида, одна из них точно была посвяшена теме управления доступом через группы AD

grep -e "1.2.3.4" access.log

external_acl_type inet_medium ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g Internet-medium@DOMEN.LOCAL

Вот тут у меня стоит еще -D DOMEN.LOCAL и -a (принимать все сертификаты без проверки на валидность)

Настроен squid с интеграцией через керберос с AD

В случае отключения основного DC1, squid при запуске браузера начинает запрашивать логин пароль

Ну значит либо такая интеграция, либо такая AD. Потому что в нормальной AD MS где-то там внутри себя обеспечивает переключение между DC.

Строку auth_param, которая настраивает интеграцию с AD покажите

Любая задача начинается с определения категории нарушителя. От кого Вы собираетесь защищаться? Жена, друг, сосед, админ, провайдер, государство? Возможности у всех разные и соответственно ответ на вопрос будет разным.
Полная анонимность невозможна в принципе - ну если только комп от сети отрубить и сунуть его в наглухо запаянную и заземленнную железную коробку :)

если кто-то залезет на машину

Что значит "залезет на машину"? Заберется на капот и попрыгает? Если скажем "люди в сером" уже пришли к Вам - Вас не спасет никакая анонимность - паяльник в #опе - пренеприятнейшая штука...