DouleKit

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

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

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

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

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

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

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

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

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

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

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

В предыдущей части я уже рассказал о том, как пандемийные реалии привели меня на тернистый путь настройки безопасной удаленной работы для коллег по офису. Трудности подстерегли меня там, где их никто не ожидал – скорость подключения при использовании 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 дают скорости едва приемлемые для работы.

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

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

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

Дано: выделенка на 100мбит и MikroTik Hex S в офисе и 4G модем + Hex S в распоряжении отдельного сотрудника, в среднем. В таких условиях я принялся за рассмотрение возможных вариантов.

Прежде всего на ум пришел PPTP – разработка корпорации Microsoft, относящаяся к числу старейших протоколов. С одной стороны, что немаловажно, PPTP обеспечивает достаточно высокую скорость и поддерживается любой версией Windows, а с другой – этот протокол из-за недостаточной надежности и конфиденциальности уже не рекомендуется самим разработчиком, да и при разрыве соединения восстанавливается довольно медленно, что может добавить лишней нервозности и без того непростым рабочим моментам.

Гораздо лучше с безопасностью дела обстоят в случае L2TP/IPSec, пришедшего в 1999 году на замену майкрософтовскому PPTP и L2F от Cisco. Стандартизация, поддержка большинства операционных систем, шифрование, простота настройки общепризнаны в качестве сильных сторон протокола. Однако безопасность, обеспечиваемая двойной инкапсуляцией данных, не лучшим образом сказывается на скорости передачи. Вторым минусом стала систематическая брандмауэрная блокировка используемого протоколом по умолчанию UDP порта 500.

Нельзя было обойти вниманием и OpenVPN, недаром пользующийся огромной популярностью. Востребованность его возникла не на ровном месте – ее подкрепляют многочисленные пройденные независимые проверки, высокая стабильность и скорость, а также способность работы не только с операционкой от Microsoft, но и с «яблочными» iOS и Mac Os, с Android и даже с Linux. Однако ситуацию несколько осложняет необходимость использования специализированного клиентского ПО.

Наконец, в качестве запасного варианта я добавил к своему списку SSTP, который слывет достаточно надежным при совместимости с Windows, а также с операционными системами Router и Linux. При всей своей стабильности и безопасности SSTP этот протокол вызвал у меня существенные опасения ограничением сферы использования – далеко не каждый VPN провайдер берется его поддерживать.

Прикинув все «за» и «против», решил опробовать L2TP/IPSec. Дело стало за малым – настроить протокол на микротике. Для начала создал отдельную подсеть для подключения клиентов через L2TP. IP-адреса персонально не назначал, автоматизировав выдачу из диапазона свободных, присвоив пулу само за себя говорящее название.

Пулы для локалки и клиентов L2TP, соответственно:

Настроил профиль сервера, указав имя, начало диапазона адресов и название пула, а также поставив галочку в соответствующей ячейке:

Настроил вкладку протоколов:

Далее вкладка Limits:

Потом создал юзера:

В графе профиля указал имя сервера.

Включил сервер и выбрал следующие настройки:

Чтобы фаерволл пропускал входящие соединения, настроил соответствующее правило открыв порты 1701, 500, 4500:

И для IPSec тоже:

Создаю правило, позволяющее выйти в интернет при подключении к серверу L2TP:

Далее провел настройку подключения в Windows, чтобы соединение пошло сразу по нужному протоколу:

Для проверки подлинности вписал общий ключ, указанный при создании сервера:

Чтобы не нагружать роутер выбрал минимальные настройки шифрования в меню IP – IPSec:

Решил проверить результат, замерив скорость соединения, и тут меня ждал сюрприз! Если без VPN счетчик выдавал уверенные 30-40 Мбит/с, то через VPN скорость оказалась всего 100-200 кбит/с! Да как так то? Посмотрел нагрузку на процессоре - нулевая.

Нерадостный результат навел на мысли что МТС режет VPN соединения и это побудило меня испытать еще один вариант, настроить сервер на протоколе SSTP, но об этом в следующем посте.

Производительность процессора в значительной мере определяет быстродействие всей системы.

Поэтому споры между поклонниками AMD и Intel выходят далеко за рамки непосредственных характеристик комплектующих. Одним из полей сражений для подобного рода споров традиционно стали испытания в новых компьютерных играх.

Для испытаний системы были укомплектованы следующими компонентами:

• Материнская плата – MSI X570 Tomahawk для AMD и Z490 для Intel;

• Несколько вариантов накопителей

Corsair Force MP600 1Tb [PCIe 4.0],

WD Black SN750 1 Tb [PCIe 3.0],

Samsung 870 QVO 8Tb [SATA],

