VDSina Хостинг

На связи Александр Чистяков, я евангелист vdsina.ru и расскажу про 9 лучших технологических событий 2019 года.

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

Я не сортировал события в списке по значимости или вау-эффекту, потому что их значимость будет понятна лет через десять, а вау-эффект слишком краткосрочен, просто постарался сделать эту историю связной.

1. Переносимые серверные приложения на языке программирования Rust под WebAssembly
Я начну обзор с двух докладов:
1. Доклад Брайана Кантрилла “Время переписать ОС на Rust?”, прочитанный им ещё в 2018-м.
На момент прочтения доклада, Брайан Кантрилл работал в компании Joyent на позиции CTO и еще не догадывался, чем закончится для него и Joyent 2019-й.

2. Доклад Стива Клабника, члена core team языка Rust и автора книги “The Rust Programming Language”, работающего в Cloudflare, где он рассказывает об особенностях языка Rust и технологии WebAssembly, позволяющей использовать веб-браузеры как платформы для запуска приложений.

В 2019-ом WebAssembly со своим интерфейсом WASI, предоставляющим доступ к объектам операционной системы, такими, как файлы и сокеты, шагнула за рамки браузеров и нацеливается на рынок серверного программного обеспечения.

Суть прорыва очевидна — у человечества появляется еще один рантайм, способный запускать переносимые приложения для Web (кто-нибудь помнит принцип WORA, придуманный еще авторами языка Java?).

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

WebAssembly настолько переворачивает игру, что Соломон Хайкс, один из создателей Docker, писал о том, что, если бы WebAssembly и WASI существовали в 2008-м, Docker бы просто не родился.


Неудивительно, что именно Rust оказался в рядах освоителей новой переносимой технологии — его экосистема динамично развивается и Rust уже несколько лет остается самым любимым языком программирования согласно результатам опроса, проводимого StackOverflow.

Это слайд из доклада Стива, который наглядно показывает соотношение числа ошибок безопасности, которых целиком можно избежать при использовании Rust к общему числу ошибок в MS Windows, найденных за последние полтора десятилетия.


Компания Microsoft должна была как-то ответить на такой вызов, и она ответила.

2. Project Verona от Microsoft, который спасет Windows и откроет новую страницу истории для любой ОС

Количество ошибок в ядре Microsoft Windows и большинстве пользовательских программ почти линейно увеличивалось в течение последних 12 лет.


В 2019 Мэтью Паркинсон из Microsoft представил публике Project Verona, который может положить этому конец.

Это инициатива Microsoft по созданию безопасного языка программирования, основанного на идеях языка Rust: коллеги из Microsoft Research выяснили, что большинство проблем с безопасностью связано с тяжелым наследием языка C, на котором написана большая часть Windows. Rust-подобный язык Verona управляет памятью и конкурентным доступом к ресурсам, используя принцип абстракций с нулевой стоимостью. Если вы хотите подробно разобраться, как он работает, просмотрите доклад самого Паркинсона.

Интересно, что компанию Microsoft традиционно воспринимают как империю зла и противника всего нового, несмотря на то, что Саймон Пейтон-Джонс, основной разработчик Glasgow Haskell Compiler, работает именно в Microsoft.


Вопрос Брайана Кантрилла из первого пункта: “не пора ли переписать ядро операционной системы на Rust?” получил неожиданный ответ — очевидно, что ядро операционной системы переписать пока невозможно, но программы, работающие в userspace, уже переписываются. Начался неостановимый процесс, и это откроет новую страницу будущего для всех операционных систем.

3. Взлет популярности языка программирования Dart благодаря фреймворку Flutter
Я уверен, что следующая новость является большим сюрпризом не только для нас и широкой публики, но и для большинства непосредственных участников процесса её формирования. Язык программирования Dart, появившийся в Google восемь лет назад, в этом году показал стремительный рост популярности.

Я использую свой метод оценки популярности языков программирования при помощи анализа репозиториев на Github, раз в месяц обновляя данные в таблице. Если в начале года популярных репозиториев на Dart было всего 100, то сегодня их уже 313.

Dart обогнал по популярности Erlang, PowerShell, R, Perl, Elixir, Haskell, Lua и CoffeeScript. Быстрее, кажется, в этом году не рос ни один другой язык программирования. Почему так произошло?

Один из знаковых докладов этого года по версии аудитории HackerNews был прочитан Ричардом Фельдманом и назывался “Почему функциональное программирование не является нормой?” Значительная часть доклада посвящена анализу того, каким образом языки программирования становятся популярными. Одна из основных причин, по версии Ричарда — наличие популярного приложения или фреймворка, иначе говоря the killer app.

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


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

4. Шанс на выживание ядра Linux и его коммьюнити благодаря вирутальной машине eBPF

Мы в VDSina любим конференции: в этом году я ездил на конференции DevOops в Санкт-Петербурге и участвовал в круглом столе, посвященном трендам и горячим штучкам в индустрии. В 2019-м в таких разговорах лидировали мнения:

• Docker мертв, потому что слишком скучен
• Kubernetes жив и протянет где-то год — о нём ещё будут говорить на конференциях в 2020 году
• тем временем, в ядро Linux никто из живых людей не заглядывает уже давно

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




Благодаря eBPF, ядро теперь сообщает о наступлении событий, которые можно частично обрабатывать вне ядра — интерфейс дает возможность безопасно и эффективно взаимодействовать с ядром из userspace и расширять и дополнять функциональность ядра Linux, минуя всевидящее око Линуса Торвальдса.

До eBPF разработка программ, деятельность которых тесно связана с взаимодействием с ядром Linux была непростой историей — для создания вещей вроде драйверов не очень быстрых устройств и интерфейсов для файловых систем в userspace требовалось проходить формальную процедуру review опытными разработчиками ядра Linux.

Появление интерфейса eBPF сильно упростило процесс написания таких программ — входной порог понизился, разработчиков станет больше и коммьюнити снова оживёт.

Я не одинок в своем энтузиазме: разработчик ядра с многолетним стажем Дэвид Миллер декларирует важность eBPF для выживания (!) экосистемы разработки ядра. Другой, не менее известный разработчик Брендан Грегг (я его большой фанат) называет eBPF прорывом, равного которому не было 50 лет.

Тем временем Линус Торвальдс за подобное обычно публично не хвалит и я могу его понять — кому хочется публично выставлять себя идиотом? :)


5. Linux забил почти последний гвоздь в гроб FreeBSD благодаря асинхронному интерфейсу io_uring в ядре Linux

Раз уж речь зашла о ядре Linux, необходимо отметить и другое значительное улучшение, происшедшее в этом году: включение в ядро нового высокопроизводительного асинхронного API ввода/вывода io_uring за авторством Дженса Эксбоу из Facebook.

Много лет системные администраторы и разработчики под FreeBSD обосновывали свой выбор фактом, что во FreeBSD асинхронный ввод-вывод был сделан лучше, чем в Linux. Например, этот аргумент использовал в своем докладе в 2014-ом году Глеб Смирнов из Nginx.

Теперь игра перевернулась. На использование io_uring уже перешла распределённая файловая система Ceph и результаты тестов производительности впечатляют — рост количества операций ввода/вывода в секунду составляет от 14% до 102% в зависимости от размера блока. Существует прототип, использующий асинхронный ввод-вывод в PostgreSQL (по крайней мере, для background writer), запланированы дальнейшие работы по переводу PostgreSQL на асинхронный ввод-вывод. Но учитывая консервативность сообщества разработчиков, в 2020-м эти изменения мы еще не увидим.


6. Триумфальное возвращение компании AMD с линейкой процессоров Ryzen
Ничего необычного, просто компания AMD, долгое время бывшая в индустрии на вторых ролях, бьёт рекорд за рекордом.

Новая линейка процессоров Ryzen показала невероятное соотношение цена/производительность: они доминируют в списке самых продаваемых процессоров на Amazon, а в некоторых регионах продажи процессоров AMD превысили продажи Intel. В конкурентной борьбе Intel вынуждена идти на крайне непопулярные меры: заставляет программы, созданные при помощи их собственного компилятора, работать менее эффективно на процессорах конкурента. Несмотря на грязные способы борьбы Intel, рыночная оценка AMD вплотную приблизилась к рекордным значениям 2000-го года.

7. Вслед за AMD, Apple целится откусить кусок пирога Intel с помощью iPadOS и старых уловок Гейтса

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

Выпустив новый iPadOS, Apple использовала против Intel тактику, которая называется “disruptive innovation” — подрывные инновации.

Определение Википедии

«Подрывные инновации» (англ. Disruptive innovation) — инновации, которые изменяют соотношение ценностей на рынке. При этом старые продукты становятся неконкурентоспособными просто потому, что параметры, на основе которых раньше проходила конкуренция, теряют свое значение.

Примерами «подрывных инноваций» являются телефон (заменил телеграф), пароходы (заменили парусные суда), полупроводники (заменили электровакуумные приборы), цифровые камеры (заменили пленочные), электронная почта («подорвала» традиционную почту).

Apple использует свои собственные процессоры на базе ARM с низким энергопотреблением и это оказалось для пользователей более важным, чем немного отстающая от Intel x86 производительность.

Apple успевает урвать часть рынка, превращая iPad из терминала для развлечений в полноценный рабочий инструмент — сначала для тех, кто создает контент, а теперь и для разработчиков. Конечно, в ближайшее время мы не увидим MacBook на базе ARM, но маленькие неприятности с дизайном клавиатур MacBook Pro способствуют поиску альтернативных решений и одним из них обещает стать iPad Pro с iPadOS.

Причем тут Гейтс и Microsoft?

В свое время Гейтс провернул точно такой же трюк с IBM.

