Блог

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

Если существует веб-служба: https://www.ExampleSaasWebService.com/ и клиенты могут добавлять домены / поддомены vanity в white-label или перепродавать услугу и заменять доменное имя своим собственным, должен быть обратный прокси-сервер для прекращения трафика TLS доменов vanity и маршрутизации его на статически определенный серверный сервис (HTTPS) в исходном домене, отличном от vanity (по сути, существует один серверный сервер где-то еще в Интернете, а не в локальной сети, который принимает весь входящий трафик независимо от входящего домена). . По сути:

• «Клиент A» может настроить запись A / CNAME на VanityProxy.ExampleSaasWebService.com (хост, на котором запущен Traefik) с example.customerA.com .
• «Клиент B» может настроить запись A / CNAME на VanityProxy.ExampleSaasWebService.com (хост, на котором запущен Traefik) из customerB.com и www.customerB.com .
• и т.д…

Я (на удивление) не нашел ничего, что делало бы это из коробки, но, глядя на Traefik (2.x), я вижу некоторые многообещающие возможности, и это кажется наиболее эффективным инструментом для достижения этой цели. В первую очередь из-за интеграции Let’s Encrypt и возможности перенастройки без перезапуска службы.

Изначально я рассматривал встроенное управление сертификатами AWS и балансировку нагрузки, но я вижу, что существует ограничение в ~ 25 сертификатов на балансировщик нагрузки, что кажется неуместным. Предположительно, в любое время могут существовать тысячи доменов vanity.

Некоторые из моих вопросов, связанных с Traefik:

1. Правильно ли я понимаю, что вы можете обойтись без явного предоставления сгенерированного списка явных доменов тщеславия для создания сертификатов TLS в файлах конфигурации? Они могут быть определены на лету и предоставлены из Let’s Encrypt на основе заголовков входящих запросов / SNI?
   • Например, если запрос поступает на www.customerZ.com , а сертификата для этого доменного имени еще нет, его можно сгенерировать «на лету»?
   • Я нашел это примечание о флаге OnDemand в документах версии v1.6, но я изо всех сил пытаюсь найти эквивалентную документацию в документах (2.x).
2. Как я могу легко обмениваться «состоянием» (конфигурационными / динамическими сертификатами, которые уже были созданы) между несколькими серверами для совместного использования нагрузки с помощью служб AWS? Моей первоначальной мыслью была EFS, но я вижу, что общая файловая система EFS может не работать из-за зависимости от уведомлений об изменении файлов, которые не работают в файловых системах, подключенных к NFS?
   • Казалось, что имело бы смысл предоставить AWS NLB (со статическим IP и связанной записью DNS), которая доставляла запросы на парк из 1 или более из этих прокси-серверов Traefik с универсальной конфигурацией / состоянием, которые были надежно сохранены и синхронизированы.
3. Как я упоминал выше, это похоже на общую потребность. Есть ли образец файла конфигурации или проект, который мог бы стать хорошей отправной точкой, которую я упустил из виду? Я совершенно новичок в Traefik.
4. При маршрутизации запросов в серверную службу исходное Host имя все еще будет идентифицироваться где-то в заголовках? Я предполагаю, что он не может оставаться в заголовке хоста, поскольку серверная часть также получает запросы к имени хоста HTTPS.

Я продолжу экспериментировать и публиковать любые результаты здесь, но я уверен, что кто-то уже настроил что-то подобное — так что просто хочу не изобретать велосипед.

Мне удалось сделать это с помощью Caddy. Очень важно настроить запрос, интервал и пакет, чтобы избежать возможных DDoS-атак.

Вот простой пример обратного прокси:

 # https://caddyserver.com/docs/caddyfile/options#on-demand-tls
{
    # General Options
    debug

    on_demand_tls {
        # will check for "?domain=" return 200 if domain is allowed to request TLS
        ask "http://localhost:5000/ask/"
        interval 300s
        burst 1
    }
}

# TODO: use env vars for domain name? https://caddyserver.com/docs/caddyfile-tutorial#environment-variables
qrepes.app {
    reverse_proxy localhost:5000
}

:443 {
    reverse_proxy localhost:5000

    tls {
        on_demand
    }
}