Эдуард Асадов "Распахну свое сердце настежь…" - (2)
Стихоробот, помощник поэта онлайн - (8)
Федоров Евгений - Национально-освободительное движение России. Русский код развития, Скачать книгу - DetectiveBook - (2)
Борис Валеджо (Вальехо) - Искусство фэнтази [1998, DjVu/PDF, 129 стр.] Скачать торрент бесплатно Книги с Seedoff.tv - (2)
Серия сообщений "1. Ошибки в сети":Выбрана рубрика 1. Ошибки в сети.
Часть 1 - Ошибка 522: Тайм - аут соединения...
Часть 2 - Защита сайта...
Ошибка 522: Тайм - аут соединения... |
Дневник |
Ошибка 522 указывает, что Cloudflare не может связаться с исходным веб-сервером, и время ожидания запроса истекло.
В качестве первого шага по устранению неполадок Ошибка 522:
Некоторые условия могут привести к появлению ошибки 522. Наиболее распространенные причины включают в себя:
Другие возможные причины могут также включать:
Ниже вы найдете дополнительную информацию по наиболее распространенным причинам.
Сервер может отбрасывать запросы в результате перегрузки. То, что представляет собой высокую нагрузку, может отличаться в зависимости от аппаратного и программного обеспечения сервера.
Как правило, средняя загрузка более 10-20 может означать, что сервер перегружен. Чтобы проверить это в Linux / Unix, вы можете запустить команды w или top в окне терминала.
Если вы не можете самостоятельно проверить загрузку веб-сервера, обратитесь к своему хосту или системному администратору.
Блокирование запросов Cloudflare является наиболее распространенной причиной периодических ошибок 522.
Когда трафик проходит через веб-сайт с поддержкой Cloudflare, исходный веб-сервер видит все запросы как поступающие с нескольких IP-адресов Cloudflare. Это часто может запускать брандмауэры и ограничители скорости IP для блокировки запросов Cloudflare, полагая, что веб-сайт находится под атакой. CPHulk (который поставляется с cPanel ) и другие сервисы, как известно, делают это.
Чтобы избежать этой ситуации, убедитесь, что:
Кроме того, ваш хост-провайдер может отключить ограничение скорости.
Нарушение сетевой маршрутизации между Cloudflare и исходным веб-сервером более сложно устранить, чем по другим причинам. Прежде чем проверять это, сначала исключите другие возможные причины.
Если вы считаете, что причиной могут быть проблемы с сетью, отправьте заявку в службу поддержки Cloudflare. Полезная информация, указанная в вашем билете, включает в себя:
Cloudflare использует заголовок Keep-Alive для повышения производительности. Отключение этого на исходном веб-сервере вызывает сбой соединения и возвращает ошибку 522 в некоторых случаях. Эта функция включена по умолчанию на большинстве основных веб-серверов, поэтому, если вы явно не отключили ее, это не должно быть проблемой.
Когда кто-то посещает веб-сайт с поддержкой Cloudflare, устанавливается соединение между Cloudflare и исходным сервером сайта. Для установления соединения TCP использует трехстороннее рукопожатие.
В этот момент и Cloudflare, и исходный сервер получили подтверждение соединения, и связь установлена. Если исходный сервер не отправляет SYN + ACK обратно в Cloudflare в течение 15 секунд, возникает ошибка 522 и соединение закрывается.
Эта диаграмма иллюстрирует успешное рукопожатие TCP:
На следующих диаграммах показано, что SYN + ACK не возвращается с исходного веб-сервера в течение 15 секунд, вызывая тайм-аут ошибки 522:
Другое условие для тайм-аута ошибки 522 возникает, когда источник отвечает SYN + ACK и устанавливает соединение TCP, но никогда не отвечает на запрос ACK в течение 90 секунд (условие 524 ACK подтверждает запрос, но слишком долго ожидает отправки ответ). Вот иллюстрация, детализирующая этот сценарий:
Проверка этих условий у администратора сервера или хостинг-провайдера - лучший способ устранить эти ошибки. Если есть проблема с сетью, трассировка маршрута или MTR от источника сайта также полезны.
Если вы по-прежнему видите ошибки 522 после исключения вышеупомянутых возможностей и устранения неполадки, обратитесь в службу поддержки Cloudflare для дальнейшего расследования.
https://support.cloudflare.com/hc/en-us/articles/200171906-Error-522
Метки: Ищем ошибки сети |
Защита сайта... |
Дневник |
Здравствуйте, уважаемые читатели блога KtoNaNovenkogo.ru. Кто не слышал про CloudFlare? Я слышал и даже подробно изучал возможности сервиса лет этак пять назад, наверное (когда задумывался об ускорении сайта). Вот только сейчас уже не скажу, что именно тогда меня остановило от того, чтобы этот сервис попробовать (не помню). Но это и не важно.
Важно же то, что в первый рабочий день после новогодних праздников мне таки пришлось подключить KtoNaNovenkogo.ru к CloudFlare и притом в авральном режиме (с выдиранием волос, литрами выпитого кофе и биением головой об стол). Сделать это пришлось из-за полной блокировки доступа к сайту (скорее всего путем Ддос атаки — по FTP доступ был возможен).
Из меня администратор сервера аховый и по большому счету я мало что понимаю в тонкостях и разновидностях DDos атак (ни как их организуют, ни как от них грамотно отбиваться — кроме простейшего блокирование по IP). Когда с этим не сталкиваешься, то оно тебе и не надо.
Но по всему выходит, что в первый рабочий день после новогодних праздников меня ддосили, и ничего ни я, ни техподдержка хостинга с этим поделать не смогли. Нанимать фрилансера для решения проблемы было стремно. Хорошо хоть по телефону ребята с Инфобокса мне подкинули идею подключить CloudFlare (как один из вариантов решения проблемы) и я за эту идею ухватился как за соломинку.
На успех особо не рассчитывал (за несколько часов, нужных для сброса старых и прописывания новых NC адресов успел много чего узнать по теме и даже составил уже примерный план действий). Но к моему удивлению буржуйский чудо-сервис помог! Притом даже на бесплатном тарифе. Замечательно сработал режим защиты от DDos атаки. Честно — не ожидал. Был приятно удивлен. Да еще и сайт стал летать как на крыльях (хотя и раньше черепахой не был).
В общем — так не бывает, но все же случается...
Что такое Ddos? Ну, во-первых, это аббревиатура от «distributed denial of service». По-русски это звучит как распределенная атака, цель которой добиться от атакуемого сервера (группы серверов) отказа в обслуживании для посетителей сайта (сайтов). Сайт будет выдавать ошибку всем желающим на него войти.
Слово «распредленная» означает, что Ддос атака идет сразу со множества компьютеров в сети. Очень часто для этой цели используется так называемый ботнет, т.е. группа зараженных вирусами или другим способом взятых под контроль компьютеров. Владельцы входящих в ботнет компьютеров могут при этом даже не догадывать о том, что они кого-то атакуют (все происходит в фоновом режиме).
Физически это означает огромное количество запросов, совершаемых к серверу с разных IP адресов. Если адрес будет один или несколько, то его легко можно вычислить по логам или открыв страницу http://xxx.xxx.xxx.xxx/server-status (где x нужно заменить на IP вашего сервера, если он работает под Апачем). После чего проблем не составит подозрительные IP временно заблокирвовать, например, через файл .htaccess дописав в него строки (Ip замените на свои — строк с Deny from можно добавлять сколько угодно):
Order allow,deny allow from all Deny from 83.149.19.177 Deny from 87.228.80.49 Deny from 178.212.72.13 |
Какое-то время мне это помогало. Но настоящий Ddos так ни за что не отбить — просто не успеете выявлять повторы IP адресов, если атаковать будут с десятков и/или сотен хостов. У меня так и случилось. В итоге 7 часов полного дауна!
Первые два часа я общался с техподдержкой хостинга на предмет «помогите» — «не могем». Потом за пять минут подключил к сайту CloudFlare, еще за пару минут сменил DNS записи у своего регистратора доменных имен и часа четыре ждал, пока начнется проключение (DNS записи должны обновиться на всех ключевых NS серверах в сети). Полноценно сайт заработал только через сутки, примерно.
Что такое DDos? Это страшная вещь на самом деле. Чувствуешь свое полное бессилие и безысходность. Со стороны атакующих — это способ заработать (на шантаже или выполняя заказ конкурента). Постоянная защита от этого зла очень дорогая, но CloudFlare даже на бесплатном тарифе позволяет отбиться от слабо-средней Ддос-атаки.
У этого сервиса есть миллионы подключенных сайтов (около пяти миллионов) и разработчики сервиса всегда четко отслеживают с каких IP сейчас обычно атакуют и таким посетителям, например, можно показать капчу (боты вряд ли настроены на ее разгадывание) или проверить браузер на «человечность» у таких подозрительных IP. Да и сами по себе их распределенные по миру сервера неплохо разреживают атаку на отказ — просто эти запросы распределяются на разные сервера и сильно снижают силу атаки сводя все усилия «редисок» на нет.
Для более серьезной защиты от Ддос в CloudFlare нужно уже платить и не мало (200$). Но это все для очень серьезного бизнеса, где Ддос мощнее (денег вливаемых в это больше), но и средств у владельцев много больше. Нам с вами «за глаза» хватит тарифа PRO за 20$ или вообще бесплатного тарифа, на котором почти все есть (читайте об этом ниже).
Что такое CloudFlare? Это онлайн сервис, ведущий свою историю с 2009 года (он ровесник моему блогу). Это ни в коем разе не хостинг, хотя со стороны может показаться именно так. Это скорее надстройка над хостингом (что-то вроде кеширующего обратного прокси). После подключения сайта к этому онлайн-сервису у него меняется IP адрес и возникает такое ощущение, что вы сменили хостера, но это не так.
Хостинг вам будет по-прежнему нужен и работать с сайтом вы будете фактически так же, как и работали раньше. Будут некоторые нюансики, но суть останется прежней. CloudFlare же нужен для защиты (стабильной работы) и ускорения работы сайта.
К нему подключены уже более пяти миллионов сайтов по всему миру. Этот онлайн сервис владеет распределенной сетью дата-центров (более 120) по всему миру (с прошлого года и в Москве такой появился). Последнее особо приятно, ибо обеспечивает гораздо более быстрый отклик при обращении к сайтам с территории России (хотя страна у нас большая и центров надо строить больше).
Итак, CloudFlare владеет кучей серверов распределенных по всему миру. Зачем? Чтобы добавленные в него сайты грузились в браузерах посетителей как можно быстрее. Вся графика, CSS и джава-скрипт коды будут отдаваться с того дата центра, который ближе находится к данному посетителю вашего сайта. Посетитель зашел из Москвы? Значит в работу включится московский дата-центр. Из США? Значит графика и прочая статика будет отдаваться посетителю с ближайшего к нему узла Cloud Flare.
Одно это уже способно повысить среднюю скорость загрузки странниц вашего сайта. Но данный сервис имеет в своем загашнике еще несколько тузов и джокеров. Работая с миллионами сайтов и отражая ежесекундно атаки сервис имеет базу адресов, с которых сейчас чаще всего атакуют сайты. Одно это может даже на бесплатном тарифе служить первым эшелоном защиты от DDoS-атак (и на это не требуется тратить особо ресурсы и время).
Кроме этого сервис позволяет включить режим «под атакой» (Under Attack Mode), когда каждое обращение к сайту прерывается на 5 секунд для выяснения типа браузера, с которого осуществлялся заход. Как раз этот режим спас меня в описанной выше безвыходной ситуации. Да, при этом отсекаются все боты и часть легитимных пользователей (на вскидку трафик стал процентов на двадцать меньше), но это лучше чем полный отказ сервера в доступе.
По окончании Ддос-атаки этот режим можно будет отключить и выбрать подходящий уровень бдения. При повторении атаки его легко можно будет включить даже с мобильника сидя в метро (главное настроить мониторинг доступности вашего сайта, чтобы вовремя среагировать).
В общем, даже на бесплатном тарифе практически все что нужно уже есть. Даже можно сжимать на лету файлы CSS и джава скрипта (удалив из них пробелы), чтобы на капелюшечку увеличить скорость загрузки. Не поверите — на бесплатном тарифе в CloudFlare можно будет даже SSL к сайту подключить (перейти на шифрованный протокол передачи данных — https, к чему нас последнее время активно склоняет Гугл). Причем сервис предоставляет свой собственный бесплатный сертификат.
Фантастика какая-то, не правда ли? Сами посмотрите сравнительную таблицу тарифных планов(включая Free). Чума! Если ваш хостинг упадет (будут проблемы), то Cloud Flare будет отдавать в этот промежуток времени страницы сайта из своего кеша (и это работает — проверял остановкой сервака, но есть нюансы о которых обязательно читайте ниже, иначе не сработает). Может чего упустил из бесплатных прелестей, но и этого более чем достаточно (за так то).
Кстати, у сервиса этого нет партнерки, но в рунете есть масса конкурентов с сумасшедшими ценниками (например, защита от DDoS-атак в qrator стоит ого-го-го сколько). Поэтому когда будете читать на форумах или блогах отзывы о CloudFlare, то обратите внимание на зачастую очень тонкую работу этих конкурентов (возможности CloudFlare занижаются, а своего сервиса или надстройки — абсолютируются). Многие ведутся, но сервис однозначно из разряда «такого не может быть, но все же есть».
Нет, недостатки у него тоже есть. Какие? Ну, зачастую очень даже значимые:
Чуть забегая вперед скажу, что я таки взял платный тариф ПРО и IP сменился (теперь у меня три соседа без особых видимых проблем — наверное тоже платники, не знаю). Проверить сайты на одном IP с вами можно на 2IP:
Как я уже сказал выше, купил PRO за 20$ в месяц (дороже хостинга получилось в полтора раза) и меня перевели (без моей просьбы — автоматом) на новый IP, где только три соседа и вполне себе легитимные.
Кроме этого на платном тарифе появилась возможность:
Например, если открыть мой блог с мобильника, то при быстрой прокрутке страницы увидите, что вместо картинок вставляются заглушки, которые заменяются на реальные изображения только при их попадании в экран просмотра.
Правда гугловский спидометр до включения Миража показывал (можно и другие сервисы измерения скорости сайта использовать):
А сейчас существенно ниже дает оценку — ругается, что часть контента на первом экране не подгружается вовремя. Кто его поймет?
Тариф я оплачиваю через Пейпел, что весьма удобно. При настройке платежей меня попросили привязать к счету в Пейпеле пластиковую карту, но деньги снимались не с карты, а непосредственно с самого кошелька (я в него вывожу доходы с мобильного приложения WhaffRewards). Прикольно, что каждый последующий месяц платеж происходит без моего участия — деньги автоматом списываются с Пайпаловского кошелька в день оплаты, что очень удобно.
Оно и не мудрено, ибо Пайпал позволяет в течении полутора месяцев опротестовать платеж, если что.
Ну, тут, кстати, все довольно просто, если мастер подключения сможет вытянуть все нужные настройки для переноса вашего сайта (его IP, Ms записи). Однако, обо всем по порядку.
Заходите на Cloud Flare и регистрируетесь (пароль храните как зеницу ока, ибо это ключ к вашему сайту).
Сразу оговорюсь, что бояться особо нечего, ибо при неудачном подключении вам не придется ждать сутки, пока ДНС записи опять перепишутся. Просто кликните по облачкам на странице настройки DNS и ваш сайт будет работать напрямую (мне пришлось так поступить с одним из второстепенных проектов, который почему-то с CloudFlare перестал открываться — см. скриншот ниже). Но по-любому: вся ответственность за ваши действия лежит только на вас и я тут буду, как бы, ни причем.
Сразу после регистрации можно переходить на страницу добавления нового сайта, где в предложенную строку нужно будет просто вставить его доменное имя и нажать на кнопку «Begin Scan»:
Далее будет проходить сканирование в течении нескольких минут, по окончании которого сервис выдаст те данные, что ему удалось нарыть про добавляемый сайт:
Тут, как видите, все ОК — сервис нашел все основные NS записи (включая почтовые), что есть хорошо. Автоматически для будущих данных, передаваемых с этого сайта, включилось кеширование (облачка окрасились). Идем дальше.
Как уже говорил выше, для защиты от Ddos подойдет даже бесплатный тарифный план(на нем при желании еще и бесплатный SSL сертификат получить можно). Отличия плана PRO от бесплатного я описал выше, поэтому выбирайте то, что вам нужно (мне все равно). Идем дальше.
Теперь основное. Нужно зайти в панель вашего регистратора доменных имен (где домен подбирали) и сменить там NS записи на те, что предложил на этом шаге мастера CloudFlare. Например, в Вебмани Домейнс это делается на такой вот страничке:
Нужно просто заменить записи в двух строчках на то, что вам Cloud Flare дал и подождать от 4 часов до 2 суток, пока все это дело пропишется на всех NS интернета. Идем далее, и по истечении нескольких часов после прописывания новых NS серверов можно будет нажать на кнопку «Recheck Nameservers»:
Обратите внимание, что внизу приведены настройки по умолчанию, которые будут применены к вашему сайту сразу после окончательного подключения к CloudFlare (средний уровень безопасности и стандартное кеширование, которое подразумевает попадание в кеш только статики — картинок, стилей и скриптов).
Если подключение ДНС уже прошло, то статус после нажатия на упомянутую кнопку сменится:
Кнопка «Quick Actions» позволяет быстро перейти в режим защиты от Ddos и прочих видов атак, который называется «Under Attack Mode». Мне при переходе на Cloud Flare пришлось сделать именно так. Данный режим «Под атакой» (Under Attack Mode) у меня был включен около 12 часов, пока атака не прекратилась.
На это время доступ к сайту ограничен и все соединения проверяются на предмет их легетивности. Всякие боты, в том числе и поисковых систем пробиться на сайт не смогут. В общем, работать в нем не стоит дольше того, чем необходимо (пока идет атака). Чуть подробнее о включении и выключении режима защиты от Ддос-атаки читайте в самом конце этой публикации.
Под автономной работой сайта я имею такую ситуацию, когда по каким-либо причинам ваш хостинг «ляжет», а сайт продолжит быть доступным посетителям. Это, как говорится, крайний случай. Но зачастую хостинг может просто-напросто не справляться с высокой нагрузкой (вызванной посещаемостью или использованием множества плагинов и плохой оптимизацией движка). В этом случае опять же поможет кеширование Html страниц в CloudFlare.
По умолчанию, как я понимаю, сервис кэширует только статику: картинки, CSS и JC. Все. В принципе, и это здорово может облегчить работу хостинга и ускорить загрузку страниц сайта в разных точках мира. Но зачастую этого бывает недостаточно. И даже не это главное. В этом режиме не срабатывает функция «Always Online» (Всегда онлайн), ибо Cloud Flare не умеет творить чудеса и отдает страницы из своего собственного кеша, а если их там нет, то отсылает к хостингу (который в данный момент может быть недоступен).
В общем, задача сводится к тому, чтобы включить кэширование всего содержимого веб-страниц (кода разметки, включающего текстовое наполнение), а не только статики. Сделать это можно на вкладке «Page Rules» из верхнего меню (см. пояснения в хелпе). Почему это не вынесли в общие настройки кэширования? Думаю, что из-за великого разнообразия сайтов и движков, на которых они работают. Видимо, не возможно обеспечить таким образом стабильность. Нужно действовать более точечно, опираясь на структуру и специфику каждого конкретного вебсайта. ИМХО.
На бесплатном тарифе можно создать только три правила для страниц, а на тарифе PRO — уже 20. Суть создания правила довольно проста. Пока опустим то, что нужно вставить в поле с регулярным выражением, а посмотрим что нам предлагают при нажатии на «+ Add a Setting» (добавить настройку):
Здесь как раз можно выбрать настройку степени кэширования (Cache levels), где в открывшемся списке допнастроек можно будет выбрать последний вариант «Cache everything» («Кэшировать все»). Таким образом, мы принудительно заставим CloudFlare кешировать всю вебстраницу, а не только статику.
Еще желательно будет задать время, которое страница будет храниться в кэше CloudFlare и в кэше браузеров посетителей сайта (это две разных настройки). Тут все зависит от степени динамичности вашего сайта в целом и отдельных его страниц в частности. Меня вполне устраивает интервал в несколько суток хранения кеша в облаке, а кеш браузера я выбираю разный (в зависимости от типа страниц).
Для задания этих настроек нужно будут еще пару раз нажать на кнопку «+ Add a Setting» и выбрать:
Метки: Ищем ошибки сети |
Страницы: | [1] |