WireGuard

Сегодня Роскомнадзор в очередной раз забанил подсеть Амазона (или хостер пофиксил "проблему"), в общем пришлось заворачивать всё в VPN, что привело к весьма печальной скорости работы сервера, т.к. VPN был далеко.

Решил поднять его поближе, в Azure, а т.к. в нём весьма грустно с фаирволлом, решил попробовать новый хипстерский VPN под названием WireGuard. Правда потом оказалось, что VPN всё-таки можно было попробовать устроить, но у меня оказалась неправильная виртуалка, в которой всё делается через жопу. Надо было создавать другую и гуглить как в азуровом фаирволле сделать проброс чего-то отличного от TCP и UDP.

В общем, WireGuard позиционируется как простой и правильный VPN, без кучи опций и настроек. Просто работает. И в целом да, только оказалось, что это нифига не VPN в привычном понимании (хотя технически да, и виртуальная, и частная, и сеть).

Что хочется получить от VPN:

• Стабильной работы (у всех существующих решений всё плохо)
• Простой конфигурации (PPTP рулит)
• Безопасности (SSTP, L2TP/IPSec, OpenVPN)
• Выдачи IP адресов (все умеют)
• Выдачи маршрутов (у всех очень грустно)
• Выдачи доп. настроек (ещё хуже)

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

И вот тут вылезает WireGuard. Что же он делает?

• Создаёт отдельный сетевой интерфейс
• На него руками необходимо назначить IP (wat?)
• Клиент и сервер в целом не разделяются (привет IPSec), они равнозначные пиры (peers), но в целом можно использовать концепцию клиент-сервер, просто сделав определённые настройки
• Если нужно устроить VPN, то можно сделать это ручками через iptables и маскарад
• Каждый пир определяется парой ключей (публичным и приватным), так что заранее на сервере никого не добавить (можно нагенерить ключей, но как-то коряво выглядит)
• По умолчанию роуты связаны со списком разрешённых IP'шников, т.е. делаются на клиенте, проброса нет

Так что получается, что это какой-то упрощённый IPSec, но с отдельным интерфейсом и IP-адресом (без добавления, думаю можно извернуться, но уже не очень дефолтная конфигурация). Т.е. использовать его как VPN — можно, но очень фигово (хотя если для себя делаете, то вполне норм). И с VPN'ами по-прежнему всё тухло, а WireGuard оказался каким-то странным созданием.

Но с другой стороны, настраивается он элементарно и начинает сразу же работать. Это ему плюс. Только имейте в виду, что конфигурация через wg-quick и ip работает по-разному, через ip можно сделать гораздо больше и и точнее.

Хранение данных в памяти

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

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

Почему не стоит полагаться на кеш SQL-сервера?

Потому что он построен именно на модели кеша для данных, и в него можно попадать или не попадать. Конечно, в MS SQL есть OLTP таблицы, которые хранятся в памяти, но они больше для очень активных данных, и вообще это на уровне SQL, причём MS SQL. А без них — используются стандартные алгоритмы для поиска, оптимизированные для данных, находящихся на диске, как результат, необходимый кеш для очень 100% попадания в память многократно превышает размер реальных данных.

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

Что это даёт?

• Резко упрощается внешняя логика пользователя. Во многих случаях можно отказаться от джойнов, если нет дополнительной фильтрации. Например, классический джойн с данных с пользователем (например, вывести автора данных) можно заменить на выборку данных и доставание всех пользователей по ID. Это очёнь дешёво
• Можно использовать очень тупые алгоритмы, и это всё равно будет очень быстро. Фуллскан 10000 записей почти незаметная вещь, а если надо будет ещё быстрее — всегда можно будет прикрутить "индекс" в виде словарика
• Можно избавиться от отдельного кеша для тяжёлых данных, ибо и так всё в памяти
• Тупо быстрее из-за отсутствия запросов к внешнему SQL-серверу
• Легко хранить данные, которые тяжело забирать из SQL (объект с зависимыми детишками, слабо-структурированные документы, JSON/XML поля)
• При этом, если приложение написано с использованием LINQ, то местами можно вообще не заметить разницы между базой и памятью (если грамотно спланировать архитектуру приложения)

 А в память влезет?

А вот это как раз главный вопрос, который всех останавливает и которого все боятся. И из-за этого, всё так и останавливается на уровне идей. Но давайте прикинем необходимое количество памяти.