Western Digital WD120EMAZ 12 Tb;

• Процессоры - Ryzen 9 3900XT, Ryzen 5 3600, Ryzen 5 3400G и Intel Core i5-10600K Comet Lake.

Платформы AMD и Intel сконфигурированы с одним и тем же оборудованием, за исключением материнской платы и процессора. Это означает, что тот же графический процессор RTX 2080 Ti FE и тот же двухканальный комплект памяти DDR4-3200 с примененным XMP. Обе системы также используют загрузочные диски PCIe 3.0, хотя при разных свежих установках, как мы знаем, перенос установки AMD на систему Intel может повлиять на производительность.

Чтобы избежать предвзятости в нашем сравнении, мы тестируем эти четыре процессора с четырьмя твердотельными накопителями в семи тестах бенчмарк.

Бенчмарки:

Для синтетического теста, чтобы увидеть, влияет ли производительность процессора на что-либо в данных условиях, воспользуемся CrystalDiskMark.

Для последовательного чтения основное наблюдаемое отличие, заключается в том, что для диска PCIe 4.0 наличие платформы с поддержкой PCIe 4.0 обеспечивает более высокую производительность, как и следовало ожидать. Zen 2 также демонстрировал ускоренное последовательное чтение с низкой глубиной очереди даже на диске PCIe 3.0 по сравнению с Intel и Zen+, хотя разница составляет всего 12%.

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

При последовательной записи производительность одинакова для каждой платформы с небольшим преимуществом AMD, в то время как для случайной записи может быть довольно большой прирост производительности с AMD по сравнению с Intel с дисками PCIe. Однако, производительность в тестах бенчмарк не всегда напрямую коррелирует с реальной игровой производительностью.

Производительность в играх

Что же касается некоторых игр, картина выглядит следующим образом. На примере Horizon Zero Dawn можно наблюдать некоторое влияние используемого диска на время загрузки. Причем быстрые диски были на 30 процентов быстрее самых медленных. Но именно здесь заметно влияние скорости процессора на быстроту загрузки.

Ryzen 9 3900XT при использовании твердотельного накопителя PCIe был примерно на 11% быстрее, чем Ryzen 5 3600 и Core i5-10600K, которые показали аналогичные результаты. Однако показатели всех трех процессоров были похожи при загрузке с диска SATA. Как и ожидалось в такой ситуации, Ryzen не выигрывает от наличия PCIe 4.0.

Самое большое различие показывает Ryzen 5 3400G. Он заметно медленнее при загрузке уровня, по сравнению с другими процессорами, и это масштабировалось во всех четырех вариантах хранения.

Обращает на себя внимание 3-4 секундная задержка, которую дает Intel в сочетании с Western Digital WD120EMAZ 12 Tb – с другими накопителями различия были незаметны, но здесь проявились достаточно ярко.

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

The Outer Worlds - интересный пример сравнения времени загрузки AMD и Intel. Производительность Ryzen не сильно различалась, даже между Ryzen 5 3400G и Ryzen 9 3900XT, при этом Zen + APU был всего на пару секунд медленнее.

Однако загрузка этой игры на Core i5-10600K была значительно медленнее – она заняла в Intel в два раза больше времени по сравнению с AMD, при этом Intel не показала значительного увеличения производительности при загрузке с SSD по сравнению с жестким диском.

Это в очередной раз подтверждает, что процессоры Ryzen, как правило, имеют более быстрое взаимодействие ядер, чем Intel при декомпрессии, но это не полностью объясняет данное несоответствие. Замеры были произведены четырежды, и каждый раз обнаруживалось подобное отставание.

В Red Dead Redemption 2 неожиданно не наблюдается разницы во времени загрузки между любым из протестированных процессоров. По-прежнему существует разрыв в производительности между временем загрузки жесткого диска и SSD, но 3400G - который до сих пор был медленнее во всех других играх - работает в этой игре так же хорошо, как 10600K или 3900XT. В трех случаях из четырех Intel демонстрировал отставание от Ryzen 9 3900XT и Ryzen 5 3600

В Assassin’s Creed Odyssey наблюдается другая ситуация, когда на время загрузки больше влияет ЦП, чем устройство хранения, если вы не используете жесткий диск. В этом тесте Intel показывает пусть небольшое, но заметное отставание.

Заключение

Сравнение наглядно демонстрирует, что время загрузки игр напрямую зависит от скорости процессора, особенно при использовании твердотельных накопителей.

Несмотря на не слишком большую выборку игр в сравнении, очевидно, что именно прирост производительности ЦП может дать значительное ускорение загрузки.

Процессоры Ryzen в очередной раз показали себя с лучшей стороны, тогда как Intel продемонстрировал далеко неоднозначные результаты.