В 1970-х IBM доминировал на рынке серверов, с уверенностью гиганта не обращая внимания на персональные компьютеры для обывателей. В 1980-х Гейтс создает на деньги IBM и лицензирует для него MS-DOS, оставляя права на операционную систему на себя. Получив деньги, Microsoft создает под MS-DOS графический интерфейс, и рождается Windows — сначала просто графическая надстройка над DOS, а потом и первая операционная система под PC, удобная для использования широкими массами. IBM, будучи большой неповоротливой компанией проигрывает рынок персональных компьютеров молодой и быстрой Microsoft. Я очень кратко пересказал эту замечательную историю, поэтому если вам интересно, как в 2020-ом Apple будет играть против Intel с помощью iPadOS, очень рекомендую прочитать её целиком.

8. Укрепление позиций ZFSonLinux — старый конь борозды не портит
Компания Canonical представила возможность установки Ubuntu с использованием файловой системы ZFS в качестве root file system прямо из инсталлятора. Иногда мне кажется, что инженеры, работавшие в Sun Microsystems, представляют собой отдельный биологический вид человека разумного (уже упоминавшиеся выше Брайан Кантрилл и Брендан Грегг работали в Sun). Посудите сами, несмотря на многолетние попытки всего человечества сделать что-то, хотя бы, отдаленно похожее на файловую систему ZFS, несмотря на неразрешимые лицензионные ограничения, препятствующие включению исходного кода ZFS в основную ветку разработки ядра Linux, мы все еще используем ZFS, и в ближайшее время ситуация не изменится.

9. Oxide Computer Company — мы будем пристально следить за командой, которая явно способна на многое — как минимум, создать крутое шоу
Я завершаю свой список новым упоминанием Брайана Кантрилла, с которого я и начал.

Брайан Кантрилл с другими инженерами (некоторые из которых тоже раньше работали в Sun) основал предприятие под названием Oxide Computer Company, основная цель которого — создание серверной платформы, пригодной для использования в больших масштабах. Известно, что очень большие корпорации, такие как Google, Facebook и Amazon, не используют в своей деятельности обычное серверное железо. Компания Брайана призвана устранить это неравенство, разработав программно-аппаратную платформу, пригодную для использования любым облачным сервисом (не обойдется и без языка программирования Rust).

Их задумка — обещание новой революции, и я буду, как минимум, с удовольствием наблюдать за движением их мысли и их разработкой в грядущем 2020 году.

Что мы успели сделать в 2019 в VDSina
Технологических прорывов в 2019 с VDSina мы не делали, но нам все равно есть, чем гордиться.

В феврале мы добавили возможность использовать локальную сеть между серверами и запустили услугу регистрации доменов. Цену сделали одной из самых низких на рынке — 179 руб за ru/рф, в том числе и за продление.

В марте выступили на IT Global Meetup #14.

В апреле увеличили ширину канала для каждого сервера с 100 до 200 Мегабит, значительно увеличили лимит трафика для всех тарифов (кроме самого дешёвого) — до 32 ТБ в месяц.

В июле у клиентов появилась возможность автоматически устанавливать Windows Server 2019. В пределах московской локации начали предоставлять бесплатную защиту от DDoS.
Также в июле наша компания появилась на Хабре, дебютировав статьей, как мы написали собственную панель управления хостингом и как это помогло нам сделать качественный скачок в поддержке клиентов.

В августе добавили возможность создавать снимки — резервные копии серверов.
Выкатили публичный API.
Увеличили ширину канала для каждого сервера с 200 до 500 Мегабит.
Участвовали в конференции Chaos Constructions 2019, раздав в качестве мерча плётки с логотипом компании (слоган кампании был “Когда разработчик сверху”) и взорвали телеграм-чаты.

В сентябре мы запустили самый милый и дружелюбный инстаграм IT-компании — о новостях и буднях VDSina начал рассказывать пёсик-разработчик.
www.instagram.com/developer.dog/


В ноябре мы съездили на Highload++, поучаствовали в круглом столе “базы данных в Kubernetes” и одели участников в шапки-акулы.

В декабре выступили на DevOps-митапе в офисе ГазПромНефти с докладом про базы данных в Kubernetes и на конференции DevOpsDays в Москве с докладом про выгорание, который, определенно, стал моим лучшим выступлением за год.
www.youtube.com/watch?v=JqShWWtCL04

Заключение
Как говорил Нассим Талеб, гораздо проще предсказать то, чего мы точно не увидим. Хочу отметить, что всё то новое, что мы увидим в 2020-м берет начало еще в 2019-м, 2018-м и раньше. Я не берусь предсказывать будущее точно, но 2020-й точно не станет годом Linux на десктопе (когда вы в последний раз видели десктоп?) а год Linux на мобильных устройствах мы наблюдаем уже лет десять.

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

https://vdsina.ru

TL;DR Атакующий подменяет source ip на адрес вашего сервера и триггерит автоматические абузы. В результате клиента банят на хостинге за вредоносную активность, которой не было.

Эта статья написана нашим клиентом, который перешёл к нам от крупного хостера после DDoS-атаки и любезно согласился поделиться этой историей.

Расскажу про удивительно коварный способ DDoS-атак, с которым я раньше не сталкивался. Коварство заключается в том, что на сам сервер жертвы не выполняется никакой атаки. Вместо этого, злоумышленник провоцирует срабатывание сторонних систем обнаружения атак, заставляя генерировать совершенно настоящие жалобы (в простонародье «абузы») на ваш сервер.

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

В статье подробно разбирается этот вид атаки в реальном кейсе.

Хронология событий
Я держал несколько личных проектов на VPS-серверах у одного известного хостера. Однажды мне пришло от него такое письмо:

#9042382: ToS Violation — Malicious Activity
Hello,
We have received a report of malicious activity originating from your server XXXX. We ask that you investigate this matter as soon as you are able. Once you have completed your investigation, kindly reply to this ticket with the answers to the following questions:

Reported-From: abuse-out@checkdomain.de
Category: info
Report-Type: info
Service: different services
Version: 0.1
User-Agent: Checkdomain Express 0.19
Date: Fri, 26 May 2018 19:25:19 +0200
Source-Type: ipv4
Source: my-server-ip-xx-xxx
Port: dif.
Report-ID: dih3cefnp@checkdomain.de
Schema-URL: http://www.blocklist.de/downloads/schema/info_0.1.1.json
Attachment: text/plain

DETAILS ZU DEN ATTACKEN/STÖRUNGEN | DETAILS OF THE ATTACKS
(letzten 60 Tage / max. 100 St.) | (last 60 days / max. 100 hits)
 portflood: syn | | standby.checkdomain.de |
VORHERIGE SPERREN DER IP-NUMMER | BANNED HISTORY OF THIS IP-NUMBER
my-server-ip-xxx-xxx-xxx: this ip-number was never banned before

AUZUG AUS SERVERLOGDATEI | EXCERPT FROM SERVER LOGFILE
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:41667 SYNRECV - 
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:46208 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:13000 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:39104 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:55348 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:37266 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:60684 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:63878 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:50445 SYNRECV -
tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:56215 SYNRECV -

Где my-server-ip-xx-xxx это IP-адрес сервера.

В нем хостер пересылает мне жалобу, поступившую на его ящик abuse@, и настойчиво просит прекратить вредоносную активность, иначе я буду заблокирован. В приложенном логе виден список TCP-подключений к 80 (HTTP) порту в состоянии SYN RECEIVED. То есть с моего сервера идёт SYN-флуд на чей-то веб-сервер.

Первая мысль — меня взломали и с моего сервера идёт SYN-флуд. В Linux есть ограничения на управление сокетами с правами обычного пользователя и посылать только SYN-пакеты (без установки полноценного TCP-соединения) можно только имея привилегии root. А это значит, что взломали полностью.

В панике бегу на сервер искать вредоносный процесс. Проверяю top, ss, lsof и ничего подозрительного не вижу. Первичный вывод: «ужас, наверное залили настолько крутой руткит, который прячет вирус на уровне ядра от всех системных утилит!». В процессе исследований выясняется, что нагрузка на сервер никак не изменилась, по графикам в панели хостера трафик на интерфейсе остается прежним.

До этого я запускал tcpdump c фильтрами, показывающими исходящий трафик и ничего подозрительного не видел. Отчаявшись, решаю посмотреть весь трафик на сервер. В потоке легитимного трафика нахожу редкие RST-пакеты от странных серверов.

Выглядит это примерно так, где my-server-ip-xx-xxx адрес моего сервера:

IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R]
IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R]
IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R]
IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R]
IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R]
IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R]

Было очевидно, что это аномалия, так как больше никакого обмена с этими серверами не было и почему они шлют пакет закрытия соединения, мне было неясно.
На этом моменте опытные админы сразу бы всё поняли, но мы разберём всё на пальцах

Как это работает
Входящие RST-пакеты это ответы на попытки установить TCP-соединение на закрытый порт. При этом от моего сервера никакого исходящего трафика в сторону серверов, посылающих RST, нет. Это значит, что атакующий подменяет исходящий адрес на мой и генерирует трафик, похожий на DDoS-атаку. Но так как единственное, что может атакующий, это послать исходящий пакет, все ответы от серверов приходят на мой сервер.

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

В моем случае атакующий не ставил целью исчерпать канал сервера-жертвы. Его активность была совершенно незаметна на графиках потребления канала. Главной его целью было спровоцировать системы автоматического уведомления о сетевых атаках, которые пошлют письмо с жалобой на abuse-адрес, указанный в whois подсети моего провайдера. Это умеют делать системы обнаружения и предотвращения вторжений (Intrusive Prevent/Detect System), такие как Snort и Suricata.

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

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