• База данных в 20ГБ содержит где-то 20ГБ данных (логично, да?), в памяти это будет занимать примерно столько же. Найти подходящий сервер — не так уж и сложно. Естественно, базы в 100МБ вообще влезут в память без проблем
• Очень часто в "больших" базах большой объём занимают всякие полумёртвые данные — журналы, результаты импорта, файлы, подписанные данные, акксесс логи... Эти данные нужны очень редко, их можно не хранить в памяти, тем самым кардинально снизив объём "реальных" данных
• Многие данные нужны только в небольшом количестве. Например, у вас есть 10000 пользователей в системе, но активны только 1000, тут можно использовать какой-нить LRU кеш и не держать в памяти все объекты, а только активные. Опять же, очень сокращает необходимый объём памяти
• Ну и для реально огромных баз данных можно уж держать в памяти только специально выделенные объекты (например, справочники). Хотя, с такими объёмами у вас будет проблем побольше чем просто держать в памяти

Как реализовать?

Поскольку я ещё не делал это в полном виде, то могу только предположить следующие варианты:

• Собственный кеш класса, ратающего с сущностью (e.g. UserManager), он сам решает, что и как кешировать. Проблемы в куче аналогичного кода в разных классах и сложность с инвалидацией. Плюсы: в каждом конкретном случае можно использовать самые эффективные варианты
• Мемоизация и автомемоизация методов. Плюсы: очень упрощается код, минусы: сложно инвалидировать и оптимально использовать данные. 
• Обёртка над ORM (или использование встроенных средств типа Second Level Cache), которая сделает всё сама. Проблемы: сложно в реализации и конфигурировании. Плюсы: полная прозрачность в использовании со стороны кода

Краткий итог

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

Итоги моего 2017 года

Решил в этом году повторить пост относительно прошлого, ибо оказалось даже для меня полезным и интересным посмотреть, что было в прошлом и сравнить, что стало (хотя уже было) в этом. Так что, нашёл время (единственный свободный день под конец года оказался, хотя сейчас пытаюсь восстановить угробленные виндой данные с диска в 3Тб), и решил написать, что же произошло технического в этом году.

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

А в этом активно и вплотную занялся .NET Core под Linux, фактически все новые проекты теперь там и живут, и живут весьма неплохо. На работе кроме всякой мелочи был сделан очень крутой проект. Он. конечно выглядит просто и банально, но внутри там очень всё круто, микросервисно, распредёлённо и кешированно. При этом, пока не замучали новыми фичами, он умудрялся жить на мелких виртуалках, используя по максимуму всё, что они предоставляли. Но в конце-концов, один проект превратился в два, с общей и своей частью, я сдался и развёл проект на 3 сервера и разрешил жрать память (хотя слишком разрешил 16 Гигов, съеденных из-за баги доставили много радости в поиске бага).

В остальном, год был похож на прошлый. Был хакатон, но участвовал я один, в итоге "почётное" третьё место. И ещё не внедрено. Продолжаю пилить на гитхабе свой клонятор, Crc32 (теперь ещё быстрее), и архиватор, который уже помаленьку использую в бою и вижу, что у него есть очень интересные фичи. Также нарисовал свой аналог IPSec под названием AutoTunnel, получилось интересно, но надо бы чуть допилить, ибо склейка фрагментированных UDP пакетов со стороны Windows — это боль.

С нетехнической стороны — год отметился путешествиями: Баку, Минск, Кострома, Мюнхен, Тбилиси, Амстердам, Прага... Посетил кучу мест, получил много впечатлений и не собираюсь останавливаться на достигнутом!

К сожалению, со всей этой беготнёй, забыл про новогоднее настроение, но у меня есть ещё 2 дня его найти, буду упорно стараться. Ну а вам его тоже желаю, надеюсь, что оно у вас уже есть и вы готовитесь к самому весёлому празднику, Новому Году.

С Наступающим!

Ненавистный .NET

Последнее время совсем не пишу в блог, как-то нет подходящих тем, могу только сообщить, что такой ненависти к Microsoft я давно не испытывал. Попытка поработать с .NET Core 2.0 сразу же привела к идиотским ошибкам, типа 2 entry point у приложения. При этом второй генерируется самостоятельно (!), другими словами, у Microsoft новые отличнейшие идеи, как всё должно работать по их мнению, вместо того, чтобы просто сделать рабочий продукт.

Если кончится мат и появятся слова, постараюсь написать что-то более членораздельное. Но, блин, у Microsoft был отличнейший .NET, приложения на котором просто работали... Теперь не так, они могут падать по совершенно различным причинам, а Dll Hell уже перешёл все границы. Ну, как, как можно так портить жизнь разработчикам за их же деньги...

