Про плохие интерфейсы
...и про то, как делать так, чтобы они были хорошими. Крайне интересное выступление Ильи Бирмана на прошедшей в июне конференции YFF, рекомендую к просмотру.
Заметки разработчика
...и про то, как делать так, чтобы они были хорошими. Крайне интересное выступление Ильи Бирмана на прошедшей в июне конференции YFF, рекомендую к просмотру.
Итак, у вас есть домен, который вы перенесли в Cloudflare. Сразу же после его добавления и настройки на платформе к нему автоматически выдаются два SSL-сертификата: основной и запасной, с разными Certificate Authority — Let’s Encrypt, Sectigo, Google Trust Services. Время жизни сертификатов — 3 месяца, после — автопродление. Удобно.
Вот, как это выглядит:
Обратите внимание, что это Edge Certificates. Поскольку платформа по-умолчанию проксирует трафик на сайт через себя, эти «пограничные» сертификаты используются только на участке «пользователь — Cloudflare». Там же можно включить настройку «Always use HTTPS», и ожидаемо получить автоматические редиректы — но только всё на том же участке! Трафик от Cloudflare до сервера будет передаваться без шифрования!
Обновив страницу блога, я получил несколько ошибок в консоли вида «Mixed content: request has been blocked» — падали асинхронные запросы, инициированные где-то в JavaScript. Также не работало сохранение записей и некоторые редиректы — видимо, всё по той же причине 😭
Опытным путем я понял, что надо бы шифровать весь трафик E2E, а для этого нам понадобится Origin Certificate — как раз-таки тот, который отвечает за оставшийся путь от Cloudflare до сервера (в моем случае до Nginx).
Нажав на кнопку «Create», мы получим, по сути, две строки: сам сертификат и приватный ключ для него. Для добавления их в Nginx Proxy Manager, я сохранил их как файлы и импортировал так, как показано на втором снимке в галерее ниже:
Отлично, осталось только подключить полное шифрование в Cloudflare...
...и протестировать, что получилось.
Добро пожаловать на новый домен: eviterno.online!
Сегодня хочу рассказать про то, как я подключил платформу Cloudflare для обеспечения безопасного доступа к сервисным приложениям, которыми я пользуюсь для управления этим сайтом.
Кратко про архитектуру: «под капотом» здесь VPS c Ubuntu 22.04, веб-сервер и база данных запускаются в Docker-контейнерах, для их удобного администрирования я использую Portainer. Также здесь установлен Nginx Proxy Manager (тоже в контейнере), который перенаправляет трафик с www на основной домен, обеспечивает подключение по HTTPS, проверяет подлинность домена, и т. д. В качестве удобного интерфейса для конфигурации сервера и доступа к терминалу я выбрал Cockpit.
Поскольку все эти инструменты — веб-приложения, доступные публично (мне хотелось иметь возможность подключаться с любого устройства), необходимо было по-максимуму защитить их от несанкционированного доступа. Да, у них у всех по-умолчанию есть формы авторизации, но проверка там однофакторная, по логину и паролю — они хоть и длинные, но все равно могут быть скомпрометированы путем фишинга или подбора. Также вполне возможно появление уязвимостей и эксплойтов для них, позволяющих, в теории, каким-то образом обойти защиту. В общем, хотелось бы что-то понадежнее, в идеале — вообще не давать случайному пользователю доступ к этим сервисам.
Zero Trust Tunnel позволяет связать субдомен и внутренний адрес на host-машине с установленным приложением-коннектором (его, кстати, тоже можно развернуть в контейнере). Не нужно открывать порты или отключать firewall, т. к. коннектор поднимает egress-соединение с облаком, и самое крутое — через панель управления Cloudflare можно также задать правила доступа к ресурсу и подключить дополнительный фактор аутентификации, например, отправку одноразового кода на почту или вход через Google-аккаунт.
То есть, можно буквально в два клика открыть доступ по HTTPS к localhost:9090 через private-service.my-site.com для тех, кто введет правильный email из whitelist’а и укажет верный код, отправленный в письме.
Красота! ❤️
Вот, как это выглядит в панели управления Cloudflare: на каждый «приватный» сервис я создал отдельный туннель. Обратите внимание на адреса — контейнер с коннектором cloudflared я добавил в bridge-сеть в Docker, которую создал вручную. Благодаря этому, во-первых, работает DNS, и можно обращаться к контейнерам по имени, а также легко можно получить доступ к host, указав Default Gateway.
Добавим policy с группой доступа по-умолчанию — у меня это «разрешить любому пользователю с email из списка получать одноразовый код на почту». Настраивать можно как угодно: работает фильтрация по странам, по IP-адресам, можно проверять токены и т. д.
Теперь при попытке обратиться к туннелю по public hostname, откроется форма авторизации. Выглядит она вот так, и её, кстати, можно настроить — добавить свой логотип, поменять цвет фона, написать какой-нибудь текст, добавить подсказки для входа.
На всякий случай повторюсь — если введенного адреса нет в whitelist, код просто не придет.
А ещё можно создать «приложения» и добавить их на главный экран — он называется App Launcher. Естественно, он тоже доступен только для авторизованных пользователей.
Отмечу, что работает это всё только с доменами, перенесенными в Cloudflare или изначально приобретенными у них. Мой был куплен в reg.ru, перенос занял минут 15, ничего сложного.
Весь описанный выше функционал абсолютно бесплатен, как и кэширование, защита от DDOS, и куча разных дополнительных виртуальных сетевых функций, но нужно привязать карточку. Наверное, единственный минус, который я могу выделить — Cloudflare функционально довольно перегружен: много дашбордов, панелей, настроек; но, благо, есть хорошая документация.
В Cloudflare можно автоматически добавить SSL-сертификат и настроить редиректы с HTTP на HTTPS — об этом читайте в следующей заметке.
Большое спасибо Михаилу Щербине за консультации.
На прошлой неделе вышло переиздание игры Braid 2009 года: добавили новые уровни, улучшили музыкальное сопровождение, перерисовали визуальную часть, появился раздел с комментариями разработчиков. Кто пропустил — крайне рекомендую попробовать! Braid: Anniversary Edition доступна на всех цифровых площадках, включая Steam и Google Play (на 4PDA можно найти версию для Android без привязки к подписке Netflix).
... и это я о wildcard-сертификате. Да, всё заработало.
Оказалось, что у reg.ru в личном кабинете нужно задать список IP-адресов (или сразу подсеть), с которых разрешается обращение к их API. Указав IP своей машины, я попробовал получить сертификат ещё раз — и запрос упал с Gateway Time-out.
Что ж, попробуем ещё раз — результат тот же.
ОК, у Nginx Proxy Manager есть параметр «Propagation seconds». Увеличив его в 2.5 раза, я снова словил таймаут, полез в логи посмотреть — и оказалось, что всё сработало!
Настройки nginx получились примерно следующие:
🔎 www.[domain]
301 ➡️
www.[domain] (wildcard-сертификат)
🔎 [domain]
принудительный переход на SSL ➡️ https + [domain] (отдельный сертификат под [domain])
Нет, в принципе, можно было бы обойтись и без wildcard-сертификата, просто это добавляет дополнительный шаг при создании очередного субдомена.
P. S. У cloud.ru потрясающая техподдержка. Если кому-то нужна бесплатная виртуальная машина на linux — наверное, это один из лучших вариантов на данный момент: тык
Галерею можно листать
Что мне особенно нравится — всё это удовольствие (сервер, IP, домен, SSL-сертификат, artifactory для Docker-образов) стоит всего
147 рублей в месяц*
+ 119 рублей за домен на год
* и первые 2 месяца бесплатно
18:30 | самый сочный дроп |
но слушать, конечно, надо полностью