Использование Redbird для обратного прокси для сайта HTTPS и его поддоменов на сервере node.js - PullRequest
Новая
       52

Использование Redbird для обратного прокси для сайта HTTPS и его поддоменов на сервере node.js

0 голосов
/ 14 марта 2019

Я пытаюсь понять, как использовать Redbird в качестве обратного прокси-сервера (кажется, меньше работы, чем nginx для устаревшего сервера узлов, но, возможно, я ошибаюсь), и я не могу понять их пример в файле readme, можетя не могу найти ответ в другом месте: https://github.com/OptimalBits/redbird

Моя настройка: у меня есть сервер узлов, работающий под «example.com», и мне нужно создать поддомен (api.example.com).Прямо сейчас устаревшее приложение, установленное на сервере, перенаправляет весь трафик с порта 80 на 443 и имеет установленный сертификат SSL (не LetsEncrypt, как я уже говорил, это устаревшее и, вероятно, до получения сертификата было бесплатным).Этот сертификат распространяется только на «example.com» и «www.example.com».После нескольких часов (ну, дней) попыток найти лучший способ добавления субдомена (для обслуживания через HTTPS тоже) я подумал, что это будет работать:

  1. ДобавитьA-запись для моего субдомена (api.example.com);
  2. Получите сертификат для api.example.com от Let's Encrypt;
  3. Измените устаревшее приложение, чтобы оно не 't прослушивает порт 80 (для перенаправления)
  4. Измените устаревшее приложение, чтобы оно слушало 7000 вместо 443
  5. Разместите мое новое приложение в сети и заставьте его слушать 7001
  6. Настройте Redbird для прослушивания 80 и перенаправления на 443
  7. Настройте Redbird для регистрации «example.com» и перенаправьте запросы на 7000 (с существующим сертификатом)
  8. Настройте Redbird для регистрации «api».example.com "и перенаправить запросы на 7001 (с моим новым сертификатом)

Я на правильном пути?

Примечание: я знаю, что у redbird есть функция для автоматического получения ssl-сертификатов, но, поскольку мне приходится использовать устаревший сертификат для основного домена (example.com), я решил, что не могу использовать автоматический способ.

Я могу пройти по списку до # 6, но тогда документация redbird для HTTPS смущает меня.Вот их пример: 

var redbird = new require('redbird')({
port: 8080, //??? => so this is the entry point? Why not 443 since we want only HTTPS?

// Specify filenames to default SSL certificates (in case SNI is not supported by the
// user's browser)
ssl: {
    port: 8443, //??? => what is this port for? Is it our default HTTPS port (in my case 443?)
    key: "certs/dev-key.pem",
    cert: "certs/dev-cert.pem",
}
});

// Since we will only have one https host, we dont need to specify additional certificates.
redbird.register('localhost', 'http://localhost:8082', {ssl: true}); //??? => this is the port my request will be forwarded too... right?

Я думаю, что из этого я получаю следующее: трафик, поступающий на локальный хост через порт 8080, перенаправляется на порт 8082. Верно?Но тогда зачем нужен 8443?

Едва понимая, что происходит, я попробовал следующее: 

var redbird = new require('redbird')({
port: 80,
secure: false,

// Specify filenames to default SSL certificates (in case SNI is not supported by the
// user's browser)
ssl: {
    port: 443,
    key: "/etc/cert/example.key",
    cert: "/etc/cert/example.crt",
}
});

// Since we will only have one https host, we dont need to specify additional certificates.
redbird.register('example.com', 'http://localhost:7000', {ssl: true});
redbird.register('api.example.com', 'http://localhost:7001', {
ssl: {
    key: "/etc/letsencrypt/api.example.key",
    cert: "/etc/letsencrypt/api.example.crt"
}
});

Почему у нас нет HTTPS вместо HTTP во втором аргументе redbird.register ()?

Излишне говорить, что вышеприведенное не работает, и когда я открываю example.com из своего браузера или api.example.com, он отвечает: «ECONNRESET».