Проверяем возможность подмены IP-адреса
Советую вам проверить своего хостера на возможность подмены исходящего IP. Для этого потребуется два сервера, один для приёма трафика, другой для отправки.

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

tcpdump -i any port 9912

На проверяемом сервере сгенерируем пакет с подменой исходящего IP-адреса на 1.1.1.1, направленный на порт 9912. Для этого используем крутую утилиту nping от разработчиков nmap. Она позволяет генерировать любые нестандартные пакеты на уровне L2 и L3.

nping --tcp -p 9912 -S 1.1.1.1 receiver-server.com

receiver-server.com — адрес слушающего сервера, на котором запущен tcpdump
1.1.1.1 — подменяемый исходящий адрес
9912 — удалённый порт

Если на стороне receiver-server.com вы увидите пакет, пришедший от имени 1.1.1.1, значит ваш провайдер позволяет подменять исходящий IP-адрес. Это повод сообщить ему о проблемах в настройке сетевого оборудования. Зачастую такой проблемой страдают домашние интернет-провайдеры.

Глупая техподдержка
Разобравшись в причинах жалоб, я подробно все изложил хостеру:

Hello,
I finally understand what happened.

They spoof my IP address and DDoS random hosts using my address as source address. So victims generate automatic abuse reports to my hosting providers.

You can see on abuse log that connections are only in SYN_RECV state (no full TCP-connection established) because they can send only one packet using spoofed IP and can't finish TCP-handshake.
I can prove this. There are many TCP RST incoming packets coming right now to my server from hosts whom I never sent any packets.

You can check it right now by running:

tcpdump -i eth0 «tcp[tcpflags] & (tcp-rst) != 0»

You will see that many RST packets came from hosts to which I've never sent any data.
This proves that attacker is spoofing my IP-address to compromise me and generate abuses.

Тогда мне казалось, что любой квалифицированный инженер техподдержки разберётся в ситуации и вопрос будет закрыт. Но вместо этого они требовали от меня проверить сервер антивирусом или полностью переустановить ОС. Пока мы переписывались с техподдержкой, абузы продолжали поступать и через сутки меня забанили.

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

https://vdsina.ru

Можно ли объединить несколько интернет-каналов в один? Вокруг этой темы куча заблуждений и мифов, даже сетевые инженеры с опытом часто не знают о том, что это возможно. В большинстве случаев, объединением каналов ошибочно называют балансировку на уровне NAT или failover. Но настоящее суммирование позволяет пустить одно единственное TCP-подключение одновременно по всем интернет-каналам, например видеотрансляцию так, чтобы при обрыве любого из интернет-каналов вещание не прерывалось.

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

Мифы про суммирование каналов

Есть много бытовых роутеров, поддерживающих функцию Multi-WAN. Иногда производители называют это суммированием каналов, что не совсем верно. Многие сетевики верят, что кроме LACP и суммирования на L2 уровне, никакого другого объединения каналов не существует. Мне часто доводилось слышать, что это вообще невозможно от людей, которые работают в телекомах. Поэтому попробуем разобраться в популярных мифах.

Балансировка на уровне IP-подключений

Это самый доступный и популярный способ утилизировать несколько интернет-каналов одновременно. Для простоты представим, что у вас есть три интернет провайдера, каждый выдаёт вам реальный IP-адрес из своей сети. Все эти провайдеры подключены в роутер с поддержкой функции Multi-WAN. Это может быть OpenWRT с пакетом mwan3, mikrotik, ubiquiti или любой другой бытовой роутер, благо сейчас такая опция уже не редкость.

Для моделирования ситуации представим, что провайдеры выдали нам такие адреса:
WAN1 — 11.11.11.11
WAN2 — 22.22.22.22
WAN2 — 33.33.33.33

То есть, подключаясь к удалённому серверу example.com через каждого из провайдеров, удаленный сервер будет видеть три независимых source ip клиента. Балансировка позволяет разделить нагрузку по каналам и использовать их все три одновременно. Для простоты представим, что мы делим нагрузку между всеми каналами поровну. В итоге, когда клиент открывает сайт, на котором условно три картинки, он загружает каждую картинку через отдельного провайдера. На стороне сайта это выглядит как подключения с трёх разных IP.



Такой режим балансировки часто несёт проблемы для пользователей. Например, многие сайты жёстко привязывают cookie и токены к IP-адресу клиента, и если он внезапно изменился, то запрос отбрасывается или клиента разлогинивает на сайте. Это часто воспроизводится в системах клиент-банка и на других сайтах со строгими правилами пользовательских сессий. Вот простой наглядный пример: музыкальные файлы в VK.com доступны только при действительном ключе сессии, который привязан к IP, и у клиентов, использующих такую балансировку, часто не проигрываются аудио, потому что запрос ушёл не через того провайдера, к которому привязана сессия.


Такая балансировка позволяет получить суммирование скорости интернет-канала, при использовании множества подключений. Например, если у каждого из трёх провайдеров скорость 100 Мегабит, то при загрузке торрентов мы получим 300 Мегабит. Потому что торрент открывает множество подключений, которые распределяются между всеми провайдерами и в итоге утилизируют весь канал.

Важно понимать, что одно единственное TCP-подключение всегда пройдёт только через одного провайдера. То есть если мы скачиваем один большой файл по HTTP, то это подключение будет выполнено через одного из провайдеров, и если связь с этим провайдером оборвется, то загрузка тоже сломается.


Это справедливо и для видео-трансляций. Если вы вещаете потоковое видео на какой-то условный Twitch, то балансировка на уровне IP-подключений не даст никакой особенной пользы, так как видео-поток будет транслироваться внутри одного IP-подключения. В данном случае, если у провайдера WAN 3 начнутся проблемы со связью, например потери пакетов или снижение скорости, то вы не сможете моментально переключиться на другого провайдера. Трансляцию придётся останавливать и переподключаться заново.

Настоящее суммирование каналов
Реальное суммирование каналов даёт возможность пустить одно подключение к условному Twitch сразу через всех провайдеров таким образом, что, если любой из провайдеров сломается, подключение не оборвется. Это на удивление сложная задача, которая до сих пор не имеет оптимального решения. Многие даже не знают, что такое возможно!

По предыдущим иллюстрациям мы помним, что условный сервер Twitch может принять от нас видеопоток только от одного source IP адреса, значит он должен быть у нас всегда постоянным, вне зависимости от того, какие провайдеры у нас отвалились, а какие работают. Чтобы этого добиться, нам потребуется суммирующий сервер, который будет терминировать все наши подключения и объединять их в одно.


В такой схеме используются все провайдеры, и отключение любого из них не вызовет обрыв связи с сервером Twitch. По сути, это особый VPN-тоннель, под капотом у которого сразу несколько интернет-каналов. Главная задача такой схемы — получить максимально качественный канал связи. Если на одном из провайдеров начались проблемы, потеря пакетов, увеличение задержек, то это не должно никак отразиться на качестве связи, так как нагрузка автоматически будет распределяться по другим, более качественным каналам, которые есть в распоряжении.

Коммерческие решения
Эта проблема давно беспокоит тех, кто ведёт прямые трансляции мероприятий и не имеет доступа к качественному интернету. Для таких задач существуют несколько коммерческих решений, например компания Teradek делает такие монструозные роутеры, в которые вставляются пачки USB модемов:


В таких устройствах, обычно, встроена возможность захвата видеосигнала по HDMI или SDI. Вместе с роутером продаётся подписка на сервис суммирования каналов, а также обработки видеопотока, перекодирования его и ретрансляции дальше. Цена таких устройств начинается от 2к$ с комплектом модемов, плюс отдельно подписка на сервис.

Иногда это выглядит достаточно устрашающе:


Настраиваем OpenMPTCPRouter
Протокол MP-TCP (MultiPath TCP) придуман для возможности подключения сразу по нескольким каналам. Например, его поддерживает iOS и может одновременно подключать к удалённому серверу по WiFi и через сотовую сеть. Важно понимать, что это не два отдельных TCP-подключения, а именно одно подключение, установленное сразу по двум каналам. Чтобы это работало, удалённый сервер должен поддерживать MPTCP тоже.

OpenMPTCPRouter — это открытый проект программного роутера, позволяющего по-настоящему суммировать каналы. Авторы заявляют, что проект находится в статусе альфа-версии, но им уже можно пользоваться. Он состоит из двух частей — суммирующего сервера, который размещается в интернете и роутера, к которому подключаются несколько интернет-провайдеров и сами клиентские устройства: компьютеры, телефоны. В качестве пользовательского роутера может выступать Raspberry Pi, некоторые WiFi-роутеры или обычный компьютер. Есть готовые сборки под различные платформы, что очень удобно.


Настройка суммирующего сервера
Суммирующий сервер располагается в интернете и терминирует подключения со всех каналов клиентского роутера в одно. IP-адрес этого сервера будет внешним адресом при выходе в интернет через OpenMPTCPRouter.

Для этой задачи будем использовать VPS-сервер на Debian 10.

Требования к суммирующему серверу:

• MPTCP не работает на виртуализации OpenVZ
• Должна быть возможность установки собственного ядра Linux

Сервер разворачивается выполнением одной команды. Скрипт установит ядро с поддержкой mptcp и все необходимые пакеты. Доступны установочные скрипты для Ubuntu и Debian.

wget -O - http://www.openmptcprouter.com/server/debian10-x86_64.sh | sh

Результат успешной установки сервера.


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

uname -a 
Linux test-server.local 4.19.67-mptcp

Видим рядом с номером версии надпись mptcp, значит ядро установилось корректно.

