#Cloudflare

🔒✨🐇 Сьогодні увімкнули ще одну можливість Cloudflare - а саме, генерацію сертифікатів TLS для користувацьких доменів. Це у них загадково називається Cloudflare for SaaS.

Як це виглядає для користувача: вони роблять CNAME на наш домен, підтверджують його на нашому боці, і отримують на своєму домені HTTPS з правильним сертифікатом (і контент з нашого сервера).

Як це виглядає для нас: наш сервер має бути підключений через Cloudflare Proxy (як це нормально буває, якщо ви користуєтесь Cloudflare.) Потім, після реєстрації клієнтського домену ми по Cloudflare API додаємо його як Custom Hostname. По HTTP домен працює відразу, а з HTTPS через хвилину.

Як це працює: зрозуміло, що Cloudflare, по-перше, має підтвердити власність домену. Це можна зробити або доданням DNS запису, або відповіддю на HTTP запит за заданим шляхом. Так от, HTTP-випробування за нас пройде Cloudflare Proxy - бо домен клієнта вже направлений на нього через CNAME. До нашого додатка цей запит навіть не доходить. Отакою простою магією без жодних зайвих зусиль користувача він отримує TLS-сертифікат (тобто, сам сертифікат — ні, а підтримку HTTPS - так.) Радію від таких рішень.

Фіча доступна навіть на безплатних планах, а коштує $0.10 на домен на місяць, при чому перші 100 доменів безоплатно. Було б добре придумати якесь цікаве некомерційне застосування.

💩🚚😬 Сьогодні весь вечір боролись з виснажливою DDoS атакою. Довелось випробувати, на що здатний Cloudflare. Отже, декілька спостережень:

• Платний план захищає суттєво краще, ніж безплатний (а у нас як раз чомусь скасувався платний, можливо, через перемикання картки.) Кількість заблокованих запитів більше у 20 разів. Думаю, це тому, що на безплатних користувачах Cloudflare і дивиться, який клієнт неблагонадійний. Хоча якщо грошей немає, то все одно від чогось Cloudflare вас захистить.

• Автоматичне блокування не ідеальне, тому раджу в реальному часі дивитись на характер запитів, та вручну створювати правила до фаєрволу. Так надійніше. Та, звісно, автоматичні правила продовжуватимуть роботу.

• Треба вмикати режим “під атакою”, тоді всі відвідувачі будуть проходити через JS перевірку. (Security level -> Under Attack.) При цьому, щоб не поламати API, для нього за допомогою Page Rules треба поставити інший рівень безпеки (і заздалегідь).

• Окремо нас порадував плагін Wordfence для WordPress. Здається, атака переповнила його базу, та вичерпала ресурси сервера. Вимкнули плагін повністю, бо за Cloudflare в ньому немає сенсу.

• Налаштуй сповіщення про DDoS, щоб не чекати скарг клієнтів.

А тепер, буду встановлювати macOS Ventura. 🌻

👨‍💻📢🥳 Сьогодні опублікував покращену стрічку для Hacker News, про яку писав у листопаді. Сама стрічка не змінилась — я їй користуюсь вже декілька тижнів і дуже задоволений. Довелося тільки перетворити її на продукт:

• Купив ще один короткий домен leonid.codes під майбутні проєкти. Знайшов класний сайт з порівнянням цін на домени - tld-list. На цей раз мені підійшов NameCheap.

• Щоб зʼявився HTTPS, під’єднав CloudFlare, який безплатно дає не тільки HTTPS, а ще й кешування і базовий захист. CloudFlare для мене — відкриття року. Бекенд залишився без змін: AWS S3 + Lambda.

• Далі, треба було додати хоч базову, але сторінку, бо сама по собі RSS у браузерах не відображається зовсім. Знайшов дуже простий CSS стиль SPCSS, мета якого — щоб звичайний HTML виглядав приємно. Це саме те, що для такого проєкту потрібно.

• Нарешті, налаштував “лояльну” аналітику Plausible, яка в мене підключена всюди. За неї доводиться платити, проте вона набагато легше та простіше за Google Analytics, та не торгує даними.

1. Якщо використовуєте Cloudflare, моя порада — встановити у правилах сторінок високий рівень безпеки для вашої сторінки логіну (а також, можливо, реєстрації та білінгу, залежить.) Це у Page rules -> додати -> Security Level: High. До такого висновку я прийшов після того, як припинив чергову атаку по підбору паролів на нашому сайті. А ще цікаво, що наш нападник, який мав доступ до тисячі IP-адрес, не здогадався міняти свій User Agent, і таким чином був легко відфільтрований та знешкоджений. Добре, що Cloudflare дає всі інструменти, щоб відділити злочинні запити від нормальних, та швиденько їх заблокувати. Погано, що я поки не знайшов способу автоматично помічати такі атаки раніше. Цього разу помітив через високе споживання процесора, але це трапилось суттєво пізніше початку атаки.

