☰

Хостинг нескольких приложений из дома

tag-icon • tag-icon networking dns ssl nginx dynamic-dns
Хостинг нескольких приложений из дома

Я размещаю несколько приложений из дома. Мое текущее "грязное" решение - переадресация нескольких портов в моем маршрутизаторе. Недостаток в том, что мне нужно помнить, какие порты обслуживают какое приложение. Плюс, есть службы/приложения, которым нужен nginx спереди для обеспечения защищенных соединений TLS, например nextcloud.

Я хотел бы навести порядок. Идеальным решением было бы получить wildcard-сертификат letsencrypt и в nginx сделать что-то вроде (сокращенный псевдо-конфиг):

server {
    server_name nextcloud.mydyndnsdomain.org;
    location / {
        proxy_pass https://internalip:port;
    }
}
server {
    server_name someotherapplication.mydyndnsdomain.org;
    location / {
        proxy_pass https://internalip:anotherport;
    }
}

Проблема в том, что я не могу найти провайдера dyndns, который разрешает поддомены. Разрешены несколько имен хостов, но не поддомены к ним.

Еще одно решение, которое я придумал, было бы таким:

server {
    server_name mydyndnsdomain.org;
    location /nextcloud/ {
        proxy_pass https://internalip:port;
    }
    location /someotherapplication/ {
        proxy_pass https://internalip:anotherport;
    }
}

Проблема в том, что как только я работаю, например, с nextcloud, дальнейшие ссылки больше не работают, так как отсутствует /nextcloud/в URL. Поэтому "более правильная" версия этого будет

server {
    server_name mydyndnsdomain.org;
    location /nextcloud/ {
        redirect 301 https://internalip:port;
    }
    location /someotherapplication/ {
        redirect 301 https://internalip:anotherport;
    }
}

Проблема в том, что я больше не пользуюсь защищенным TLS-соединением и мне все равно приходится перенаправлять порты на маршрутизаторе и т. д. и т. п.

Или, конечно, я регистрирую несколько имен хостов у своего провайдера dyndns. Но тогда мне снова понадобятся несколько сертификатов, и я буду ограничен определенным количеством имен хостов. И мне придется помнить, какое приложение обслуживается под каким именем хоста.

Итак, мой вопрос: как это делают другие? Какое рекомендуемое решение? Или я что-то не понял из-за своих плохих навыков работы с nginx?

решение1

Все три метода можно довольно легко реализовать.

Проблема в том, что я не могу найти провайдера dyndns, который разрешает поддомены. Разрешены несколько имен хостов, но не поддомены к ним.

Купите свой собственный домен, тогда вы сможете создать столько поддоменов под ним, сколько захотите. Есть два способа заставить его обновлять адреса динамически:

Сделай сам:Купите собственный домен, разместите его серверы имен у DNS-провайдера, имеющего какой-либо API, убедитесь, что для записей DNS A настроен достаточно низкий TTL (например, 5–10 минут), и все — у вас есть собственный «dyndns» с неограниченным количеством поддоменов.

Сообщество Certbot/LetsEncrypt может быть хорошим источником совместимых (т. е. автоматизируемых) поставщиков DNS, поскольку для получения wildcard-сертификата от LetsEncrypt требуются DNS-проблемы, так что эта функциональность вам понадобится в любом случае. (Не то чтобы вам нужен wildcard-сертификат, на самом деле...)

Разница между обновлением записей TXT с помощью Certbot для задач LE и обновлением записей A с помощью клиента dyndns очень мала, а некоторые поставщики DNS даже имеют API, совместимый с обновлениями dyndns.


¹ Хост сервера имен не обязательно должен быть там же, где и регистратор, который продал вам домен — все регистраторы позволяют вам менять адреса серверов имен, поэтому вы можете, например, купить домен на Namecheap, но разместить DNS на Linode или Route53 или где-то еще, где вам удобнее.

² Единственное, что осталось, этовнутреннийзадержка распространения между серверами имен DNS-провайдера — хотя большинство провайдеров начинают обслуживать новые записи сразу после их отправки, есть и такие, которые перезагружают свои базы данных только каждые 10–15 минут, поэтому будьте осторожны с ними, если вам нужны очень быстрые обновления.


Использовать текущего провайдера:Купите свой собственный домен, используйте записи CNAME, чтобы направить его различные поддомены на ваше существующее имя dyndns. Это не требует дополнительных настроек, ни со стороны провайдера Dyndns (они не могут отличить распознаватель, следующий за CNAME, от того, который просто делает прямой запрос), ни с вашей стороны (использование CNAME невидимо как для HTTP, так и для TLS). Подойдет любой обычный сервер имен, поскольку сами записи CNAME не требуют обновления.

Когда CNAME на месте, когда вы посещаете, например,https://cloud.example.comвы автоматически получите IP-адрес example.dyndns.org, но Nginx все равно будет считать, что вы пытаетесь посетить cloud.example.com, и выберет правильный блок server{} и сертификат.

У этого варианта есть два недостатка: теперь вы управляете конфигурацией домена черездваслужбы, и вы по-прежнему ограничены только обновлениями IP-адресов — вы, скорее всего, не сможете использовать это для задач LE DNS, поэтому вам не подойдет wildcard-сертификат.

как только я работаю, например, с nextcloud, дальнейшие ссылки больше не работают, так как в URL отсутствует /nextcloud/.

Большинство веб-приложений можно настроить так, чтобы они ожидали себя на любом базовом URL, который вы хотите. Например, Nextcloud имеетпереписатьwebrootвариант для этого.

Поэтому «более правильной» версией этого будет

redirect 301 https://internalip:port;

Нет, если вам нужно, чтобы приложения были доступны извне, это действительно должно быть вашимвнешнийадрес (и порт) — весь смысл перенаправлений в том, что они обрабатываются клиентом, и внешние клиенты не смогут подключиться к вашему внутреннему IP-адресу.

Проблема в том, что я больше не могу пользоваться преимуществами защищенного TLS-соединения.

Если ваши перенаправления указывают на разные порты одного и того же домена dyndns, то ничто не мешает вам обслуживать TLS на всех этих нескольких портах одного и того же домена, даже используя один и тот же сертификат.

Если некоторым веб-приложениям нужен фронтенд для TLS, то просто настройте тот же Nginx с большим количеством server{}блоков listenна разных портах. Например, на порту 443 вы можете обслуживать перенаправления, а на порту 8443 вы можете проксировать /на Nextcloud.

Связанный контент