Настройка клиентского роутера
На сайте проекта доступны готовые сборки для некоторых платформ, например Raspberry Pi, Banana Pi, роутеры Lynksys и виртуальные машины.
Эта часть openmptcprouter основана на OpenWRT, в качестве интерфейса используется LuCI, знакомый всем, кто когда-либо сталкивался с OpenWRT. Дистрибутив весит около 50Мб!


В качестве тестового стенда я буду использовать Raspberry Pi и несколько USB-модемов с разными операторами: МТС и Мегафон. Как записать образ на SD-карту, полагаю, не нужно рассказывать.

Изначально Ethernet-порт в Raspberry Pi настроен как lan со статическим IP-адресом 192.168.100.1. Чтобы не возиться с проводами на столе, я подключил Raspberry Pi к WiFi точке доступа и задал на WiFi-адаптере компьютера статический адрес 192.168.100.2. DHCP-сервер по умолчанию не включен, поэтому нужно использовать статические адреса.

Теперь можно зайти в веб-интерфейс 192.168.100.1

При первом входе система попросит задать пароль root, с этим же паролем будет доступен SSH.


В настройках LAN можно задать нужную подсеть и включить DHCP-сервер.

Я использую модемы, которые определяются как USB Ethernet интерфейсы с отдельным DHCP-сервером, поэтому это потребовало установки дополнительных пакетов. Процедура идентична настройке модемов в обычном OpenWRT, поэтому я не буду рассматривать её здесь.

Далее нужно настроить WAN-интерфейсы. Изначально в системе создано два виртуальных интерфейса WAN1 и WAN2. Им нужно назначить физическое устройство, в моем случае это имена интерфейсов USB-модемов.

Чтобы не запутаться в именах интерфейсов, я советую смотреть сообщения dmesg, подключившись по SSH.

Так как мои модемы сами выступают роутерами, и сами имеют DHCP-сервер, мне пришлось изменить настройки их внутренних диапазонов сетей и отключить DHCP-сервер, потому что изначально оба модема выдают адреса из одной сети, а это вызывает конфликт.

OpenMPTCPRouter требует, чтобы адреса WAN-интерфейсов были статическими, поэтому придумываем модемам подсети и настраиваем в меню system → openmptcprouter → interface settings. Здесь же нужно указать IP-адрес и ключ сервера, полученный на этапе установки суммирующего сервера.


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


По умолчанию используется режим shadowsocks + mptcp. Это такой прокси, который заворачивает в себя все подключения. Изначально он настроен обрабатывать только TCP, но можно включить и UDP.


Если на странице статуса нет ошибок, на этом настройку можно считать законченной.
С некоторыми провайдерами может возникнуть ситуация, когда на пути следования трафика флаг mptcp обрезается, тогда будет такая ошибка:

В этом случае можно использовать другой режим работы, без использования MPTCP, подробнее об этом здесь

Заключение
Проект OpenMPTCPRouter очень интересный и важный, так как это, пожалуй, единственное открытое комплексное решение проблемы суммирования каналов. Всё остальное либо наглухо закрытое и проприетарное, либо просто отдельные модули, разобраться с которыми обычному человеку не под силу. На текущем этапе развития проект ещё достаточно сырой, крайне бедная документация, многие вещи просто не описаны. Но при этом он всё-таки работает. Надеюсь, что он будет и дальше развиваться, и мы получим бытовые роутеры, которые будут уметь нормально объединять каналы из коробки.

https://vdsina.ru

TL;DR в статье описывается установка Kali Linux с графической средой на виртуальный сервер с ISO-образа по VNC. Такой системой можно пользоваться как полноценным десктопом.

Большинство хостеров предоставляют только консольный доступ к виртуальным серверам и ограниченный выбор образов операционных систем. Но что, если вы хотите установить собственную ОС со своего диска, например что-то экзотическое вроде Kali Linux? У нас вы можете подключить собственный ISO-образ и установить с него любую операционную систему, которая поддерживается гипервизором.

С момента установки- управление сервером происходит по VNC в графическом окружении, точно так же, как на десктопной виртуальной машине вроде VirtualBox или Vmwarе. Пользоваться таким сервером можно прямо в браузере без установки дополнительных программ.

Создание сервера
Первым делом нужно создать виртуальный сервер. Установка операционной системы из ISO-образа происходит уже на созданный сервер, а создать пустой сервер нельзя. Поэтому при создании сервера выбираем любой образ ОС, например CentOS. Этот выбор не имеет значения, так как мы все равно будем форматировать жесткий диск.


Графическая среда требует существенно больше системных ресурсов, поэтому выбираем конфигурацию с 4ГБ оперативной памяти для комфортной работы. Могу сказать, что и с 2ГБ тоже работает сносно, но тяжелые программы вроде Burp Suite на Java съедают всю память. Чтобы ресурсов точно хватило, мы подготовили для вас бонус — 1000 рублей при пополнении баланса от 3000 рублей. Чтобы его активировать, перейдите по этой ссылке для регистрации и пополнения.


Добавлять SSH-ключи не нужно, так как мы все равно форматируем диск и все настройки предустановленной системы будут удалены.

Дожидаемся завершения установки сервера, обычно это занимает не более минуты. Если в момент создания сервера оставить вкладку открытой, вы услышите звуковое уведомление о том, что сервер создан. Так же вы получите письмо на электронную почту с реквизитами для SSH-доступа к серверу. Эти реквизиты нам не потребуются, так как мы установим пароль на этапе установки новой системы.


Подключение ISO-образа
Теперь, когда сервер создан, мы можем подключить ISO-образ с Kali Linux. Для этого его сперва нужно смонтировать в панели управления, так подключенный ISO-образ будет доступен для подключения ко всем созданным серверам. Услуга подключения ISO-образа стоит 1 рубль в день. Нам он потребуется только на время установки, после чего его можно будет удалить.


Здесь можно загрузить ISO с компьютера, выбрать из нашей библиотеки или указать ссылку на файл с образом, который будет автоматически скачан. Нам не потребуется ничего скачивать, так как в библиотеке уже есть образ с Kali Linux. Не обращаем внимания на версию, так как Kali Linux выпускается по модели «Rolling release», он не имеет определенных мажорных версий, и всегда может быть обновлен до актуального состояния простым запуском apt ugprade.


Монтирование образа займет не более минуты, после чего его статус изменится на «активно». Теперь его можно подключать к существующим серверам. Для этого заходим в свойства сервера и нажимаем кнопку «Подключить ISO». После подключения ISO система будет перезагружена и загрузка системы начнется с образа.

Доступ по VNC
На этом этапе система загружена с ISO-образа и не имеет доступа в интернет. Единственный способ управления сервером, это подключиться к виртуальному экрану по VNC. В нашей панели управления встроен браузерный VNC-клиент, который запускается по нажатию одной кнопки. Никакие пароли при этом вводить не требуется.


При желании, вы можете использовать свой VNC-клиент, например Realvnc. Реквизиты для подключения можно посмотреть нажав на пиктограмму раскрытия пароля. Важно помнить, что адрес VNC-сервера отличается от IP-адреса вашего сервера.


Описывать все этапы установки Kali Linux мы не будем, так как они сводятся к простому нажатию Next -> Next -> Next -> Finish. Остановимся только на неочевидных моментах.

Настройка сети вручную
Виртуальный сервер не получит IP-адрес автоматически, так как в сети нет DHCP-сервера, поэтому его потребуется ввести вручную. На этапе обнаружения DHCP можно нажать Cancel, чтобы не тратить время.


Выбираем ручную конфигурацию и вводим IP-адрес, шлюз и маску сети. Все нужные настройки для конкретного сервера сразу указаны внизу страницы VNC-клиента.


Разметка диска и загрузчик
На этапе разметки диска достаточно выбрать пункт по-умолчанию. Таким образом мастер установки займет весь диск, отформатирует его и создаст разделы автоматически. В нашем случае нет необходимости использовать сложную разметку диска и создавать отдельные разделы.

Аналогичным образом поступаем с вопросом о загрузчике GRUB — выбираем пункт по умолчанию.

Завершение установки
После завершения установки система автоматически перезагрузится и мы снова попадем в загрузочное меню ISO-образа. Чтобы загрузить установленную систему с жесткого диска, нужно извлечь ISO из сервера. После чего сервер автоматически перезагрузится и мы попадем уже в установленный Kali Linux.

Чтобы не платить за смонтированный ISO-образ, его можно удалить из панели управления. Он нам больше не нужен.


Заключение
Готово! Теперь у нас есть дистрибутив Kali Linux, который всегда включен и доступен. Не нужно нагружать основной компьютер виртуальным машинами и страдать, если нужно перезагрузиться.
Это особенно удобно когда нужно запустить какую-то ресурсоемкую программу вроде сканера, и оставить ее выполняться на несколько дней.


Напомним, что VNC не единственный способ управлять сервером. На нем так же можно активировать SSH, который выключен по-умолчанию, или использовать другие программы удаленного рабочего стола, например TeamViewer.

https://vdsina.ru

8chan (новое название 8kun) — популярный анонимный форум с возможностью пользователей создавать собственные тематические разделы сайта и самостоятельно их администрировать. Известен своей политикой минимального вмешательства администрации в модерирование контента, из-за чего стал популярен у разной сомнительной публики.

После того как на сайте оставили свои послания террористы-одиночки, на форум начались гонения — их стали выгонять со всех хостингов, регистраторы разделегировали доменные имена и т.д.

С правовой точки зрения ситуация с 8chan достаточно спорная, так как администрация декларирует, что следует законам США и удаляет запрещённый контент с сайта, а также выполняет запросы правоохранительных органов. Претензии к 8chan носят скорее морально-этический характер: место имеет дурную репутацию.

