Хосты для ProxMox кластера не обязательно должны быть с одинаковой аппаратной конфигурацией.
Важно - чтобы процессоры инструкциями не особо сильно отличались и архитектура их совпадала.
Для настройки нужно погуглить squid transparent ssl proxy, почитать про SSL bumping и настроить.
Могли бы вы уточнить - на каком пункте у вас возникла проблема?
Не знаю, что у вас за ошибка - но у вас неправильный подход.
Правильный - поднять новый виртуальный контроллер домена, передать ему все роли, перенести все нужные настройки и вывести из домена старый контроллер.
Нужно для каждого адреса/virtualhost - для api.frontserver.com и api.targetserver.com - настроить стандартно SSL и прикрутить каждому свой сертификат и private key.
Как настроить - зависит от того, что у вас висит на этих хостах - гугл в помощь.
Маршруты с включенным и выключенным сравнивали?
Включенное проксирование заворачивает весь траффик сайта через Cloudflare, которого теоретически в РФ не должно быть.
Выделить внутренний порт на первом роутере в DMZ (без доступа к остальным портам), воткнуть в него второй роутер и настроить.
Но большинство роутеров умеют из коробки гостевую WIFI сеть, так что стоит только настроить ее на первом роутере.
Во всех нормальных облаках есть возможность декларативного описания шаблонов нужных ресурсов в json\xml и их автоматического развертывания через cli\powershell\api\web interface и т.п.
А еще есть terraform\ansible\puppet и т.п.
Нужно обеспечить маршрутизацию и прохождение трафика на всем пути следования этого трафика. Так как wireguard не умеет управлять таблицамми маршрутизации на сервере и клиенте - то потребуется настройка маршрутизации на всех хостах, начиная с клиента wireguard, продолжая сервером wireguard и заканчивая всеми хостами в локальной сети, куда нужен доступ.
Альтернативой может быть использование NAT на сервере wireguard.
Открываете любую статью по запросу "nginx real ip to apache", делаете, что там написано, понимая, что поле будет другое и формат лога apache придется тоже изменить.
