Лига Сисадминов

EC2 Auto Scaling. Между 02:15 и 07:10 API сервиса отдавала большое число ошибок. С 07:10 до 10:52 в EC2 наблюдались существенные задержки при выполнении нового подключения, либо отключении старого. Уже имевшиеся подключения продолжали работать корректно в течение всего инцидента.

Сервис хранит в DynamoDB информацию о группах и конфигурацих запуска. С момнета начала инцидента EC2 не мог обновлять внутреннюю таблицу данных при вызове его API. Когда DynamoDB было восстановлено, началось восстановление работы сервиса, которое не было закончено из-за накопившихся за время инцидента не обработанных активностей. Запуск и остановка сервиса осуществляется в фоновых процессах. В течение инцидента накопилось большое количество активностей, связанных с вышеупомянутым фоновым планировщиком. Эти процессы обрабатывались до 10:52.

Помимо мероприятий, сделанных командой DynamoDB, заключавшихся в обеспечении быстрого восстановления при образовании большого лога необработанных запросов, Amazon также изменил подход к разделению работ над серверами EC2 (чтобы большее их число можно было выполнять в параллельном режиме), внедрил механизмы удаления старых активностей и увеличил мощность серверов для обработки запоросов.

CloudWatch. Начиная с 02:35 сервис метрик Amazon - CloudWatch, - начал регистрировать задержки, отсутствие метрик EC2, а также возросшее число ошибок. CloudWatch использует внутреннее хранилище для добавления информации о членстве в группе автомасштабирования во все входящие запросы сервиса EC2. С 02:35 до 05:45 ошибки в DynamoDB обуславливали нестабильный доступу к метрикам EC2. CloudWatch также заметил ненормально низкую активность метрик других сервисов, использующих DynamoDB, усугбляя  проблему доступа к метрикам.

Далее примерно с 05:51 до 07:10 CloudWatch сообщил о значительно возросшем фоне ошибок вызовов API сервиса PutMetricData, что влияло на все метрики Amazon, а также метрики, созданные пользователями. Ошибки были связаны с доступом к данным о членстве, упомянутым выше. Сервисы CloudWatch восстановились к 07:29.

Для уменьшения влияния DynamoDB на CloudWatch Amazon уменьшил размер пакета до минимально возможного. Также в разработке сервисы быстрой доставки метрик за счет сквозной записи кэшей. Этот кэш должен предоставить возможность получать метрики без их ее сохранения. Кроме того он обеспечит большую защиту данных.

Console. AWS console также работала не стабильно у некоторых пользователей между 05:45 и 07:10. Пользователи, уже зашедшие в консоль оставались подключенными к ней. Те же, кто пытался войти в систему сталкивались с высокими задержками при входе. Это связано было с высокими задержками API, полагавшегося на DynamoDB. Для успешного входа вызов к этому API не обязательно должен пройти без ошибок, но из-за большог таймаута, этот запрос, блокировал процесс входа на десятки секунд.

Таймаут запроса уже был уменьшен и отправлен на тестирование. К сожалению, до начала инцидента новая версия консоли еще не была обновлена на релизе.

P.S. Сбой в системе хранения затронул большое число сервисов, однако, выше приведены основные - т.е. те, которые Amazon сам посчитал таковыми.

Впечатлившись рекламой и хвалебными отзывами руководство одной из контор, в которых мне довелось сисадминить, приняло решение о внедрении модного Kerio Control. Сказано – сделано: мечта об удаленном рабочем столе претворилась в жизнь, а трудовые будни окрасились в неожиданно привлекательные тона. Теперь начальство могло преспокойно работать из дома, попивая кофе в трусах.

Беда, как это обычно бывает, пришла, откуда не ждали. Поскольку о таком понятии как VPN ребята слыхом не слыхивали, а о его назначении – и подавно, то, недолго думая, открыли порт удаленного рабочего стола для доступа из любой точки недружелюбного внешнего мира. И, конечно же, при этом пароль администратора на сервере был «12345», его никто не удосужился поменять, да и вряд ли кто об этом задумывался.

Всего через пару недель счастливой и безоблачной работы из дома на сервере появилась зловещая картинка.