Версионирование .NET Core

Когда-то писал про .NET Core и обещал написать больше, но было лениво, так что руки не дошли.

Сейчас просто для понимания бреда, который творится с версионированием краткое описание разных версий. Это может быть полезно, т.к. вышел .NET Core 2.0 и .NET Standard 2.0, и версии слились в экстазе. Но на самом деле они разные, и скоро разъедутся и будут опять портить всем жизнь. Итак, временно забудем про существование 2.0, и вспомним, что есть:

• Вы собрались писать под .NET Core, соответственно выбираете, какую версию хотите, вы можете выбрать версию 1.0 (на момент написания 1.0.7) или 1.1 (на момент написания 1.1.4), при этом, особой разницы в этом нет. 
• На самом деле, вы можете выбрать рантайм или сдк Логично, что для разработки нужен SDK, для версии рантайма 1.0.7, сдк имеет версию 1.1.4 (т.е. рантайм разрабатывается и старый и новый одновременно, сдк только новый)
• После этого, вы можете решить, что использовать, .NET Standard или .NET Core. Для библиотек лучше использовать Standard, у него версии: 1.0,1.1,1.2,1.3,1.4,1.5,1.6, для запускаемых файлов лучше Core, у него версии 1.0 и 1.1
• Впрочем, вы можете писать библиотеки на Core, а экзешники на Standard, в этом не очень много смысла, но в целом он есть
• Версии Standard для удобства используют стандартную библиотеку NETStandard.Library, она бывает версий 1.6.0 и 1.6.1
• В этой библиотеке есть стандартные библиотеки, которые любят называться как большие и иметь версию 4.3.0 (большие имеют версию 4.0.0). Впрочем, иногда бывают и 4.2.0 и 4.1.0, и всякие разные

Т.е. приложение мод .NET Core 1.0 может запускаться в рантайме 1.1.4, иметь зависимость на библиотеку .NET Standard 1.3, которая использует библиотеку NETStandard.Library 1.6.1 и это всё будет замечательно работать! Главное надо понять, что это просто разные версии разных библиотек. 

Сейчас вышел .NET Standard 2.0, и всё стало совсем просто: приложение под .NET Core 2.0 запускается в рантайме 2.0, имеет зависимость на библиотеку .NET Standard 2.0, которая использует библиотеку NETStandard.Library 2.0.0. К сожалению, скоро все эти версии опять разъедутся в разные стороны, и опять будет путаница. Но. надеюсь, вы теперь будете во все оружии.

PS: Сейчас слушаю про version hell в .NET Core 2.0, и становится страшно, там добавили совместимости из-за которой много всего развалилось, несмотря на обещанную совместимость.

Подлые порты

Я тут настроил логгирование входящих запросов из интернета на мой комп, конечно же, меня периодически (раз в час) сканируют. Решил просто поделиться списком портов, которые интересуют "хакеров".  Зачем? Просто для информации, на какие порты обращать внимание, и на какие порты не стоит вешать ваши сервисы, если они настолько популярны, что их ломают, то и ваши сервисы могут попасть под раздачу или флуд.

Собственно, список:

7
9
13
21
22
23
25
26
37
53
79
80
81
88
106
110
111
113
119
143
144
179
199
389
427
443
444
465
513
514
515
543
544
548
554
587
631
646
873
990
993
995
1025
1026
1027
1028
1029
1110
1433
1720
1723
1755
1900
2000
2001
2049
2121
2717
3000
3128
3306
3389
3986
4899
5000
5009
5051
5060
5101
5190
5357
5432
5631
5666
5800
5900
6000
6001
6646
7070
8000
8008
8009
8080
8081
8443
8888
9100
9999
10000
32768
49152
49153
49154
49155
49156
49157

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

Какой тип VPN лучше

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

PPTP

Классический протокол, работает везде. На всём что шевелится. Очень быстрый (с ним только IPSec может соперничать при определённых условиях). Но есть один недостаток — дырявый. Стандартный MSCHAPv2 позволяет выяснить пароль, если перехватить сессию. Но, судя по всему, проблема только в случае MITM. Т.е., если не считаете, что ваш трафик перехватывают, то жить вроде бы можно. Есть ещё протоколы вида EAP, но с их поддержкой всё достаточно грустно.

Второй недостаток — использование в качестве транспорта протокола GRE (тоже самое что TCP, UDP или ICMP, только GRE). Иногда режется.

