• Full disclosure: 0day vulnerability (backdoor) in firmware for Xiaongmai-based DVRs, NVRs and IP cameras
    +1
    Great work! The improvement was that you have decrypted challenge/responce required to open telnet sesion, was it?
    That's correct
    BTW, have you been interviewed by Cnews? They state that vulenrability built-in in HiSilicon CPUs (based on interview). Is it correct statement?
    I had interview with them. During the interview I've outlined vulnerability is restricted to DVR-specific software. Statement in article about processors is likely a misconception inferred from common trait of those devices.
  • Full disclosure: 0day vulnerability (backdoor) in firmware for Xiaongmai-based DVRs, NVRs and IP cameras
    0
    Received more info: first camera was ELP-1881-POE (http://www.elpcctv.com/)
  • Full disclosure: 0day vulnerability (backdoor) in firmware for Xiaongmai-based DVRs, NVRs and IP cameras
    0
    Did those Medias respect your original creation intention or ask your permission or authorization?
    This report is supposed to be widely disseminated, so I'm glad media works how it works.

    That particular article on The Register has many inaccuracies like lame analysis based on Shodan output and so on. However, article does what intended and notifies users: action required!
  • Full disclosure: 0day vulnerability (backdoor) in firmware for Xiaongmai-based DVRs, NVRs and IP cameras
    0
    Thanks you! I've added update to an article.
  • Full disclosure: 0day vulnerability (backdoor) in firmware for Xiaongmai-based DVRs, NVRs and IP cameras
    0
    Initial research performed against firmware for some Xiong Mai «HI3518C_50H10L»-based device. I hadn't physical access, only network one. I'll be provided with more specific information about that device tomorrow.

    Once vulnerability was discovered it was tested on a variety of other devices, without knowledge of their model or brand attribution. One of recent devices was branded as «H264dvr» and had «AHB7804R-MH-V2» string in it's ProductDefinition file.
  • Full disclosure: 0day vulnerability (backdoor) in firmware for Xiaongmai-based DVRs, NVRs and IP cameras
    0
    Yeah, article has dedicated section «Affected devices» which refers to previous research with pretty extensive list of vendors: https://github.com/tothi/pwn-hisilicon-dvr#summary (bottom of page). This is quite big list, so it's hard to enumerate all affected models.
  • Kali Linux 2020.1
    0
    Не путайте apt upgrade и apt update.
  • Kali Linux 2020.1
    0
    Чтобы apt install срабатывал, нужно сначала обновить списки пакетов командой apt update. В live-образе возможно уже присутствует «скачанный» список пакетов на самом диске или это делается автоматически.
  • Сравнение производительности инструментов обхода блокировок\VPN
    +2
    А я Вам объясню, как бывший сисадмин сисадмину.

    Я использую дома нечто похожее для всех соединений из браузера и firefox private network для проксирования соединений торрент-клиента. Как раз благодаря производительности названных здесь решений для меня не является проблемой что весь мой трафик идёт через зарубежный сервер. Для меня это решает массу проблем: часть из них связана с блокировками, часть потенциально-призрачных проблем связана с авторскими правами и торрентами, часть опасений связана информационной гигиеной и возможной непорядочностью сотрудников местного провайдера). Мне так комфортно, для меня из дома интернет выглядит как в 2009ом.

    Что касается использования туннелей и прокси на предприятиях — я с 2014го года не работал ни в одной конторе, которая этим бы не пользовалась, причём даже в странах, где на тот момент не было блокировок. Причины разные — кому-то нужно в WiFi нарисовать VLAN с IP-адресами из другой страны для того, чтобы банеры посмотреть, кому-то не нравится, когда GitHub или какая-то другая критичная инфраструктура отваливается по мановению чьей-то руки, кто-то просто никому не хочет свой трафик показывать. И да, действительно дело кончается тем, что один из маршрутизаторов офисной или продакшн сети в итоге подключен к забугорному серверу, именно так.
  • Сравнение производительности инструментов обхода блокировок\VPN
    +1
    Там ещё есть Cloudflare Warp, который по сути является туннелем Wireguard. Учитывая, что это бесплатно и есть скрипты для использования со стандартным клиентом Wireguard с компьютера, то почему бы и нет.
  • Сравнение производительности инструментов обхода блокировок\VPN
    0
    Я думаю, что почти всем критериям, которые Вы привели, соответствует Pooling TLS Wrapper. Разве что по удобству развёртывания можно поспорить.

    Вкратце, это SOCKS5 и Transparent proxy (то есть может быть установлен на роутере и заворачивать все коннекты), который форвардит каждое соединение в серверную часть отдельным TLS-коннектом, имея при этом пул подготовленных соединений для оборачивания новых коннектов. Серверная часть представляет из себя связку haproxy и danted (последний нужен только для SOCKS). Для авторизации клиента и сервера используются штатные механизмы TLS. Посторонние получают HTTP-заглушку.

    Я использую это в качестве основного решения для сёрфинга из браузера.
  • Сравнение производительности инструментов обхода блокировок\VPN
    0
    Действительно, качать торренты через свою недорогую виртуалочку у популярного хостера чревато как минимум абузами и возможностью отключения при непрекращающемся злоупотреблении. В остальном каких-то весомых проблем нет.

    Можно качать торренты через серверы Cloudflare, используя Firefox Private Network. Изначально бесплатная версия этого продукта — просто расширение для браузера, включающее прокси с авторизацией, завязанной на аккаунт Firefox. Однако, есть набор инструментов и сетевой враппер, позволяющий использовать его как обычный прокси для всех приложений. Скорость довольно неплохая, у меня получается весь физический канал (100Мб/с) использовать.
  • В Linux-дистрибутивах обнаружен баг. Он позволяет перехватывать VPN-соединения, но далеко не все
    0
    И адрес, и TCP-порты, и номера последовательностей TCP выясняются методом проб.
  • Президент подписал закон о повторном отказе передавать ФСБ ключи шифрования. Штрафы сильно вырастут
    +7
    Дело в том, что все компании всегда оставляют себе калитку. И у них эти ключи есть. И компания, если захочет, может расшифровать переписку пользователей. Или отдать ключи кому нибудь. Тайно или явно.
    Чем-то подкрепить это утверждение Вы, конечно же, не можете?
  • Прямой VPN-туннель между двумя компьютерами находящимися за NAT провайдеров с использованием UDP hole punching
    +1
    А зачем?

    Несмотря на то, что оверхед у пакетной маршрутизации меньше, чем у проксирования соединений, практическая скорость у прокси в условиях реальной сети выше по весьма банальной причине: TCP-ретрансмиты при потерях происходят независимо на двух разных участках — между прокси и клиентом и между прокси и целевым узлом.

    Если всё что требуется — это гонять весь трафик через удалённый сервер, то проксирование как технология — самое то. Ну а в качестве узла для доступа внутрь частной сети Windows попросту не самый удачный выбор именно с технологической точки зрения.
  • На одной асимптотике далеко не уедешь…
    +12
    Как вам такое?
    Да никак, в принципе. Нотация O-большое показывает исключительно характер роста времени выполнения при неограниченном росте выбранных переменных. Больше ничего. И для потребления памяти такая нотация тоже существует.

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

    действительно ли «O»  –  главный показатель скорости алгоритма?
    Если один алгоритм выигрывает у другого асимптотически, то, грубо говоря, это значит, что всегда найдётся такой объём входных данных, начиная с которого асимптотически выигрышный алгоритм выполняется быстрее. В отдельных случаях, когда практические объёмы невелики, использование алгоритма с лучшей асимптотикой может быть не выгодно. Но общая закономерность такова, и она не зависит от реальных коэффициентов. По этой причине действительно оценка О-большое является главным показателем скорости алгоритма. Никто никогда нигде не утверждал, что она является достаточной для сравнения времени работы всех частных случаев.
  • Прямой VPN-туннель между двумя компьютерами находящимися за NAT провайдеров с использованием UDP hole punching
    +2
    Отличная идея! Может быть стоит развить её дальше и пробивать NAT с использованием публичных STUN-серверов, как это делают, например, браузеры для использования WebRTC?
  • Прямой VPN-туннель между двумя компьютерами находящимися за NAT провайдеров с использованием UDP hole punching
    0
    Вы можете установить OpenSSH на системе с Windows установкой одной галочки в списке «компонентов», а потом использовать этот SSH-сервер как SOCKS-прокси с помощью либо обычного ssh-клиента, либо многопоточной быстродейственной альтернативы.
  • VPN в каждый дом или как приручить Дракона
    0
    Там в IPsec не совсем маршруты, а селекторы трафика. Они могут указывать и определённые протоколы и порты. Посмотрите «left|rightsubnet» тут.
  • VPN в каждый дом или как приручить Дракона
    0
    Можно просто найти адрес из свежего диапазона, который не загажен, поперебирав адреса на каком-нибудь Digital Ocean. Там попадаются диапазоны адресов, которые только недавно куплены у нормальных владельцев. У меня сейчас как раз такой, вроде бы капчи не докучают.

    Либо попробуйте Firefox Private Network, для ваших целей скорее всего хорошо подойдёт. Трафик идёт через серверы Cloudflare Warp (но не через wireguard, как в Warp, а обычный HTTP-прокси через TLS 1.3). В Firefox устанавливается простым расширением. С остальными браузерами и приложениями можно подружить, если сделать прокси, который получает и подставляет авторизационный токен в хедер авторизации прокси. У меня есть такое готовое решение.
  • VPN в каждый дом или как приручить Дракона
    0
    Именно на сетевом уровне это сделать довольно трудно, потому что при таком избирательном переключении каналов попытка установления соединения напрямую уже начата.

    Проще всего тогда в браузере всё через прокси пустить. Если сервер не слишком далеко, то это даже не будет заметно.

    Если Вы всё же хотите идти таким путём селективного проксирования, то можно адаптировать мою вариацию SOCKS прокси через SSH, чтобы по возможности она использовала прямое соединение. Для этого буквально будет достаточно попытаться установить соединение напрямую и при ошибке/таймауте уже перейти к установлению соединения через удалённый сервер.
  • VPN в каждый дом или как приручить Дракона
    0
    Да, это оно, block-outside-dns убёрет DNS-leak, если клиент эту опцию воспринимает.
  • VPN в каждый дом или как приручить Дракона
    0
    Нет, не проще. Смысл wireguard в том, что там роутинг связан с ключами. Кроме того он имеет массу других преимуществ: скорость, лёгкое переподключение, трудноузнаваемость трафика с точки зрения DPI. Ну а заводить все девайсы под одним аккаунтом — не совсем грамотно.
  • VPN в каждый дом или как приручить Дракона
    0
    Любой, на котором OpenWRT хорошо работает. Посмотреть на каких лучше можно на сайте openwrt в таблице.
  • VPN в каждый дом или как приручить Дракона
    –2
    Иначе несколько клиентов вместе работать не будут.
  • VPN в каждый дом или как приручить Дракона
    +6
    Те же самые VPN-провайдеры, которым Вы не доверяете, не позволяют себе сливать DNS-запросы пользователей гуглу.

    В случае с виндой даже если DNS-сервер будет установлен, но по каким-то причинам не успеет отверить вовремя, то винда может использовать DNS-серверы, назначенные на других интерфейсах (есть отличный комментарий со схемой пользователя chupasaurus про это). Для OpenVPN есть плагин с фиксом этого, но я не уверен, что такое же есть для wireguard. К слову, коммерческие VPN-сервисы имеют клиенты, подавляющие эту уязвимость.
  • VPN в каждый дом или как приручить Дракона
    +1
    Что-то я здесь не вижу, чтобы DNS пускался через VPN и на сервере был форвардер DNS. Проверьте вашу конфигурацию каким-нибудь тестом DNS leak. Например, этим.
  • DNS по HTTPS – половинчатое и неверное решение
    0
    Да, пардон.
  • DNS по HTTPS – половинчатое и неверное решение
    0
    На OpenWRT можно просто stubby установить, настроить его на DoH-сервер по своему предпочтению, а dnsmasq настроить на использование этого stubby.
  • DNS по HTTPS – половинчатое и неверное решение
    +8
    В форме сообщения об ошибке в тексте не работает кнопка «отправить», поэтому я напишу здесь. Вместо
    на самом деле не подтверждают ответы DNS
    должно быть
    на самом деле не проверяют ответы DNS

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

    Углублюсь в детали.

    DNSSEC

    Это технология, которая:
    1. Не нашла широкого распространения. Очень малая доля доменов имеют подпись.
    2. Предназначена для проверки подлинности, а не обеспечения конфиденциальности запросов. К задачам, решаемым DoH, не имеет никакого отношения.

    Из этого упоминания автор статьи попытался наскрести повод, чтобы бросить тень сомнения на реализации DoH, предлагаемые Google и Cloudflare:
    За DNS over HTTPS ратуют две крупные компании, Cloudflare и Mozilla, причём последняя даже выпустила миленький комикс, где пытается объяснить схему DoH. Неудивительно, что они совершенно не упоминают DNSSEC (несмотря на то, что её называют «критически важной» в RFC 8484), и вместо этого предлагают нечто под названием Trusted Recursive Resolver (TRR), что, по сути, представляет собой совет «использовать доверенный DNS-сервер», под которым Mozilla подразумевает Cloudflare.

    Тем не менее, рекурсивные резолверы Google и CF валидируют DNSSEC. Вместе с этим, ответы DNSSEC может валидировать и DNS-форвардер на офисном или домашнем шлюзе. Стоит заметить, что технология DNSSEC имеет свои проблемы внедрения и одно из требований для полноценного обеспечения гарантий, которые может предоставить эта технология, — это обеспечение безопасного канала между DNS-клиентом и рекурсором, проверяющим подлинность DNSSEC. DoH и DoT в этом случае абсолютно уместны и делают внедрение DNSSEC практичным.

    Проблема с DoH

    В этой части я ожидал увидеть технические проблемы протокола, однако увидел только три полуправдивых утверждения, не доказывающих основной тезис. По порядку:
    1. Аргумент о том, что операторы сети теряют контроль над сетью и апеллирование к мнению Пола Викси. Если проследовать по ссылке, то можно заметить, что его в первую очередь не устраивает формат транспорта внутри HTTPS и вместо этого он рекомендует использовать DoT. Что же касается контроля над трафиком пользователя, то это соответствует изначальной цели протокола. Более того: в корпоративной среде, использующей MITM-фильтрацию и собственные CA-сертификаты для неё, задача фильтрации остаётся решаемой.
    2. Этот тезис раскрывается дальше про передачу запросов через HTTPS заявлено, что это «кошмар для встроенных приложений, а также несовместимо практически со всеми существующими типами оборудования». Это заявление не выдерживает критики, так как везде DNS обычно реализован программно, а встраиваемое оборудование может получать преимущество от DoH/DoT, настренного для всей сети. Кроме этого, в следущем абзаце зачем-то упомянут VPN и TOR, которые уж точно не представлены в массе (особенно TOR) ни на каких встраиваемых устройствах.
    3. Далее идёт утверждение о том, что DoT более зрелый и имеет большее распространение. Однако, DoH труднее заблокировать и он может получать преимущества в сетевом обмене, используя HTTP/2 Server Push.

    Шифрование не препятствует слежке

    Такое можно сказать о любом шифрованном оверлее через сеть: выходная точка видит нешифрованный трафик. Однако, это существенно сокращает возможности для слежки и в конечном итоге может определить исход доступности какого-то ресурса в условиях сетевой фильтрации. Что же касается конфиденциальности самих подключений к ресурсам — протоколы конфиденциального DNS не берутся решать эту задачу, но могут служить ценными дополнениям к другим способам обеспечения конфиденциальности.
  • Как запускается сервер
    +9
    в остальном изменений практически нет.

    У EFI с обычным загрузчиком мало общего. Помимо того, о чём Вы сказали:

    1. Устанавливает 64битный режим для 64битных EFI-приложений. Это многое значит: EFI-приложению не принадлежит вся память, загрузчик должен запрашивать её аллокацию у фирмвари так же, как у операционки обычное приложение запрашивает память. Но после вызова ExitBootServices вся память переходит во владение приложени.
    2. Предоставляет унифицированные таблицы с данными о системе и сервисами (в т.ч. драйверами устройств, ватчдогами и т. д.).
    3. Поддерживает выход из загрузчика и передачу управления обратно фирмвари (Legacy BIOS — нет).
    4. Проверка подписи кода (Secure Boot — must have для безопасной серверной платформы).


    Схема Legacy BIOS — нагромождение рудиментов, которому уже не место в современных системах по множеству причин. Если написать статью про устройство UEFI — это был бы редкий и качественный материал. А уж если ещё и снабдить статью примером простенького Hello World приложения UEFI, то, наверное, это будет вообще уникально.
  • Telegram наносит ответный удар DPI и блокировкам — Fake TLS
    0
    С остальным-то я в целом согласен.

    Гораздо правильнее было бы иметь полноценный мультиплексор, который устанавливает полноценную TLS-сессию на «сайт-с-котами.тк» и затем уже внутри неё перенаправляет трафик либо на МТПрото, либо на вебсервер, руководствуясь каким-то секретным ключом.

    Именно так я и сделал в своём решении. Серверная часть представляет собой haproxy, который разруливает полезную нагрузку для авторизованных клиентов и подключает неавторизованных клиентов на фэйковый HTTP-сервер.
  • Совместное сетевое использование криптографического токена пользователями на базе usbip
    0
    Интересно, токен хотя бы ввода пин-кода требует? Всё выглядит так, как будто секретный ключ просто расшарили без пароля в локалке, похоронив весь смысл смарт-карт.
  • Решение Veeam PN и его новые возможности в версии 2.0
    0
    Благодарю Вас!
  • Firefox и Chrome будут шифровать DNS-запросы и обходить цензуру
    0
    Да, вполне. Я несколько сервисов запускал и на 400-мегагерцовом MIPS-процессоре роутера TP-Link Archer C50.
  • Firefox и Chrome будут шифровать DNS-запросы и обходить цензуру
    0
    Да, можно. Малина работает как обычная машина на линуксе, у неё нет никаких особых ограничений.
  • Firefox и Chrome будут шифровать DNS-запросы и обходить цензуру
    0
    Да, у меня как раз так сделано.
  • Решение Veeam PN и его новые возможности в версии 2.0
    0
    Кстати, в рассылке WireGuard поступали предложения изменить протокол так, чтобы DPI системам сложнее было обнаруживать и классифицировать траффик WG, но автор ни в какую не соглашается. Там же в рассылке упоминалось, что великий китайский файрволл уже умеет детектировать и блокировать траффик WG.
    А есть где прочитать? Для меня это имеет некоторое значение.

    В отношении DPI, наверное, самая выгодная стратегия — быть неотличимым от HTTPS и прочих виды «легетимного» шифрованного трафика. Тем более что в самом TLS уже есть всё неоходимое для шифрования.
  • Решение Veeam PN и его новые возможности в версии 2.0
    0
    При этом о поддержкe WireGuard и предоставлении сервисов на его основе уже заявило большинство крупнейших VPN провайдеров. А Cloudflare, например, вообще свою реализацию WireGuard протокола на Rust написали.

    Да, я сам использовал в прошлом AzireVPN потому, что они начали поддерживать wireguard. Однако, вот что:

    1. Поддержку wireguard выкатили на данный момент только, наоборот, самые мелкие провайдеры. Они в первую очередь заинтересованы в уникальном торговом предложении, а не в реальной безопасности. Поэтому AzireVPN наряду с wireguard предлагает и SOCKS5 без шифрования, а, например, vpn.ac предлагает PPTP (с MPPE на шифре RC4) и L2TP/IPsec с PSK для аутентификации сервера, который знают все клиенты. Wireguard на слуху, вот они и подсуетились. А старые протоколы поддерживают потому что и на них есть спрос со стороны владельцев старого оборудования. То есть, это из-за спроса, а не из-за безопасности.
    2. Вероятнее всего, CF пилил эту реализацию для своего Cloudflare Warp, который недавно запустился. Это VPN для мобильных и wireguard туда отлично вписывается потому, что прочно держит соединение, тут лучше чем wireguard и правда не придумать. Кроме того CF ещё имеет кое-какие амбиции по борьбе с цензурой, а у wireguard обфусцированный протокол.
    Множество, только абсолютное большинство из них уже устарело. Из тех шифров, которые удовлетворяют современным требованиям я бы назвал только AES-128/192/256-CBC. И то, CBC режим подвержен уязвимостям.

    Поддержка современных режимов шифрования (e.g. AES-256-GCM) и perfect forward secrecy (e.g. ECDHE) появилась только в версии 2.4 и не поддерживается в более старых версиях, которых до сих пор полно на просторах сети. В общем и целом, OpenVPN гораздо проще настроить неправильно, с использованием небезопасной криптографии.
    Так помимо блочного шифра транспортного канала, с которым проблем и так особо нет, в шифронабор входят вариации согласования ключей по Диффи-Хеллману, псевдослучайная функция и асимметричные ключи подписи, к которым обычно больше вопросов. Вот в вайргарде оно всё прибито гвоздями, в OpenVPN и других хотя бы пара рабочих вариантов есть. И по той причине, что в протоколе wireguard применяется обфускация точек эллиптической кривой, которая специфична для этой конкретной кривой, по-другому не будет, там можно весь шифронабор только разом сменить.
    Для WireGuard тоже можно придумать реализацию PKI, благо клиенты и так аутентифицируются по публичным/приватным ключам, которые суть есть Curve25519, так что можно раздавать клиентам те же ECC SSL сертификаты. То, что поддержка PKI не зашита в протокол WireGuard по-моему только плюс. Это, конечно, может быть минусом для корпоративного сектора, но думаю и там в скором времени найдётся решение.
    Общего решения, сохраняющего свойства wireguard, не найдётся точно, потому что обнажение публичных ключей идёт вразрез с целями протокола Noise. Wireguard использует паттерн IK протокола Noise, и для получения гарантий, которые он предоставляет, инициатор должен знать публичный ключ ответчика заблаговременно.

    В тот же OpenVPN PKI тоже не прямо жёстко зашита — можно использовать статический ключ. Кстати тогда возникает вопрос про вайргард: если мне ещё и ключи нужно так скрупулёзно распространять, зачем мне тогда DH встроенный в wireguard? Чего б тогда сразу статический ключ не назначать, раз оно без внешних костылей или ручной работы не работает? В своей презентации они такой способ, кстати, и рекомендуют, как возможный способ достижения постквантового шифрования. Но в дикой природе реализации wireguard, поддерживающие статический ключ, мне не попадались пока.
  • Решение Veeam PN и его новые возможности в версии 2.0
    0
    Одной из причин перехода с OpenVPN на WireGuard стала улучшенная безопасность в WireGuard.
    Я не большой фанат OpenVPN, но ситуация скорее обратная.
    • OpenVPN проходил аудит безопасности, а Wireguard нет.
    • OpenVPN поддерживает множество шифров и не является заложником какого-то одного в случае, если в нём будут найдены фатальные проблемы. Wireguard в текущий момент времени поддерживает ровно один комплект криптопримитивов.
    • Wireguard полагается на статические ключи, которые должны быть предварительно распространены и сконфигурированы на узлах, а значит требует какого-то внешнего решения для закрытия этой проблемы, которое так же нуждается в аудите. OpenVPN может полагаться на стандартную PKI.

    Приведённое Вами утверждение ничем не подкреплено. Кроме этого, по информации с официального сайта ни одного стабильного релиза так и не было:
    WireGuard is currently working toward a stable 1.0 release. Current snapshots are generally versioned «0.0.YYYYMMDD» or «0.0.V», but these should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software). This text will be removed after a thorough audit.
    То есть авторы не пока не рассматривают его как production ready.

    WireGuard задействует крипто-версионирование для предупреждения крипто-атак.
    Мне попадалось это утверждение в статьях о Wireguard, но в самой спецификации нет вообще ничего про версию. Надо понимать, что это такая обтекаемая форма утверждения «в случае чего просто поменяем всё под корень».

    Говоря о производительности самого Wireguard, следует заметить что рекордные скорости он достигает благодаря размещению модулем прямо в ядре Linux. На всех остальных платформах, где Wireguard реализован в юзерспейсе, скорость будет сопоставимая с OpenVPN и будет проигрывать решениям, которые реализованы драйвером в ядре (например, IKEv2 IPsec).

    В новейшей версии решения Veeam PN мы перешли от использования OpenVPN к WireGuard, поскольку именно WireGuard постепенно становится новым стандартом в индустрии VPN-технологий.
    Wireguard модный, перспективный, но пока он не конкурент даже IPsec по причине неполного соответствия функционалу обычных VPN-серверов и отсутствия зрелости.