Работа конторы оказалась парализована, со стороны это всё выглядело следующим образом: все опрошенные старательно отрицают переход по небезопасным ссылкам нигерийских принцев, руководящий состав мечет громы и молнии, часть рядовых сотрудников радуется возможности похалявить, проектный отдел рвёт на себе волосы, логисты нервничают, кадровики хранят отстраненное молчание, и только снабженцы с трудом скрывают довольные ухмылки. Стало очевидно, что без привлечения квалифицированного специалиста дальнейшее функционирование не представляется возможным. Тогда-то меня и вызвали, чтобы поставить извечный русский вопрос: «Что делать и кто виноват?».

Послание от злоумышленников, как можно было легко догадаться, содержало требование выкупа в обмен на обещание расшифровки файлов. По тем временам, учитывая актуальный на тот момент курс биткоина, сумма запрошенного выкупа – 0,5 биткоина – выходила в сущие копейки и составляла всего-то 500 килорублей.

На кону была не только дальнейшая работа компании, клиентская база и многолетние наработки, но и пресловутая коммерческая тайна. Казалось бы – что такое полмиллиона для преуспевающей столичной конторы с приличным годовым оборотом?

Однако директор был категоричен и непреклонен, заявив, что не намерен вести никаких переговоров с вымогателями, а восстановление предполагается вести в ручном режиме. «Мне бы только файлик с «черной» бухгалтерией восстановить» - понизив голос, добавил директор и вкрадчиво присовокупил обещание «в долгу не остаться».

От успеха или неудачи в данной ситуации напрямую зависела моя репутация и дальнейшее сотрудничество с компанией, не скупящейся на оплату моих трудочасов. Вариантов у меня было немного. Здраво рассудив, что за спрос денег не берут, решил закинуть удочку злодеям. Написал, мол, деньги не проблема, однако, имеются сомнения в оправданности трат – хорошо бы продемонстрировать способность к расшифровке, вот, хотя бы на этом «совершенно рандомном» файле.

Вымогатели радостно заглотили мою наживку и прислали заветный файл в дешифрованном виде. Окончательное спасение ситуации пришло от главбуха – оказалось, что она со своей профессиональной паранойей регулярно делала резервное копирование. Миссия моя была близка к успешному завершению – всего-то за квартал документов пришлось восстанавливать.

А ведь всего этого можно было избежать, если бы VPN вовремя настроили, порты открывали с умом и использовали сложные пароли.

P.S. Прикладываю скрин переписки с злодеями, дабы развеять все сомнения в кото-ламповости истории. В нем видно, что файл они прислали.

Первоначальная причина отказа. В 2:19 ночи ( PDT - тихоокеанское летнее время, -10 часов от МСК) наблюдалось кратковременное падение сети, затронувшее несколько серверов DynamoDB. Обычно аналогичные падения сети обрабатываются не заметно и без изменения производительности DynamoDB, так как затронутые сервера хранения запрашивают службу управления метаданными сведения о своем членстве, применяют все необходимые обновления и сообщают, что они вновь могут обрабатывать запросы. Если сервера хранения не могут получить информацию назад в течение определенного периода времени, они отправляют повторный запрос о членстве и временно отписываются от обработки запросов.

Основная проблема. Но воскресным утром несколько ответов службы управления метаданными превысили предел времени получения и передачи данных. В следствие чего некоторые из серверов не смогли получить сведения о членстве и отписались от обработки запросов. Увеличение времени ответа было связано с недавней доработкой DynamoDB: в последние несколько месяцев пользователи часто применяли GSI (Globl Secondary Indexes). GSI позволяет обращаться к данным по альтернативным ключам (а не по первичным). Так как GSI является глобальным, он имеет свой собственный набор разделов на серверах хранения, тем самым увеличивая общий размер членских данных. Пользователи могут добавить несколько GSI для одной таблицы, поэтому таблица с большим числом разделов может быстро удвоить или утроить размер таких данных. За счет быстрого применения технологии пользователями для больших таблиц индекс "разделов-на-таблицы" значительно вырос. Из-за больших размеров членских данных время обработки некоторых запросов начало приближаться к пороговым значениям. Amazon не вел мониторинга размера данных о членстве и не имел достаточных мощностей для обработки таких тяжеловесных запросов.