2 ноября 2019 к нам на хостинг vdsina.ru пришёл 8chan. Это вызвало оживлённые споры внутри нашего коллектива из-за чего мы решили опубликовать этот пост. В статье рассказывается история гонений на 8chan и почему мы в итоге решили предоставить хостинг проекту 8chan (который всё равно закрылся).

Хронология событий
Мы не будем описывать конкретные эпизоды трагедий, участники которых как-либо упоминаются в контексте 8chan. Отношение к этим событиям однозначно для любого здорового человека и не является для нас предметом споров. Главный вопрос, который мы хотим поднять — это может ли поставщик услуг выступать в роли цензора и решать кому отказывать в предоставлении сервиса, основываясь не на букве закона, а на своём представлении о морали.

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

Исключение из поисковой выдачи Google
В августе 2015 сайт 8ch.net перестал показываться в поисковой выдаче Google. В качестве причины для удаления было указано «Жалобы на контент, содержащий насилие над детьми». При этом правила сайта явно запрещали публикацию такого контента и с самого сайта 8ch.net подобный медиа-контент оперативно удалялся.

Спустя несколько дней, после публикации на ArsTechnica, сайт 8ch.net частично вернулся в поисковую выдачу Google.

Отключение от CloudFlare

Сайт 8chan использовал сервис CloudFlare для защиты от DDoS-атак и в качестве CDN. 5 августа 2019 года в блоге Cloudflare был опубликован большой пост о том почему они решили прекратить обслуживание 8chan.

Вот краткие выдержки из этого поста:

… стало известно, что подозреваемый в расстрелах террорист был вдохновлён интернет-форумом 8chan. Основываясь на предоставленных доказательствах, можно утверждать, что он выложил целую речь прямо перед тем, как убить 20 человек.

...8chan не раз подтверждал звание выгребной ямы для ненависти.

— Cloudflare о прекращении обслуживания 8chan

В своём посте CloudFlare сравнивает сайт 8chan с другим скандальным сайтом, антисемитским новостным изданием The Daily Stormer, которому так же ранее было отказано в обслуживании. Однако главное отличие The Daily Stormer от 8chan в том, что первый сайт прямо позиционируется как антисемитский и контент публикуется самими авторами сайта, в то время как на 8chan весь контент является пользовательским, точно так же, как в условном facebook или twitter. При этом позиция администрации 8chan состоит в том, чтобы не вмешиваться в контент пользователей «сверх того, что требует закон США». То есть администрация сайта блокирует, к примеру, сцены насилия над несовершеннолетними, но не запрещает дискуссии.

CloudFlare явно осознают неоднозначность своего решения, когда пишут, что им оно не слишком нравится, но при этом полностью законно.

Нам по-прежнему крайне неудобно находиться в роли судей контента и мы не планируем часто делать это. Многие ошибочно предполагают, что причина тому — первая поправка США. Это не так. Во-первых, мы частная компания и мы не ограничены первой поправкой. Во-вторых, подавляющее большинство наших покупателей, и более 50% нашего дохода приходит из-за границ США, где, ни первая поправка, ни аналогичная ей либертарианская защита свободы слова не применимы. Единственное сходство с первой поправкой здесь в том, что мы имеем право выбирать с кем вести бизнес, а с кем нет. Нас не обязывают вести бизнес со всеми.

— Cloudflare о прекращении обслуживания 8chan

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

Вольный перевод:

Чо? Почему вы называете 8chan сайтом ненависти и обвиняете его в «беззаконии»? Это просто движок, на котором любой может создать свою борду и самостоятельно её администрировать. Как можно сравнивать это с The Daily Stormer, новостным сайтом со своим администратором?

И вообще почему вы обвиняете сайт в убийствах? Это люди убивают людей, а не форум в интернете. Если они будут использовать смски и мобильную связь, чтобы общаться с другими людьми, то надо отключить мобильную связь?

Отключение хостинга
После отключения от CloudFlare обнаружился реальный IP хостинг-площадки 8chan. Это были адреса дата-центра Voxility. Официальный аккаунт Voxility в твиттере написал, что адреса принадлежали реселлеру под названиями Epik/Bitmitigate, которого сразу отключили.


Переезд в Россию
Спустя три месяца после отключения хостинга, сайт возобновил работу под новым именем 8kun.net. Согласно расследованию CBS News, сперва сайт развернулся на площадке Selectel, но в тот же день был заблокирован. После чего переехал к нам.

Почти сразу один из наших бизнес-партнёров потребовал заблокировать ресурс, потому что 8kun нарушает их AUP. Мы начали искать возможность предоставить хостинг для 8kun, не нарушая партнёрских договорённостей и как только нашли такой, разблокировали серверы 8kun. К тому моменту ресурс успел переехать на Medialand.

Мы приняли решение не блокировать сайт, пока он не нарушает законы стран, в которых мы работаем.

Подпольный хостинг Medialand
Вскоре домен 8kun.net стал указывать на IP-адрес 185.254.121.200, который формально не должен принадлежать никому, так как находится в нераспределённом пуле адресов и официально не выделен ещё ни одному провайдеру. Однако этот адрес анонсируется из автономной системы AS206728, которая по данным Whois принадлежит провайдеру MEDIALAND. Это русский подпольный хостинг, получивший известность после расследование Брайна Кребса — Крупнейший пуленепробиваемый хостинг.

Компания «Медиа Лэнд» принадлежит россиянину Александру Воловику, и по мнению Брайана Кребса и других исследователей, используется для хостинга мошеннических проектов, контрольных панелей ботнетов, вирусов и прочих преступных целей.

Доклад на конференции BlackHat USA 2017 о сетевой инфраструктуре преступников, в которой фигурирует хостер «Медиа Лэнд».

Разделегирование доменов
За время существования сайта, у него сменился владелец. Из-за разногласий с прошлым владельцем, доменное имя 8ch.net сохранить не удалось. В октябре 2019 сайт был переименован в 8kun.net и анонсирован перезапуск проекта.

Пока домен 8kun.net был активен, посторонние люди зарегистрировали у регистратора name.com несколько доменов:

• 8kun.app
• 8kun.dev
• 8kun.live
• 8kun.org

И установили переадресацию на домен 8kun.net. Все эти домены были разделегированы Name.com якобы за нарушение правил, при этом заблокировав возможность переноса доменов к другому регистратору. Об этом сообщил владелец доменов.

Вскоре домен 8kun.net был разделегирован по заявлению бывшего владельца.

Некоторые время сайт был доступен по адресу 8kun.us, но и этот домен был разделегирован.
Забавный момент — нам писал регистратор этого домена с просьбой заблокировать хостинг, хотя сами они могли выключить домен в один клик.


На текущий момент сайт 8chan полностью недоступен в клирнете (обычном интернете) и зайти на него можно только через сеть TOR используя onion-адрес.

Заключение
Мы никоим образом не поддерживаем насилие и нетерпимость в любой форме. Целью данного поста является обсуждение технической и правовой стороны проблемы. А именно: могут ли поставщики услуг самостоятельно, не дожидаясь судебных решений, определять какой ресурс является незаконным.

Совершенно очевидно, что любые публичные сервисы, которые разрешают публикацию пользовательского контента, обязательно будут регулярно использованы во зло. На площадках Facebook, Instagram, Twitter публикуются сотни обращений террористов и даже их прямые трансляции. При этом не ставится вопрос о том, что существование этих площадок влияет на количество преступлений.

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

Вопрос сложный и легко можно найти аргументы как за, так и против блокировки 8chan. А как вы считаете?

https://vdsina.ru

Если ваша работа требует держать множество SSH-сессий к разным серверам, вы наверняка знаете, как они легко ломаются при переключении на другой Wi-Fi или при временной потере интернета. Но что, если я скажу вам, что все эти проблемы давно решены и можно забыть про сломанные сессии и постоянные переподключения?

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

Настройка сервера
Идея проста и наглядно проиллюстрирована на картинке в заголовке поста: все SSH-подключения мы будем держать на специальном терминальном сервере. Этот сервер будет нашей точкой входа для управления другими серверами. При этом на конечных серверах не потребуется настройки или установки дополнительного ПО.
Для терминального сервера подойдет почти любая конфигурация, но лучше иметь побольше оперативной памяти, чтобы хранить лог консоли внутри каждой сессии и иметь возможность в любой момент проскроллить историю вверх и посмотреть, что вы делали на сервере сессии месяц назад. Обычно 1-2ГБ памяти достаточно.

Выбор дистрибутива
В терминальном сервере самое главное — это uptime, ведь чем реже мы перезагружаемся, тем больше живут наши SSH-сессии. Поэтому выбираем максимально консервативный LTS (Long Term Support) дистрибутив, например стабильную ветку debian или ubuntu. Настраиваем автоматические обновления (unattended-upgrades) таким образом, чтобы внезапный перезапуск программ не стал неожиданностью.

Настройка SSH-сервера
Так как терминальный сервер будет открывать доступ ко всем нашим серверам разом, будет правильно его обезопасить. Для этого запретим аутентификацию с помощью паролей, оставив только доступ с помощью ключей, а так же запретим логиниться пользователем root.
Предварительно нужно создать нового пользователя в системе.

/etc/ssh/sshd_config
.....
# Запрет логиниться пользователем root
PermitRootLogin no
# Запрет использования паролей, только ключи
ChallengeResponseAuthentication no
# Если паролей нет, то и PAM не нужен
UsePAM no
....

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

Часто начинающие админы в своих руководствах советуют менять порт SSH и вместо 22 устанавливать какой-то нестандартный вроде 2222. На мой взгляд это плохая практика, не добавляющая никакой безопасности.