2. Всі інженери полюбляють узагальнені, універсальні рішення. Так приємно знати, що ти готовий до будь-чого. Але треба признати, що універсальність часто отримується в обмін на швидкодію. Іноді найкраща оптимізація — це прописати код чітко під задачу. Так в мене і трапилось: шукав шляхи оптимізації величезної SQL-вьюхи на будь-який випадок життя. А потім зрозумів, що насправді треба виписати найбільш популярні структури запитів, та зробити для них окремі, спрощені вьюхи. До речі, оскільки все це керується будівельником запитів на Ruby, то клієнти навіть не дізнаються, що від обраних аргументів міняється повністю весь запит. Так з єдиним інтерфейсом продовжуватимуть працювати як прискорені популярні запити, так і універсальні, але повільні.

Раптом після вчорашнього посту знайшовся ще один локальний рекурентний DNS сервер - Knot Resolver. Чим він гарний — це той самий сервер, який використовує Cloudflare для свого відкритого DNS 1.1.1.1. Це цікаво, бо самі автори Knot не гарантують його підтримку “в продакшні”, а тільки для простих споживацьких потреб. Втім, як бачиш, для Cloudflare його функціоналу вистачає (хоча Cloudflare додали власний кеш та ще дещо; кеш Knot не масштабується та обмежений однією машиною.)

Рекомендація від Cloudflare багато значить саме тому, що такий сервер буде давати результати, схожі на їхні. А значить, можна очікувати, що не буде незрозумілої клієнтам розбіжності, яку створював unbound. Взагалі це найбільший ризик з локальними DNS серверами — що невідомо, як вони себе поведуть в складній ситуації.

Щодо технічних деталей, то Knot Resolver встановлюється хоч на Linux, хоч на macOS, хоч в Docker; цікаво він конфігурується — файл конфігурації є скриптом на Lua. Можна кешувати запити, можна навпаки, кеш вимкнути. Можна використати в інтерактивному режимі, на кшталт dig.

Найбільші граблі, на які я наступив, поки налаштовував — це те, що DNS працює за протоколом UDP, та порти для нього треба відкривати окремо. Наприклад, в Docker: docker -p 35353:53/udp. Причому — підтримка TCP теж є — але як резервний варіант. Тому без відкритого UDP ваш DNS сервер працювати буде, тільки не з кожним клієнтом, та майже напевно з затримками. Піди та здогадайся, чому.

🇨🇿 До речі, Knot - продукт чеського доменного реєстратора CZ.NIC; на їхньому акаунті в GitHub можна знайти ще багато цікавого.

Статичний хостинг (тобто такий, що вміє тільки віддавати файли) - ніби найпростіша річ, абсолютний commodity. Втім, обрати між ними не так легко, як здається. Все залежить від того, які у вас очікування. Але ось в чому нюанс: як тільки скористуєшся одним статичним хостингом, то очікування поведінки фіксуються, та під час переїзду доведеться з ними рахуватися (або дізнатися, що сайт працює не до кінця, тільки пізніше.)

Нюанси починаються з правил перенаправлення. Будь-який сайт стикається рано чи пізно зі зміною адрес. Будь-який чемний сайт підтримуватиме старі адреси через механізм перенаправлень. Він всюди налаштовується за власними правилами — ось, наприклад, Vercel. А ось Cloudflare Pages. Все так, та не зовсім. Доведеться вручну коригувати та перевіряти. Коли перенаправлень сотні (так трапляється після реструктуризації сайту) - це вже ціла пригода.

Деякі хостинги підтримують адреси без слеша на кінці, а інші — ні. Технічно, ніби присутність слеша “правильніша”, оскільки ми віддаємо index.html для директорії — а не файл без розширення. Але те, що адреса сторінки виглядає як директорія, це принаймні дивно. Раніше мене це обурювало, зараз вже змирився та зробив все зі слешами (Звісно, через перенаправлення.) Також не всі хостинги готові взагалі показати index.html (бо це вже не просто “віддавати файли”, авжеж?)

Характер відвантаження файлів на хостинг теж відрізняється. Ось на Vercel примусово потрібно мати репозиторій на GitHub. Що гарно, поки в тебе немає величезних світлин або взагалі — завантажень на гігабайти. На Cloudflare Pages можна відвантажити на пряму, але не можна замінити єдиний файл — тільки все разом. На AWS S3 можна просто оновити окремі файли.

