Сервис GlobalCheck cообщил, что в воскресенье пользователи стали жаловаться на проблемы в некоторых регионах страны с доступностью к корпоративным VPN, работающим по протоколам IPsec и IKEv2.

1 июня 2022 года сервис Proton VPN сообщил о проблемах с доступом у российских пользователей. Компания не блокировала соединения со своей стороны.

[обновление публикации на 2 июня]: Роскомнадзор ответил на сообщения о блокировке сервиса Proton VPN. В ведомстве заявили, что средства обхода блокировок, включая Proton VPN, признаны угрозой в РФ.

2 июня 2022 года Роскомнадзор ответил на сообщения о блокировке сервиса Proton VPN. В ведомстве заявили, что средства обхода блокировок признаны угрозой в РФ и подтвердили, что в рамках закона о «суверенном» рунете ведется работа по блокировке VPN-сервисов, в том числе Proton VPN, помогающих обходить блокировки признанного в РФ запрещенным контента.

Вечером 2 июня «Роскомсвобода» уточнила, как в РФ со стороны оборудования надзорного ведомства блокируются серверы Proton VPN.

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

«Ростелеком» представил операторам связи РФ, операторам ПД и госкомпаниям сервис шифрования каналов под названием «ГОСТ VPN» для построения и эксплуатации защищённых сетей. Решение «ГОСТ VPN» позволяет организовать защищённое взаимодействие между географически распределёнными объектами в любых регионах страны, а его реализация выполнена согласно требованиям российского законодательства по защите данных.

11 декабря 2022 года VPN-сервис Surfshark перестал работать в России. Не работает десктопное и мобильное приложение (Android, iOS) и расширение к браузеру Chrome. Пользователи жалуются, что с оплаченной подпиской они не могут подключиться ни к одной из представленных в приложении стран. В техподдержке сервиса не могут ответить по поводу остановки работы в РФ.

Работает, если сделать так, как написано на этой странице (через OpenVPN).

12 декабря Роскомнадзор прокомментировал СМИ ситуацию с блокировкой VPN-сервиса Surfshark. Ведомство прямо не подтвердило, что ввело ограничения, но напомнило, что в РФ под запретом все VPN-сервисы, которые не подключены к Федеральной государственной информационной системе (ФГИС), содержащей реестр запрещённой в РФ информации.

18 декабря 2022 года глава Минцифры Максут Шадаев в ходе заседания комитета Госдумы по информполитике заявил, что VPN-сервисы в России «не приживаются», а доля пользователей VPN-сервисами среди россиян уже некоторое время не растёт. После резкого всплеска летом этот параметр упал до мартовского-апрельского уровня.

Роскомнадзор предложил использовать системы ТСПУ, установленные у провайдеров, для блокировки сервисов анонимизации, например сервисов по предоставлению виртуальных номеров для регистрации в соцсетях, мессенджерах, включая Fragment от Telegram, и, вероятно, ChatGPT, хотя в последнем случае российским пользователям помимо оформления анонимного номера нужно использовать VPN-сервисы, большинство из которых РКН уже блокирует через ТСПУ. Проект постановления.

Роскомнадзор предупредил о рисках использования VPN-сервисов. Ведомство сделало заявление после выпуска общественной организацией РОЦИТ («Региональный общественный центр интернет-технологий») нескольких роликов в формате социальной рекламы про граждан, которые пострадали от утечек персональных данных, якобы доверясь VPN-сервисам.

29 октября 2007 года умер 純一郎萩野, также известный как Itojun. Ему было 37. Дзюнъитиро активно участвовал в таких проектах как FreeBSD, NetBSD и OpenBSD. Он внёс существенный вклад в реализацию поддержки IPv6, IPsec, а также разнообразных сетевых протоколов. Он же был одним из основных разработчиков KAME.



R.I.P.
その世界で嬉しいになってください

Начнем с того, что в манах, где рекомендуется к установке Racoon упоминается racoon1, который в FreeBSD 7.x теперь называется ipsec-toos.

поэтому

portinstall ipsec-tools

не забываем скомпилировать ядро с поддержкой ipsec:

device crypto

option IPSEC

внимание, с 7.x IPSEC_ESP указывать не нужно!

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

Может быть будет полезен кому-то кроме меня:

Пакет Inside−to−Outside

1. if IPSec then check input access list
2. decryption − for CET (Cisco EncryptionTechnology) or IPSec
3. check input access list
4. check input rate limits
5. input accounting
6. policy routing
7. routing
8. redirect to web cache
9. NAT inside to outside (local to global translation)
10. crypto (check map and mark for encryption)
11. check output access list
12. inspect (Context−based Access Control (CBAC))
13. TCP intercept
14. encryption
15. queueing

Пакет Outside−to−Inside

1. if IPSec then check input access list
2. decryption − for CET or IPSec
3. check input access list
4. check input rate limits
5. input accounting
6. NAT outside to inside (global to local translation)
7. policy routing
8. routing
9. redirect to web cache
10. crypto (check map and mark for encryption)
11. check output access list
12. inspect CBAC
13. TCP intercept
14. encryption
15. queueing

Извлечено из Cisco Document ID: 6209

Draytek — относительно новая в российском сегменте компания, занимающая нишу недорогих компактных роутеров All-in-one. Здесь и здесь можно почитать обзор двух, наиболее популярных моделей роутеров этой компании серий 2820 и 2910 (которые, кстати, позиционируются как «security firewall»). Среди остальных преимуществ данных роутеров, наиболее вкусным является аппаратная поддержка шифрования (AES/DES/3DES) и аутентификации (MD5, SHA-1), так что можно, вроде бы, настроить VPN между точками и спать спокойно. Но не всё так просто, как кажется.

Ведущий разработчик OpenBSD, канадский программист и хакер Тэо де Раадт (Theo de Raadt) восстановил события десятилетней давности, когда создавался стек протоколов шифрования IPSec. Он называет имена двух основных разработчиков стека (как сейчас выяснилось, они выполняли заказы для ФБР) и пишет, что написанный ими код до сих пор используется в ключевых модулях системы и не только в IPSec.

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

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

Хочу рассказать об одном из своих первых опытов общения с FreeBSD и настройке IPSEC для связи с D-Link DI-804HV и проблемах, которые возникли при этом. Надеюсь, это поможет народу не наступать на мои грабли.

Так получилось, что когда я пришел на новую работу, то в мою сферу ответственности попал сервер с FreeBSD, который был шлюзом в Интернет — на нем крутился почтовый сервер и файерволл. По предыдущей работе был опыт работы с Линуксами, но FreeBSD до этого в глаза не видел. И вот одна из первых задач на новой работе была настроить соединение с удаленным офисом через инет, для этого туда прикупили железку D-Link DI-804HV. Решено было соединить это все хозяйство через IPSEC.

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

Вводная и условия задачи

У нас есть Amazon VPC с несколькими подсетями.
Внутри VPC разбита на несколько подсетей.
Возьмем две из них.
В первой (посеть 10.0.0.0/24), назовоем ее net1, маршрутизацию наружу осуществляет родной Амазоновский Internet Gateway, который для каждой подсети свой. К инстансам в этой сети можно привязывать Elastic IP и они будут работать.
Вторая (подсеть 10.0.1.0/24), пусть будет net2 — полностью закрытая подсеть, доступ из которой к внешним ресурсам возможен только посредством отдельного инстанса с настроенным на нем NATом (назовем его service). Прямого доступа к этой подсети извне, кроме как через какой-либо инстанс из net1, реализовать не получится. Сам service существует так же в net1.
Внутри VPC инстансы обоих подсетей видят друг друга.
Так же, есть офисная сеть, пусть она называется net0 (подсеть 192.168.5.0/24).
Появилась необходимость обеспечить защищенный доступ из офиса к инстансам в net1 и обратно. Это можно сделать нативным для Амазона способом — с помощью Virtual Private Gateway и сопустствующим ему сервисам. Но тут есть одна проблема — маршрутизация осуществляется посредством BGP, которого на пограничном маршрутизаторе офиса нет и не предвидится. На нем есть только чистый IPsec с авторизацией по паролю. В данной ситуации надо действовать через него.
Приходит в голову следующая схема реализации: на инстансе service, который имеет доступ Интернет и ко всем инстансам внутри net1, а так же обладает Elastic IP, развернуть клиента IPSec, соединиться с офисным маршрутизатором и настроить маршрутизацию между сетями.