Таким образом, когда в воскресенье после проблем с сетью несколько серверов одновременно запросили свои членские данные, служба управления метаданными обрабатывала тяжелые запросы. Несколько одновременных запросов для таких больших объемов данных привело к еще большему увеличению времени обработки, что привело к отказу  серверов хранения от обработки входящих запросов. Из за высокой нагрузки на службу управления метаданными, она также перестала отвечать на запросы серверов, не вовлеченных в изначальную проблему деградации сети, которые запросили обновление своих членских данных. Многие из этих серверов хранения также стали недоступны. Недоступные серверы продолжали отправку запросов на обновление сведений, сохраняя тем самым высокую нагрузку на службу управления метаданными. Не смотря на то, что многие запросы обрабатывались корректно, работающие сервера, получившие успешный ответ от службы один раз, получали ошибочный ответ в следующий, становясь вновь недоступными. К 2:37 ночи количество ошибок достигло максимума за последние три года, остановившись примерно на 55%.

Предпринятые шаги. Из-за высокой нагрузки Amazon не мог добавить ресурсов к службе. После нескольких неудачных попыток увеличить мощности в 5:06 утра было решено остановить запросы к службе. Это действие уменьшило активность повторных запросов, составлявших существенную часть нагрузки на службу. После того, как служба смогла отвечать на запросы администраторов, Amazon смог значительно увеличить вычислительные ресурсы и возобновить запросы серверов хранения к службе. В 7:10 утра работа DynamoDB была восстановлена.

Количество ошибок значительно  снизилось и составляло теперь 0.15%-0.25%, что считалось приемлемым показателем, хотя и более высоким, чем обычно. В понедельник Amazon начал получать сообщения от пользователей о проблемах с таблицами, застрявшими в режиме обновления или удаления. Проблема заключалась в том, что не смотря на низкий уровень ошибок, отказы был и распределены не равномерно между пользователями и у некоторых из них отказы случались существенно чаще, чем у других. Оказалось, что проблема была вызвана тем, что некоторые из разделов все еще не обрабатывали требуемое количество трафика. Команда администраторов работала осторожно и старательно чтобы восстановить собственные разделы службы управления метаданными и закрыла эту проблему в понедельник.

В результате проблемы Amazon значительно увеличил вычислительные мощности службы управления метаданными, реализовал более строгий мониторинг производительности служб, уменьшил частоту и увеличил предельное время получения членских данных. Кроме того служба управления метаданными разделяется на сегменты для того, чтобы каждый экземпляр службы обслуживал только свою часть серверов хранения.

В предыдущей части я уже рассказал о том, как пандемийные реалии привели меня на тернистый путь настройки безопасной удаленной работы для коллег по офису. Трудности подстерегли меня там, где их никто не ожидал – скорость подключения при использовании VPN упала до неприличия.

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

Сначала создал пул клиентских адресов:

Затем – профиль сервера SSTP:

Создал профиль пользователя:

Далее начинается веселье с настройкой сертификатов.

Настраиваем сервер сертификации:

Тут я указал название центра сертификации (из головы), два символа кода страны, следующие поля заполнил произвольно, важно указать внешний IP адрес сервера в Common Name, размер ключа в битах и срок действия (например, 10 лет)

Дальше настроил выдачу приватных и публичных ключей:

И самоподписал сертификат:

Подобным образом создал сертификат сервера SSTP. Указал выбранный ранее сертификационный центр, и подписал сертификат сервера ключом центра сертификации.

Далее можно включать сервер SSTP:

В настройках SSTP сервера рекомендуется оставлять только mschap2 протокол аутентификации, так же рекомендуется указать версию TLS 1.2. но я решил пока оставить по умолчанию.

Галочку PFS я трогать не стал, так как не понимаю ее глубокий смысл.

Настроив сервер, проверил фаерволл открытие порта 443.

Чтобы настроить клиент экспортировал сертификат, зайдя в пункт меню System:

Файл сертификата, взятый из раздела Files, установил на клиентский компьютер в Trusted Root Certification Authorities и создал VPN подключение:

Окончив настройку, решил замерить скорость, 6-12 Мбит/с, с одной стороны это победа, протокол не режется оператором так явно как L2TP, но за счет того что SSTP работает на TCP и внутри него трафик чаще всего так же TCP происходит жуткое снижение производительности сети.

С такой скоростью оперативного решения рабочих задач ожидать не приходится. Хотя удаленный рабочий стол работает не плохо, а вот файловая шара выдает грустные 300кб\сек.

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

В итоге SSTP на протоколе TCP + 4G дают скорости едва приемлемые для работы.

Подключаем роутер к питанию, в первый порт подключаем кабель от провайдера, в любой другой - кабель к компьютеру. Либо по Wi-Fi подключаемся к сети "MikroTik-******" (вместо звездочек могут быть любые буквоцифры). Сеть открытая, пароль не требуется

Запускаем Winbox, и если всё сделали правильно, в окне Neighbors увидим наш роутер:

У меня роутер не один, поэтому на вторую строчку внимания не обращаем. Тыкаем мышкой в первый столбик с MAC-адресом. По умолчанию, Login - admin, Password - пустой. Жмём Connect, и видим следующее окошко:

Мы, в данном случае рассматриваем самую простую и самую базовую настройку, поэтому жмём Ok.

Теперь открываем папку, куда мы распаковали файлы прошивки, и обычным перетаскиванием закидываем в окно винбокса файлы, имя которых начинается с system, wireless, и dhcp.

Можно в окне винбокса нажать меню Files, и проверить, что все файлы удачно загрузились:

Если что-то не так, докидываем недостающие файлы.

Затем в Winbox переходим в раздел System - RouterBoard, там жмём кнопку Settings, и ставим галочку Auto Upgrade, для автоматического обновления не только основной прошивки, но и загрузчика. Нажимаем OK

Теперь идём в раздел System и жмём кнопку Reboot. Ждём, пока роутер перезагрузится, и снова подключаемся к нему. Если вы закрыли окно System - RouterBoard, открываем его снова. Если не закрывали, оно откроется само. Вот что мы должны там увидеть:

Для обновления загрузчика, ещё раз идём в раздел System и жмём кнопку Reboot.

Теперь, настроим Wi-Fi

Заходим в меню Wireless, вкладка Security profiles, дважды щёлкаем по строчке default, и открываем окошко текущего профиля безопасности Wi-Fi.

Выбираем Mode - dynamic keys, Authentication Types - WPA PSK, и в строке WPA Pre-Shared Key вводим желаемый пароль Wi-Fi. Жмём OK.

На этом минимальный конфиг роутера готов. Его уже можно использовать в 90% пользовательских задач. Да, можно настроить ещё кучу параметром - изменить выдаваемые по DHCP адреса, так как по умолчанию раздаются адреса из сети по умолчанию, 192.168.88.0. Возможно, у вас другой тип подключения к интернету, и тогда настройки совсем другие. И многое-многое другое

Если будет интересно, могу рассказать о любых других этапах настройки. Микротик - очень гибкие железки, и на них можно настроить практически что угодно

P.S. Возможно придётся позвонить провайдеру, и сообщить, что у вас новый роутер, чтобы он зарегистрировал mac-адрес вашего роутера, и дал вам доступ в интернет. Если вы знаете mac-адрес предыдущего устройства, которое выходило в интернет, можно склонировать его. Но об этом в другой раз

P.P.S. Чуть не забыл самое главное. Меняем пользователя под умолчанию, во славу безопасности.

Заходим в раздел System - Users, нажимаем кнопку с большим знаком плюс. В открывшиеся окне, в поле Name вводим имя нового пользователя, в строке Group выбираем full, в полях Password и Confirm password, два раза вводим новый пароль. Жмём ОК.

Теперь проверяем, что новый пользователь заведён правильно. Закрываем окно винбокса, и открываем новое, либо просто не выходя жмём New winbox. Снова пытаемся зайти на роутер, но уже введя новые логин и пароль. В случае успеха, снова заходим в system - users, и удаляем пользователя admin