Нарешті, хоч і здається, що статичний хостинг — найшвидше, що може бути в вебі, насправді провайдери, особливо безплатні, не гарантують швидкості. В мене Ahrefs не раз скаржився на повільні сторінки на Vercel. А найшвидше сайт працював на власному сервері — але ж то незрівнянно складніше в підтримці. А ще, на власному сервері буде максимальна кількість особливих умов, та з нього найскладніше буде зʼїхати.

Хотілося закінчити на рекомендації конкретного хостингу, але її в мене немає. Хіба можу порадити не вигадувати власні обмеження (як я зі слешами), а триматися ближче до базової парадигми “сторінка = файл”.

Роздивлявся формат серіалізації Cap’n Proto. Його особливістю є відсутність копіювання даних. Це значить, що коли у вас є буфер даних (та схема до нього), то значення можна забирати прямо з буфера. Фактично Cap’n Proto не стільки серіалізатор, скільки формат організації даних у масиві памʼяті.

Схожих рішень не так багато. Можу відзначити flatbuffers від Google як справжню альтернативу. Тут треба обовʼязково роздивлятися, як воно підтримує вашу платформу (в моєму випадку - Go.) Взагалі я б сказав, що рідко трапляються обставини, щоб саме серіалізація була вузьким місцем.

Проте мені подобається те, що з масивом даних можна працювати по шматочках. Наприклад, якщо у вас є JSON в 1 Гб, то доведеться весь його завантажити та розібрати — навіть коли з нього потрібне одне значення. А якщо Cap’n Proto, то можна прицільно забирати конкретні записи та значення. Це гарно працює з mmap.

Також за моїми вимірами масив даних Cap’n Proto займає суттєво менше памʼяті, ніж еквівалентні структури Go. Особливо по витратах на керування памʼяттю. Там, де у звичайних структур спостерігаю надлишок майже в 100%, у Cap’n Proto його практично немає. Та й не дивно, бо в памʼяті утримується єдиний звичайнісінький масив байтів.

З незручного: Cap’n Proto не підтримує зміну довжини масивів (без перестворення). Також відсутній тип-словник. Словників взагалі в zero-copy не бачу — ймовірно, тому, що для ефективної роботи їх доведеться пересортовувати. Але словник завжди можна замінити пошуком за відсортованим списком.

Наразі автор Cap’n Proto працює у Cloudflare, а сам формат широко використовується у Cloudflare Workers, зокрема для зберігання даних.

Давно вже обмірковую цей переїзд. Зараз мій сайт і так доступний через Cloudflare, але розміщений на Vercel. Хочеться консолідувати майно; та можливо навіть почати платити за Cloudflare гроші — бо там багато є гарного по аналітиці та по захисту. (Але базовий статичний хостинг що там, що там безплатний.) До Vercel в мене найбільше нарікання — що час від часу Ahrefs скаржиться на повільність сторінок, що для статичного сайту дуже підозріло.

Сьогодні спробував перенести. Власне, сам зміст майже тривіально переноситься, і це сучасне досягнення. Обидва сервіси забирають сайт з GitHub, та обидва здатні викликати Hugo для збірки. Тобто майже без налаштувань зʼявляється нова копія. Єдине, що вилізло — це на CF Pages встановлений Yarn 3 та він чомусь не погоджувався з моїм Yarn 1. Але, оновити собі Yarn справа недовга.

(До речі, також всі схожі сервіси використовують спочатку тестові домени, тому підготувати переїзд можна спокійно на тестовому, а потім перемкнути DNS, коли вже буде впевненість.)

З несподіваного: у CF Pages є обмеження на розмір файлу — до 25 Мб. В мене є пара архівів, що його перебільшують. Але їх можна перенести кудись в S3 чи на його аналог - Cloudflare R2.

А ось де справжня проблема, так це з перенаправленнями. В мене після змін архітектури залишився список з близько 1000 застарілих шляхів. В Cloudflare є зручний файл _redirects, але вони надто примітивні для моїх потреб. Наприклад, у Vercel можна написати /page(/?), а у CF тільки двома правилами /page та /page/. Так я починаю упиратися в обмеження на кількість перенаправлень (2000 + 100 динамічних.)

В мене очевидно надлишковий список, можливо, доведеться його обрізати до реально потрібних. Або взагалі почати з порожнього та спостерігати за 404-ми. (Можна було б, за всі ці роки вже зібрати “живий” список старих посилань, але кому він був потрібний?)

Є ще варіант замінити 404-ту на функцію та обробляти перенаправлення там. Безплатно доступні 100 тисяч викликів функцій, вистачить з головою. Функції в Cloudflare потужні, там і база даних є, тож цікаво випробувати.