• Это не позволит защититься от перебора паролей, так как автоматические сканеры всё равно найдут SSH на любом порту и начнут долбиться.
• Это вносит бардак, если систему администрирует несколько человек и каждый выдумывает свои порты. Когда таких систем десятки, приходится искать сканером на каком порту спрятан SSH на этот раз.
• Это ломает встроенные ограничения безопасности в программах. Например, веб-браузеры не подключатся на порт 22, если явно указать его в HTTP, но при этом подключатся на другой нестандартный порт. Это можно использовать для срабатывания IDS/IPS систем DDoS.

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

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

Устанавливаем tmux, если он еще не установлен:

apt install tmux

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

Создаем новую сессию:

tmux new

В этот момент мы создали новую сессию с одним окном и сразу подключились к ней. Можно видеть появившуюся внизу зелёную панель состояния. Это что-то вроде панели с вкладками в браузере. На ней будут отображаться текущая вкладка и соседние, а также служебные сообщения.

В этот момент, даже если мы закроем SSH-подключение и заново подключимся к серверу, наша запущенная сессия tmux останется в прежнем состоянии, вместе со всеми запущенными программами так, будто мы ее свернули. Попробуем запустить программу top внутри сессии tmux и отключимся от неё. Для наглядности закроем полностью окно терминала и заново подключимся к серверу.

После переподключения к серверу подключимся к нашей запущенной ранее сессии:
tmux attach

И убедимся, что запущенная программа top продолжает работать. На этом месте важно понять главный принцип: после запуска сессия tmux остается работать в фоне на сервере вне зависимости от того, подключены вы к ней или нет.

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

Tmux умеет делить окно на несколько (каждое окно внутри вкладки называется pane), это удобно, когда нужно одновременно видеть две консоли. Например, в одном окне редактировать скрипт, а в другом смотреть лог.


По умолчанию, для управления tmux-ом используется хоткей Ctrl+b. После нажатия этого управляющего хоткея tmux ожидает ввода основной команды из одной буквы.

Вот основные команды:

• Ctrl+b + c — (create) Создать новое окно (вкладку)
• Ctrl+b + <цифра> — Переместиться на вкладку номер N, где цифра это клавиша от 0 до 9. Нумерация окон начинается с нуля.
• Ctrl+b + x — закрыть текущее окно. Если будет закрыто последнее окно, сессия tmux завершится.
• Ctrl+b + w — отобразить список всех окон, по которому можно перемещаться кнопками курсора вверх-вниз и выбрать нужное, нажав enter.
• Ctrl+b + " — разделить окно пополам по горизонтали и создать новое
• Ctrl+b + % — разделить окно по вертикали и создать новое
• Ctrl+b +, — переименовать текущее окно
• Ctrl+b + вниз/вверх/влево/вправо — перемещаться по pane'ам внутри окна
• Ctrl+b + page up/page down — прокрутить скролл вверх
• Ctrl+b + / — искать по истории, как в vim или less

Это все хоткеи, которые мне потребовались за 10 лет использования tmux. На самом деле их намного больше, но для начала лучше остановиться на этих.

Конфиг Tmux
Я считаю хоткей Ctrl+b неудобным, так как прожимать три клавиши для любого действия выходит слишком много. Тема конфигов tmux это отдельная область вкусовщины, и у каждого бывалого пользователя есть свое видение как правильно и удобно. Есть даже целые авторские подборки конфигов и тем для tmux.

Для отправной точки я приведу пример своего конфига, который, как мне кажется, исправляет все сложности, мешающие быстрому освоению tmux. Конфиг располагается в домашней папке с именем ~/.tmux.conf

