То, что у меня есть, просто, но у меня проблема с VPN, которую я не знаю, как решить. В общем, я хочу по-другому маршрутизировать общедоступные домены в VPN. Посмотрите текущую роль хоста Debian:
foo.example.com с HTTPS, обслуживаемым обратным проксиfoo.example.com:443Таким образом, этот хост является VPN-сервером и содержит некоторые виртуализации для обслуживания HTTPS для некоторых общедоступных (под) доменов. Так что в настоящее время traceroute foo.example.org попадает на хост-машину.
Для людей, подключенных к VPN, решение будет другим:
curl foo.example.org больше не будет подключаться к хост-машине (как обратный прокси), а напрямую к виртуализации (10.1.2.3).ssh foo.example.org также больше не будет подключаться к хост-машине, а к виртуализации (10.1.2.3).Я надеюсь, что все это можно настроить на OpenVPN-сервере, в файле .ovpn-Config или на хост-машине. Потому что я предпочитаю упростить клиентам задачу, просто предоставив им конфигурацию .ovpn и ничего больше (почти).
Подсказка: ovpn-Config содержит сертификат для подключения к VPN, если это интересно.
С OpenVPN вы можете использовать push возможность отправить этот адрес DNS-серверов клиенту.
В bind DNS-сервер можно настроить для обслуживания разных данных в разных представлениях. Представления могут быть назначены в зависимости от исходных IP-адресов.
Таким образом, вы можете настроить свой DNS-сервер так, чтобы он по-разному отвечал на диапазон IP-адресов, которые вы назначаете своим VPN-клиентам.
Другой вариант - использовать VPN-сервер в качестве шлюза по умолчанию, а затем использовать iptables для перенаправления пакетов на ваши виртуальные машины. Это сделает все перенаправление прозрачным для клиентов.