Почему не стоит использовать проксирование через Cloudflare
Есть такая замечательная штука как Cloudflare. Почти все знают его и много кто использует его не только как DNS провайдера, но и как обратный прокси с CDN (для чего он больше и заточен). Но мало кто задумывается, как он работает и с чем они могут столкнуться при его использовании. Просто добавляют туда домен, включают проксирование, подключают халявный SSL сертификат и думают, что Cloudflare станет волшебной палочкой от всех проблем.
Проблемы при проксировании через Cloudflare
А теперь набросаем говна на вентилятор 😈
Нет никакой гарантии защиты от DDOS
Многие думают, что бесплатный тариф Cloudflare защитит их от DDOS’ов, но хрен там. Лучшее, что он сделает при DDOS’е, так это выдаст страницу с ошибкой, пока не закончится атака. На этом все. Бесплатно Вам никто не будет фильтровать трафик, т.к. это стоит ресурсов и, соответственно, денег. Придется раскошелится на платные тарифы. И то ходят слухи, что нормальная фильтрация трафика будет только на тарифе Enterprise.
Совсем немного поможет включение капчи при входе подозрительных личностей на сайт, но не забывайте, что алгоритм часто работает не как надо, а неудачливые юзеры будут терпеть это издевательство над ними.
Нестабильная работа
Cloudflare может внезапно без предупреждения выключить проксирование по абузе или если им покажется, что Вы слишком много трафика прокачиваете на бесплатном тарифе.
Также может что-нибудь сломаться. Но от ошибок никто не застрахован.
Еще часто замечаю 521 ошибки. Причем чаще всего эти ошибки не связаны с тем, что они пишут в документации. Да, я проверял много раз, возникновение ошибки не было связано с файрволом, ошибками на сервере и с доступностью. Остальные ошибки появляются реже. Большинство людей даже и не заметят ошибки, но если поставить сайт на мониторинг, то их сложно не заметить.
Некоторые люди замечают, что при проксировании сайты начинают медленнее работать. Пруфов нет, но такие отзывы есть.
Некорректная работа защиты на сервере
(если у Вас обычный shared-хостинг, то можете пропустить этот пункт)
При проксировании через Cloudflare на сервер приходят запросы не от реальных IP клиентов, а от IP подсетей Cloudflare. Реальный IP клиента можно узнать через тот же PHP (заголовок X-Forwarded-For), но серверный софт видит только конечный IP. В итоге серверная защита будет работать не очень корректно. А еще больше усложняется, если на сервере несколько сайтов и часть из них не проксируется.
Возьмем за пример Fail2ban. Чаще всего неверные авторизации на сайтах фиксируют в error логи и натравливают Fail2ban на эти логи. Как правило, туда попадают конечные IP адреса, т.е. IP адреса Cloudflare. При брутфорсах проксируемых сайтов он будет блокировать не реальные IP адреса, а IP адреса Cloudflare. Если начнется массивный брутфорс, то он заблочит часть адресов Cloudflare, с которых будут приходить и реальные клиенты. А если продолжительность бана будет большой, то это выльется в массовые 521 ошибки при высокой посещаемости. Ну а если сделать отдельный лог, куда кидать реальные IP адреса? В этом случае Fail2ban будет блочить реальные IP, но трафик то идет с IP адресов Cloudflare, и файрвол будет продолжать пускать злодеев на сервер. Тут ломатели могут хоть заломаться, а Fail2ban будет работать в пустую.
Для того, чтобы Fail2ban блочил реальные IP взломщиков, а они в свою очередь не могли зайти на сервер, есть решение. В этом случае Fail2ban получает реальный IP и шлет его Cloudflare через их API. Cloudflare в свою очередь блочит этот IP уже на своей стороне. Разблокировка IP происходит так же. Fail2ban получает команду на разблокировку или видит, что кончается срок блокировки, и шлет запрос Cloudflare на разблокировку этого IP. Вроде бы все супер, но в этом случае появляются посредники, появляются дополнительные задержки и защита переходит на сторону Cloudflare. Остается только надеяться, что он не упадет, внезапно не отключит проксирование, не сломаются запросы к API. Или, например, представьте, что нехорошие люди узнали реальный IP сервера (а узнать его можно разными путями), прописали его в hosts атакующей системы (или ботнета) и начинают долбить сайт. Fail2ban видит неудачные логины на сайт и начинает их слать Cloudflare для блокировки. Но они же обращаются к сайту уже не через Cloudflare, а на прямую. А тут они не заблочены. Как вариант, можно разрешить доступ по http и https только через IP адреса Cloudflare напрямую в iptables или передавать их туда через IPset. При этом список подсетей нужно поддерживать в актуальном состоянии и молиться, чтобы проксирование не отвалилось. Либо поддерживать оба варианта: классическая блокировка на сервере с занесением подсетей Cloudflare в белый список и отправка реальных IP в Cloudflare. Но нужно ли Вам такое усложнение? Причем в этом случае возможны еще разные ньюансы. Самым простым вариантом остается блокировка IP адресов Cloudflare на короткий промежуток времени.
Еще один пример — массовая блокировка айпишников по листам плохих IP, например, через IPset. Эти IP адреса просто не будут блокироваться, т.к. они будут скрываться под айпишниками Cloudflare. Как вариант, параллельно передавать их Cloudflare, но можно упереться в лимиты, что тоже не очень хорошо.
Защищенный трафик может прослушиваться на стороне Cloudflare
При использовании SSL и проксировании трафика через Cloudflare, он подключает свой сертификат. А это значит, что трафик сначала расшифровывается, а потом шифруется другим сертификатом. Это все происходит на стороне Cloudflare. При компрометировании их серверов важная часть трафика может быть перехвачена и изменена третьими лицами.
Когда проксирование через Cloudflare оправдано
Скрытие реального IP адреса сервера
Одна из важных для некоторых причин. Но не забывайте, что есть масса способов найти реальный IP сервера.
Еще часто бывает, что на shared-хостингах на одном IP висит по несколько десятков сайтов (а то и больше), часть из которых с не очень хорошей репутацией и частично портят репутацию сайта в глазах поисковиков и почтовых сервисов. При проксировании через Cloudflare подменяется IP сайта и экономит средства на приобретение выделенного IP.
В этом случае в основном одни плюсы, т.к. Cloudflare частично решает проблемы с защитой и паразитной нагрузкой. Лучше уж так, чем вообще никак.
Неоптимизированные говносайты
Если у Вас есть такой сайт, который никак не кешируется и без всякой оптимизации, то теоретически подключение проксирования исправит некоторые проблемы за счет кэширования некоторой статики, сжатия скриптов и стилей и прочего.
Использование платных тарифов
Здесь и так все ясно. За определенную плату у Вас уже будет хоть какая-то фильтрация трафика и всякие интересные плюшки. Любая коммерческая организация заинтересована в зарабатывании денег.
Необходимость CDN
Если у Вас обширная аудитория по всему миру, то толк конечно же будет. Но чаще всего сервер с сайтом близко расположен с основной узкой аудиторией, и надобность в CDN отпадает.
Заключение
Я Вас не отговариваю отказаться от проксирования через Cloudflare. Сам сервис хорош, много плюшек даже в бесплатном тарифе. Удобная настройка всего. Но в первую очередь нужно подумать, нужно ли Вам проксирование. Если Вы считаете что это модно или просто на автомате активируете, то скорее всего оно и не нужно.