# Вместо ctrl+b будет использовать одну кнопку. Нам моем macbook это самая правая клавиша в цифровом ряду
set-option -g prefix `

# Когда нужно послать символ <`> нажимаем `+a
bind-key a send-prefix

# Нумерация окон с единицы вместо ноля
set -g base-index 1
set-option -g base-index 1
setw -g pane-base-index 1

# Lowers the delay time between the prefix key and other keys - fixes pausing in vim
set-option -sg escape-time 1

# Лимит истории консоли в 1000 строк. Столько строк можно отскроллить вверх
set -g history-limit 1000

# Цвета статус бара

# default statusbar colors
set-option -g status-fg white
set-option -g status-bg default

# default window title colors
set-window-option -g window-status-fg default
set-window-option -g window-status-bg default




# Автозапуск окон с командами при первом запуске
#------------------

# Respawn windows when PANE IS DEAD
bind-key R respawn-window

# Создать сессию default с окном local
new -d -s default -n local

# Создать окно с именем irc и командой irssi
neww -d -n irc irssi

# Создать окно с именем superserver и командой ssh root@superserver.com
neww -d -n superserver ssh root@superserver.com

# Создать окно с именем anotherserver и командой ssh root@123.123.123.123
neww -d -n superserver anotherserver root@123.123.123.123

Данная конфигурация позволяет автоматически создавать несколько окон при запуске, в которых сразу запускаются SSH-сессии. При этом не требуется вручную создавать новую сессию командой tmux new, достаточно всегда вводить tmux attach. Если сессия до этого не существовала, она будет создана.

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

Для этого добавим в конец файла ~/.bashrc запуск tmux. Важно помнить, что такая конструкция будет работать только с конфигом выше.

if [ ! "$TMUX" ]; then
 tmux attach
fi

if [ "$TMUX" ]; then
 export TERM=screen
fi

Это простое условие означает, что если мы не в tmux, то подключаемся к нему.
На этом конфигурация tmux на терминальном сервере закончена. Отныне для каждого нового SSH-подключения мы будем создавать отдельное окно в tmux. И даже если соединения с терминальным сервером будет потеряно, все SSH-подключения останутся активными.

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

Mosh — надстройка над обычным OpenSSH сервером, которая позволяет забыть о разрывах соединения. Mosh авторизуется по обычному SSH, после чего поднимается отдельный UDP-канал, который мгновенно восстанавливается после разрыва, даже если у вас сменился внешний IP-адрес.
Так как нам нужно держать постоянное подключение к терминальному серверу, мы установим mosh только на сервер и на наш рабочий компьютер. При этом на удалённые серверы ничего устанавливать не потребуется, так как подключения к ним и так уже живут вечно в tmux.

Устанавливаем mosh на сервер:

apt install mosh

Устанавливаем mosh на наш рабочий компьютер. Он доступен для всех основных операционных систем, но нативный клиент есть только для Unix-подобных операционных систем. Версия для Windows реализована с помощью Cygwin либо приложения Chrome.

Я использую macOS, и устанавливаю mosh через пакетный менеджер brew:

brew install mosh

В большинстве случаев mosh не требует дополнительной настройки и работает прямо из коробки. Достаточно вместо команды ssh написать mosh:

mosh user@my-server.com

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

mosh --ssh="ssh -p 2222 -i /path/to/ssh.key" user@my-server.com

Первичную аутентификацию mosh выполняет как обычный SSH-клиент, авторизуясь на стандартный порт 22. При этом mosh-сервер изначально не слушает никаких портов, и кроме оригинального демона OpenSSH наружу никаких портов на сервере не открыто. После подключения по TCP, mosh запускается на сервере в юзерспейсе и открывает дополнительный тоннель по UDP.


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

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

alias t='mosh --ssh="ssh -p 443 -i /path/to/ssh.key" user@my-server.com'

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

https://vdsina.ru

TL;DR В статье описывается самый простой способ настроить VPN-сервер, у которого IP-адрес для подключения VPN-клиентов отличается от IP-адреса, с которого клиенты выходят в интернет.

Используете VPN для защиты приватности в интернете и арендуете для этого свой личный сервер? При этом вы единственный клиент, который подключается к этому серверу во всем мире? Так ли сложно найти ваш реальный IP-адрес, как вам кажется? С вступлением в силу пакета Яровой, это становится намного проще.

Double VPN — популярная тема, вокруг которой много спекуляций. Часто этим термином называют совершенно разные технологии, но почти всегда это означает разнесенные на уровне IP-адресов точки подключения и выхода в интернет. Мы рассмотрим самый простой способ настройки VPN-сервера в таком режиме, который не требует дополнительной настройки на серверной стороне и позволяет получить максимальную скорость и самые низкие задержки.

Модель угроз
Для того, чтобы от чего-то защищаться, нужно четко понимать модель угроз. Мы не будем рассуждать о новых законах, требующих от провайдеров хранить весь трафик клиентов, но совершенно точно можно сказать, что данные о подключениях, т.н. Netflow, хранить достаточно просто, и это давно и успешно делается. То есть факт подключения условного IP-адреса 1.1.1.1 к адресу 2.2.2.2 в определенное время суток записывается.

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

Чтобы повысить уровень приватности при использовании VPN, необходимо разделить точку подключения и точку выхода в интернет на уровне IP. На картинке выше наш пользователь находится за забором под пристальным вниманием Ирины Яровой. Все подключения, проходящие через забор, Ирина строго запоминает. Пользователь, как порядочный гражданин, подключается к адресу good.citizen.vpn, при этом назад он возвращается уже с адреса super.cool.guy.vpn. В итоге для Ирины эти два подключения выглядят не связанными между собой.

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

Мы разберём самые типовые схемы, которые применяют на практике.

VPN между серверами
Самый распространенный способ. В таком режиме клиент устанавливает VPN-подключение к только первому серверу. На первом сервере настроен тоннель ко второму, и весь трафик от клиента уходит ко второму серверу, и так далее. Промежуточных серверов может быть несколько. При этом тоннель между серверами может быть установлен по любому другому протоколу, отличному от протокола, по которому подключен клиент, например IPsec, или вообще без шифрования, вроде GRE или IPIP. В таком режиме все промежуточные сервера может быть видно в трассировке маршрута. Проверить, как именно подключены между собой промежуточные сервера на стороне клиента нет возможности, поэтому можно только доверять провайдеру.

На всём пути следования трафика минимальный MTU (Maximum transmission unit) остаётся равным значению самого первого тоннеля, и каждый промежуточный сервер имеет доступ к расшифрованному трафику клиента.

VPN через прокси

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

В этом режиме прокси-сервер не видно в трассировке маршрута.


VPN внутри VPN
Самый параноидальный и медленный способ: все тоннели поднимаются на стороне клиента, при этом каждый внутри другого. Такой способ требует хитрой настройки маршрутов на стороне клиента и запуска всех VPN-клиентов в нужном порядке. Это плохо сказывается на задержках и производительности, зато промежуточные сервера не имеют доступа к открытому трафику клиента. Все накладные расходы по инкапсуляции суммируются, и максимальный размер пакета (MTU), доступный в итоге клиенту, уменьшается в зависимости от числа тоннелей. Промежуточные сервера не видны в трассировке маршрутов.


Настройка VDS
Самый лёгкий способ настроить VPN с разделёнными точками входа и выхода — подключить несколько IP-адресов на один виртуальный сервер. Этот способ позволяет получить максимальную скорость и минимальные задержки, так как по сути трафик терминируется на одном сервере. У нас, в Vdsina.ru вы можете это сделать самостоятельно из панели управления. В то время как IPv4 везде кончаются, мы выдаем дополнительные IP-адреса даже на серверах за 60 рублей!

Разберем поэтапно настройку сервера.

Выбираем сервер
Заказываем VDS с подходящим тарифом, в нужном датацентре. Учитывая нашу задачу, выберем датацентр подальше, в Нидерландах ;)


Подключаем дополнительный IP-адрес
После покупки дополнительного IP-адреса его нужно настроить по инструкции.


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

Для примеров будем использовать такие значения:

xxx.xxx.38.220 — super.cool.guy.vpn # внешний адрес (точка выхода)
xxx.xxx.39.154 — good.citizen.vpn # адрес подключения (точка входа)

Проверка двух IP
Важно помнить, что тот IP-адрес, который был установлен на сервере изначально, будет точкой выхода, соответственно новый адрес будет точкой входа. Подключимся по SSH к серверу и проверим, какой адрес используется в качестве внешнего.

Для этого проще всего из консоли использовать сервис ifconfig.co. При запросе через curl он возвращает IP-адрес, с которого был сделан запрос.

$ curl ifconfig.co
xxx.xxx.38.220

По последним цифрам видно, наш внешний адрес действительно соответствует точке выхода. Попробуем проверить корректность работы второго IP в качестве точки входа. Для этого просто используем встроенную в SSH функцию SOCKS-прокси.

Команды выполняются на клиенте:

ssh -D 9999 root@good.citizen.vpn

# в новом окне
curl -x socks5h://127.0.0.1:9999 ifconfig.co
super.cool.guy.vpn

Первая команда устанавливает SSH-сессию с адресом good.citizen.vpn и одновременно активирует SOCKS-прокси внутри этой сессии, который доступен на локальном порту. Вторая делает обычный HTTP-запрос через этот прокси.

Важно помнить, что в наших примерах для запросов используются выдуманные доменные имена. Они будут отображаться только при PTR-резолве, и полноценный запрос к ним сделать не получится. Поэтому на данном этапе обращаться к серверу нужно через IP-адрес.

Настройка сервера IKEv2


IPsec IKEv2 — современный протокол VPN, поддерживаемый почти всеми операционными системами из коробки. Он используется как протокол по-умолчанию в Windows, macOS и iOS. При этом не требует установки стороннего ПО и работает в большинстве случаев быстрее OpenVPN. На хабре уже были статьи по настройке сервера IKEv2, но все они описывают использование самоподписанных сертификатов, и неудобны тем, что требуют установить корневой сертификат на стороне VPN-клиента.

Мы же разберем пример настройки сервера с использованием доверенного сертификата от Let's Encrypt. Это позволяет не устанавливать клиенту посторонние корневые сертификаты, а выдать только логин и пароль.

Подготовка сервера
Мы будем использовать сервер на базе Ubuntu 18.04, но инструкция также подходит для большинства современных дистрибутивов.

Обновляем систему и устанавливаем нужные пакеты

apt update && apt upgrade

apt install certbot strongswan libstrongswan-extra-plugins

Выпуск сертификата
Для выпуска доверенного сертификата вам потребуется направить реальный домен на IP-адрес точки входа. Мы не будем рассматривать этот пункт подробно, так как он выходит за рамки статьи. В качестве примера мы будем использовать вымышленный домен good.citizen.vpn

Если у вас на сервере уже есть есть веб-сервер, используйте подходящий способ выпуска сертификата через certbot или другой клиент для Let's Encrypt. В данном примере предполагается, что порт HTTP (80) ничем не занят.

certbot certonly --standalone --agree-tos -d good.citizen.vpn

Ответив на вопросы мастера? мы получим подписанный сертификат и ключ

# find /etc/letsencrypt/live/good.citizen.vpn/

/etc/letsencrypt/live/good.citizen.vpn/
/etc/letsencrypt/live/good.citizen.vpn/fullchain.pem
/etc/letsencrypt/live/good.citizen.vpn/README
/etc/letsencrypt/live/good.citizen.vpn/cert.pem
/etc/letsencrypt/live/good.citizen.vpn/privkey.pem
/etc/letsencrypt/live/good.citizen.vpn/chain.pem

Для проверки подлинности IKEv2 сервера используются те же X.509-сертификаты, что и для
HTTPS. Чтобы Strongswan смог использовать эти сертификаты, их нужно скопировать в папку /etc/ipsec.d.

Вот как должны быть расположены сертификаты:

cp /etc/letsencrypt/live/good.citizen.vpn/cert.pem /etc/ipsec.d/certs/
cp /etc/letsencrypt/live/good.citizen.vpn/privkey.pem /etc/ipsec.d/private/
cp /etc/letsencrypt/live/good.citizen.vpn/chain.pem /etc/ipsec.d/cacerts/

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

Задача скрипта скопировать три файла в нужную папку каждый раз, когда сертификат обновился, и после этого послать команду strongswan перечитать сертификаты.

Создадим файл /etc/letsencrypt/renewal-hooks/deploy/renew-copy.sh и сделаем его исполняемым.

#!/bin/sh

set -e

for domain in $RENEWED_DOMAINS; do
        case $domain in
        good.citizen.vpn)
                daemon_cert_root=/etc/ipsec.d/

                # Make sure the certificate and private key files are
                # never world readable, even just for an instant while
                # we're copying them into daemon_cert_root.
                umask 077

                cp "$RENEWED_LINEAGE/cert.pem" "$daemon_cert_root/certs/"
                cp "$RENEWED_LINEAGE/chain.pem" "$daemon_cert_root/cacerts/"
               cp "$RENEWED_LINEAGE/privkey.pem" "$daemon_cert_root/private/"

                 # Reread certificates
                /usr/sbin/ipsec reload
                /usr/sbin/ipsec purgecerts
                /usr/sbin/ipsec rereadall
                ;;
        esac
done

Теперь после каждого перевыпуска сертификата скрипт будет копировать новые файлы в папки strongswan-а и посылать команду демону перечитать сертификаты.

Настройка Strongswan
Добавим конфиг strongswan /etc/ipsec.conf

config setup

    #  Разрешить несколько подключений с одного аккаунта
    uniqueids=no

    # Increase debug level
    # charondebug = ike 3, cfg 3

conn %default

    # Универсальный набор шифров для большинства платформ
    ike=aes256-sha256-modp1024,aes256-sha256-modp2048

    # Таймауты "мёртвых" подключений
    dpdaction=clear
    dpddelay=35s
    dpdtimeout=2000s

    keyexchange=ikev2
    auto=add
    rekey=no
    reauth=no
    fragmentation=yes
    #compress=yes

    # left - local (server) side
    leftcert=cert.pem # Имя файла сертификата в папке /etc/ipsec.d/certs/
    leftsendcert=always
    # Маршруты отправляемые клиенту
    leftsubnet=0.0.0.0/0

    # right - remote (client) side
    eap_identity=%identity
    # Диапазон внутренних IP-адресов назначаемых VPN-клиентам
    rightsourceip=10.0.1.0/24
    rightdns=8.8.8.8,1.1.1.1

 # Windows and BlackBerry clients usually goes here
conn ikev2-mschapv2
    rightauth=eap-mschapv2

# Apple clients usually goes here
conn ikev2-mschapv2-apple
    rightauth=eap-mschapv2
    leftid=good.citizen.vpn

Логины и пароли VPN-клиентов задаются в файле /etc/ipsec.secrets

В этом файле также нужно указать имя приватного ключа, который мы ранее копировали из папки letsencrypt:

# Имя файла приватного ключа в папке /etc/ipsec.d/private/
: RSA privkey.pem

# Пользователи VPN
# имя : EAP "Пароль"
IrinaYarovaya : EAP "PleaseLoveMe123"
Mizooleena : EAP "IwannaLoveToo3332"

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

$ systemctl restart strongswan

$ ipsec statusall
Virtual IP pools (size/online/offline):
  10.0.1.0/24: 254/0/0
Listening IP addresses:
 xxx.xxx.38.220
Connections:
ikev2-mschapv2:  %any...%any  IKEv2, dpddelay=35s
ikev2-mschapv2:   local:  [CN=good.citizen.vpn] uses public key authentication
ikev2-mschapv2:    cert:  "CN=good.citizen.vpn"
ikev2-mschapv2:   remote: uses EAP_MSCHAPV2 authentication with EAP identity '%any'
ikev2-mschapv2:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear
ikev2-mschapv2-apple:  %any...%any  IKEv2, dpddelay=35s
ikev2-mschapv2-apple:   local:  [good.citizen.vpn] uses public key authentication
ikev2-mschapv2-apple:    cert:  "CN=good.citizen.vpn"
ikev2-mschapv2-apple:   remote: uses EAP_MSCHAPV2 authentication with EAP identity '%any'
ikev2-mschapv2-apple:   child:  0.0.0.0/0 === dynamic TUNNEL, dpdaction=clear

Можно видеть, что конфиг успешно активирован и сертификат подключен. На данном этапе уже можно подключаться к VPN-серверу, но он будет без доступа к интернету. Чтобы выпустить клиентов в интернет, нужно включить форвардинг и настроить NAT.

Настройка NAT
Активируем форвардинг пакетов:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

Включаем NAT. Важно иметь в виду, что это просто пример минимальной конфигурации iptables. Настройте остальные правила в зависимости от ваших потребностей.

ethName0 — замените на свое имя интерфейса
10.0.1.0/24 — диапазон IP-адресов который будет выдаваться VPN-клиентам. Мы задавали его в /etc/ipsec.conf
111.111.111.111 — IP-адрес точки выхода, в нашем примере это адрес super.cool.guy.vpn

iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o ethName0 -j SNAT --to-source 111.111.111.111

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

В случае проблем с подключением можно смотреть лог в реальном времени:

journalctl -f -u strongswan

Автозапуск при загрузке
Если всё успешно, можно добавить strongswan в автозапуск при загрузке:

systemctl enable strongswan

Сохранение правил iptables
Чтобы сохранить правила iptables после перезагрузки, существует специальный пакет iptables-persistent. Важно помнить, что он сохранит текущий набор правил и добавит его в автозагрузку.

apt install iptables-persistent

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

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

https://vdsina.ru

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

Сегодня наш фронтенд разработчик Артыш расскажет, как писал фронтенд этой панели: какой выбрали фреймворк, какой антипаттерн считаем хорошим тоном и как защищаться от бекдоров, если пользуетесь готовыми библиотеками.

Выбор фреймворка: почему искали новый
Предыдущая панель была реализована на собственном фреймворке, написанном на jQuery. Мы сидели на VMManager, он требовал много доработок: по интерфейсу и функционалу, было тяжело сопровождать такой код. Добавление нового функционала в панель со стороны фронта занимало много времени. Понятно, что при желании и на jQuery можно реализовать хороший фреймворк (я до сих пор люблю jQuery) или даже подобие CMS, но это был не оптимальный вариант: начиная скудной документацией по самописному фреймворку и заканчивая не совсем корректной архитектурой самого приложения.

Старая панель была реализована в виде Single Page Application и на этом его хорошие качества заканчивались. После решения очередной головоломки по добавлению кнопки в список, пришло понимание, что нужна альтернатива. Выбор пал на Vue.

Почему SPA?
Single Page Application — идеальный выбор для панели управления. Панель управления в плане рендеринга довольно простая штука, эту работу можно легко доверить браузеру пользователя. К тому же панели не важна SEO-оптимизация, для этого у нас есть основной сайт. Ну и требуемое время на начальную загрузку всех необходимых скриптов пользователи панели воспринимают спокойно в силу специфики самих этих пользователей. Опять же, бекенд у нас получился классическим RestAPI сервисом — для предоставления в будущем открытого API нашим клиентам.

SPA приложение получилось таким легким, что хорошо работает с браузера телефонов и планшетов — мы просто сделали адаптивную верстку и создавать отдельное приложение не пришлось.

Почему Vue?
3 года назад Vue был относительно молодым фреймворком, но уже тогда о нем много говорили и писали, и когда вышел релиз версии 2.0, мы решили сделать ставку на него — и не прогадали. Сначала планировали просто постепенно заменять какие-то компоненты написанные на jQuery и Vue это позволял делать легко. Но потом, после того, как были переписаны довольно объемные компоненты, все таки решили, что лучше переписать вообще все приложение на Vue.
Это бы рискованный шаг и мы решили его сделать по 4 причинам:

• Vue — простой декларативный фреймворк, его понимают даже верстальщики. Если что, под него легко найти разработчика или просто научить товарища. А значит у нас не будет проблем с поиском нового разработчика и его вхождением в проект, если меня переедет трамвай (хвала богам, в моем городе их нет).
• Vue объективно хорош для написания SPA приложений.
• У меня перед глазами был опыт развития React и я предположил, что популярность Vue будет расти так же. Сейчас фреймворк входит в TOP-3 популярных JS-фреймворков (это легко проверить поисковым запросом), уступая только React и Angular. У него хорошая поддержка, развитая экосистема и большое комьюнити.
• Скорость разработки. Лично я сразу стал воспринимать Vue как этакий конструктор и разработка на нем идет довольно быстро: если мне нужен, например, компонент выбора даты, скорее всего на Vue он уже существует, свободен в использовании и опробован сообществом. Я просто устанавливаю компонент в проект, пишу тег и все работает. По сути, наша панель состоит на 70-80% из готовых библиотек. Я имею в виду именно использование компонента, а не размер кодовой базы, который можно проверить командой типа: npx intrinsic/loc

При реализации проекта всегда учитываешь его перспективы, особенно перспективы развития. И то, что в экосистеме Vue уже имеются такие инструменты как Weex, Quasar Framework или Nuxt по мне существенно расширяют горизонты развития нашей панели.

На Хабре есть замечательная статья о Vue от его создателя, а я расскажу о некоторых особенностях нашего приложения.

Синхронизация Vuex с сервисом RestAPI
Часть данных глобального хранилища Vuex в нашем приложении синхронизируется с RestAPI путем обыкновенных запросов по соответствующим адресам. Зачем мы так сделали? Ну хотя бы для того, чтобы основные настройки пользователя не были привязаны к конкретному браузеру конкретного устройства. Можно зайти в нашу панель с компьютера жены или из игрового клуба и при этом получить в то же знакомое окружение, что и было у вас на своей родной машине.

Кроме того, когда синхронизация была только с localStorage, некоторые браузеры при обновлениях теряли содержимое localStorage — оно полностью удалялось. Да и в последнее время прослеживается какая то тенденция к ужесточению политики хранения данных пользователей в куках, например функция в WebKit Intelligent Tracking Prevention — не ровен час они доберутся и до localStorage.

Шина событий
Да, мы используем глобальную шину событий. Как и в любом другом крупном приложении с множеством компонентов, рано или поздно возникает необходимость наладить взаимодействие между не связанными между собой компонентами. Даже через глобальное хранилище. Понятно, что если есть связь родитель-потомок, их взаимодействие стандартно организуется через свойства props в одну сторону и методом $emit в другую, ну или через хранилище, как и описано в рекомендациях Vue.

Но в документации описана и возможность использования глобальной шины событий. У нас в проекте куча форм с разными наборами полей и в некоторых случаях (их немного, но все из них принципиальные) нужно как-то по особенному реагировать на изменение значения поля. Хранить в глобальном хранилище значения всех полей каждой формы не имеет смысла:

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

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

Взаимодействие RestAPI с панелью
Для большей отзывчивости интерфейса в старом jQuery-фреймворке обратная связь от RestAPI к клиентскому приложению эмулировалась через хитрую систему таймеров: она производила опросы RestAPI с определенным интервалом и перерисовывала узлы DOM, которые затронули изменения.

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

Для решения этой проблемы в новой панели я решил использовать связку из модуля Nchan для веб сервера Nginx и новых возможностей HTML5-интерфейсов — EventSource и WebWorker.

Модуль Nchan поддерживает отправку сообщений через Websocket, EventSource и Long-Polling. Я провел несколько тестов и решил использовать EventSource: сообщения могут быть только текстовыми и поток сообщений осуществляется только в одну сторону (от сервера). Это полностью решало поставленную задачу.

Сейчас работу интерфейса EventSource осуществляет в отдельном фоновом потоке WebWorker, независимо от активности вкладки. В этом же потоке организована примитивная очередь сообщений, чтобы ничего не потерялось. Очередь отправляется в основной поток приложения, который свою очередь производит необходимые перерисовки интерфейса, когда ему удобно и позволяет браузер.

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

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

Я всегда проверяю пакеты на наличие хуков preinstall, install и postinstall в поле “scripts” файла “package.json”. Кроме того, использую статические анализаторы пакетов, такие как retire, snyk и команду “audit” пакетного менеджера npm.

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

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

После того, как пакет прошел анализ, я обязательно фиксирую его версию. Если нужна другая версия — пакет проходит анализ заново. Да, это занимает время, но оно того стоит.

Пока бэкдоры ни разу не попадали к нам на продакшн.

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

За что я полюбил новый фронтенд и панель в целом

• Стало проще поддерживать код

Разработка заняла полгода. Теперь я скорее занимаюсь поддержкой панели, свой код не жмет и не натирает.

Клиенты могут быстро получать то, что запрашивали


Стало быстро и удобно добавлять новые функции, которые появились в бекенде: например, оплату для юридических лиц я добавил за 2 дня, снепшоты — за 1 день.

https://vdsina.ru

Завоз железа. Засетапили новую партию железа в лучшем дата-центре Москвы — DataPro. В данный момент доступны: Стандартные серверы vdsina.ru/pricing (CPU 3.2 GHz), Hi-CPU vdsina.ru/pricing/hi-cpu-vds (CPU 4.5 GHz), Выделенные серверы vdsina.ru/pricing/dedicated-server (CPU 4.2 GHz).



500(!!!) Мбит/сек скорость подключения КАЖДОГО сервера (VDS / VPS / cloud / instance / хуинстанс) клиента сверх-хостинга серверов на ЛЮБОМ ТАРИФЕ! Это невероятно, НО в стоимость тарифов входит защита от ddos-атак!