ОБНОВЛЕНИЕ: я обслуживал оба приложения узла с HTTPS(на 7000 и 7001), и попытался подать их на прокси как HTTP.Я правильно прокси перенаправил запросы на соответствующие порты, НО только основное (устаревшее) приложение (на "example.com") имеет правильный сертификат SSL.Когда я открываю «api.example.com», я получаю предупреждение о том, что сайт не защищен ...

У меня возникает вопрос: нормально ли иметь основной домен с сертификатом от GoDaddy и поддоменом?от LetsEncrypt?Это причина того, что это не работает?

Когда я нажимаю в chrome на предупреждение «not secure» (при просмотре api.example.com), он говорит Cetificate (invaild) и показывает информацию о сертификате дляосновной домен (example.com) вместо сертификата, который я настроил для api.example.com ...

ОБНОВЛЕНИЕ2: поэтому я попытался получить новый сертификат для своего домена и всех его поддоменов (с использованием подстановочного знака* .example.com, а также примечание: * .example.com не включает example.com, поэтому его необходимо добавить вручную).С полностью инкапсулирующим сертификатом работает приведенный ниже код, но он намного медленнее, чем без Redbird в качестве обратного прокси-сервера (я ожидал разницу, но не так сильно, здесь мы говорим о разнице более 3 секунд - и сайт унаследовани не оптимизированы, эти 3 секунды находятся на вершине мучительных 8 секунд + с отключенным кешем). 

var redbird = new require('redbird')({
port: 80,
secure: true,

ssl: {
    port: 443,
    key: "/etc/letsencrypt/live/example.com/privkey.pem",
    cert: "/etc/letsencrypt/live/example.com/cert.pem",
}
});

redbird.register('example.com', 'http://localhost:7000', {ssl: true});
redbird.register('www.example.com', 'http://localhost:7000', {ssl: true});
redbird.register('api.example.com', 'http://localhost:7001', {ssl: true});

Вот несколько вещей, которые я могу вынести из этого опыта, и это может помочь другим:

  • порт, указанный в значении 80 выше, является портом входа для HTTP.Если вы укажете в этом же объекте часть ssl, redbird перенаправит весь HTTP-трафик на HTTPS (я не смог найти это в документации).
  • порт, указанный в 443 выше, является портом входадля HTTPS.Вы все еще не сделали переадресацию на данный момент, просто как бы объяснили redbrid, что к чему.Я думаю.
  • сертификат в объекте ssl должен быть файлом cert.pem, а не fullchain.pem (это не обязательно проблема redbird, а всего лишь одна из тех вещей, которые могут сбить людей с толку).
  • порт, где указаны 7000 и 7001, - это порты, на которые вы хотите перенаправить трафик (очевидно, но документация должна содержать очевидные вещи).
  • Наконец, что за объект {ssl: true} делает, это говорит redbird использовать вышеупомянутую конфигурацию SSL по умолчанию, альтернативой было бы указать другую конфигурацию для зарегистрированного домена, но я не смог выполнить эту работу (возможно, потому, что я имел дело только с поддоменами, и эта функция могла толькобыть не для поддоменов ... если это так, было бы хорошо иметь в документах).

Так что это разочаровывает, потому что (в порядке от наиболее важного до минимального):

  1. Кажется, что огромный успех на перф: я пропускаю параметр "prod", который мог бы улучшить это?
  2. Кажется, единственный способ, которым это работаетэто наличие всех приложений / серверов моего узла как http (не https) и указание на их порты (7000 и 7001), и прокси-сервер должен иметь только https.Это не слишком беспокоит, так как никто не может напрямую подключиться к портам 7000 и 7001, но я думаю, что 7000 и 7001 тоже могли быть https.Могут ли они быть?Или не имеет смысла иметь эти приложения в https, если прокси-сервер может с этим справиться?
  3. Я не смог сохранить старый (и дорогой) ssl-сертификат, срок действия которого еще не истек.Или есть способ, которого я не нашел?

Могу поспорить, что это так долго, что никто никогда не прочитает это ...

...