В общем, по общему мнению, использовать небезопасно, но быстр

IPSec

Не совсем VPN, а нечто очень клёвое и могучее, которое может шифровать или один порт между двумя компьютерами, или связывать целые подсети безопасным образом. Очень хорошо поддерживается аппартное шифрование, и сам весь шифрованный, может хоть по сертификатам, хоть по PSK ходить, работает в винде на низком уровне, в общем, чудо а не протокол. Есть только пара жирных минусов: первоначальная настройка может быть весьма муторной (с перебиранием галочек, и чтением логов), неосторожное действие может зарубить железяку (будет считать, что трафик к ней должен идти через IPSec, который не настроен), ну и настройка этого через NAT — могучий квест, для настоящих джедаев.

В общем, по жизни рекомендую связывать удалённые компьютеры с фиксированными IP в безопасную псевдо-локальную сеть. Тут он волшебен. Остальное — на любителя.

Ходит через UDP, EH и ESP протоколы, что очень хорошо для транспорта, но мутновато для фаривола. с NAT'ом добавляется UDP 4500, и куча мути.

L2TP/IPSec

Немного дурацкое название связано с тем, что сам туннель нешифрованный, соответственно поднимается туннель поверх IPSec, что приводит по мнению многих к двойной инкапсуляции и приличному оверхеду. Но т.к. IPSec сам по себе хорош, не так уж и плохо. Живьём попробовать не удалось, уж очень большой квест по настройке. Предпочитаю голый IPSec. В общем, как вы понимаете, мне не очень нравится этот туннель, но если вам кто-то его настроили он работает, то будет весьма безопасный туннель.
Ходит через UDP 1701, EH и ESP протоколы, EH не обязателен.

SSTP

Как программисту, мне очень нравится этот туннель. Ибо это тупой SSL-стрим (по умолчанию на 443-ем порту), в который всё заворачивается. Т.е. с криптографией всё нормально TLS1.2, все плюшки. Проверка сертификатов сервера, возможно клиента. Работает дубово и стабильно. Но один маленький нюанс: хорошо работает только на винде начиная с Висты и более или менее на Микротиках. Под линухом кое-как, под андроидом из коробки ничего нет, ну и в целом не очень распространён.

Тем не менее, если есть возможность его использовать со стороны системы — будет работать. 

Утверждается, что протокол закрытый, поэтому могут быть дыры, но снаружи это чистый SSL-стрим (не отличить от обычного обращения к сайту, кроме объёма данных), так что все правила безопасности соответствуют https.

Ещё один недостаток, кроме ограниченной поддержки — TCP канал для тоннеля. В чём проблема? В плохой сети. Ибо TCP-пакеты могут теряться и запрашиваться повторно. Тут получается ситуация TCP over TCP, что при потере пакетов верхнего уровня приводит к куче проблем нижнего. Т.е. два уровня начинают заниматься попытками перепосылки пакетов, что сильно проваливает скорость. Однако, при хорошей сети — всё отлично.

OpenVPN

Последний вариант, о котором я хочу рассказать, но не самый плохой. Это отдельный OpenSource клиент подо всё что шевелится, который позволяет сделать всё что угодно. Хоть примешаться к существующему SSL-трафику на 443-ем порту сервера. В общем, есть всё. Куча алгоритмов, куча вариантов. Минусов только два: нужно ставить отдельно и слегка мутновато настраивать. Если справитесь, то всё будет хорошо, хотя пользователям придётся писать развёрнутую инструкцию.

Ну и по-возможности, следует настроить его на использование UDP, а не TCP, чтобы не было проблем, аналогичных SSTP. По скорости примерно соответствует SSTP.

Скорость

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

• PPTP — самый быстрый. Очень и очень быстрый
• L2TP/IPsec — чуть медленнее (протоколы серьёзныее)
• SSTP — сильно медленнее
• OpenVPN — примерно соответствует SSTP, но чуть медленнее (проверял только TCP вариант, думаю UDP будет гораздо быстрее)

Итоги

На самом деле, выбор весьма сложен. Старые протколы или сложные или дырявые, но поддерживаются везде и максимально быстро. Новые стараются сделать удобнее, но с поддержкой грустнее. Я пока не выбрал, что лучше, но думаю про SSTP, когда всё хорошо и PPTP, когда плохо с качеством и скоростью, но очень надо. При хорошей подготовке, возможно лучшим будет всё-таки IPSec, ну а хитрый OpenVPN можно настроить как нравится.