Мой хостер - по понятным причинам - сокращает IPv4-адреса, предлагаемые с новыми серверами, так что в следующий раз, когда я перенесу свои вещи на новый сервер, у меня будет огромное количество IPv6-адресов, но только один IPv4-адрес.
Для служб, для которых я запускаю только один экземпляр (например, SMTP), это не должно быть проблемой. Я просто проведу NAT через (используя iptables/6). Однако для других сервисов - и меня здесь особенно беспокоит HTTP / S - я вижу проблему в том, как передать входящий трафик на правильный гостевой компьютер и, очевидно, снова получить исходящие данные в туре для клиента.
Моя главная проблема здесь - безопасность. Думаю, я мог бы (ab) использовать один из обычных прокси или веб-сервер (nginx, lighttpd), который также может служить прокси. Однако в этом случае гостевые системы рассматривают это как «локальный запрос», и некоторые механизмы управления доступом могут дать сбой. Кроме того, HTTPS здесь является большой проблемой из-за зашифрованного трафика, хотя я мог бы, чтобы хост-система полностью реализовала части HTTPS и прокси-сервер от / до гостевых систем в незашифрованном виде (я использовал этот метод на одной машине, где экземпляр lighttpd служил как интерфейс к бэкэнду Apache2, обрабатывающему определенный набор URI).
Как я могу предложить ту же услугу (здесь HTTP / S) внешнему миру, даже если обработка отдельных доменов выполняется отдельными гостями? Или, скорее, что считается лучшая практика Эти дни?
[internet] <--> [IPv4:host] <-+-> [guest:foo.org]
|
|-> [guest:bar.org]
|
|-> [guest:baz.org]
... или я могу не обращать внимания на все эти проблемы, просто давая AAAA записи в эти домены и позволяя клиентской стороне обрабатывать все?
Я не вижу этого конца, кроме как «в следующий раз, когда я перенесу свои вещи на новый сервер, они будут на новом хосте с большим количеством IP-адресов». Если вы не планируете 3-5 лет вперед или ваши пользователи настоящие приятели, это, вероятно, закончится слезами.
IPv6 все еще не является массовым, без IPv4 у вас просто не будет посетителей. Просто наличие записей AAAA сделает сервер довольно простаивающим. По анекдотическому опыту, через 3-5 лет каждый выбросит свой дешевый беспроводной маршрутизатор по крайней мере один раз, возможно, к тому времени, когда люди купят новые, дешевые маршрутизаторы будут поддерживать его без использования OpenWRT.
Что касается безопасности, X-Forwarded-For: был разработан для того, чтобы серверы знали, какой IP-адрес подключен к обратному прокси, поэтому вам нужно переписать код сайтов, чтобы он смотрел на заголовок, а не на само соединение.
SNI был разработан для работы с виртуальными хостами SSL, и практически каждый текущий сервер поддерживает его, поэтому настройка обратного прокси-сервера из Apache или Nginx должна покрыть вас там. Если кому-то из гостей потребовались сертификаты SSL на стороне клиента, я не знаю, как эта информация о сертификате передается через прокси (я уверен, что она отправляется в заголовке). Настоящая проблема здесь в том, что в Windows XP IE не поддерживает SNI и получит сертификат виртуального хоста по умолчанию с любым именем хоста, которое они ввели. Надеюсь, ваши пользователи обновят Windows или переключатся на Firefox.