Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 36
О чем статья? Тема пятикратно пережевано уже нейросетями во всех статьях.
Я лично на Хабре не увидел подобного туториала (актуального) и решил опубликовать для таких как я
Потому, что - 451
У меня есть vps, зарубежный, на нём установлен WireGuard и есть 4 клиента. Телефон, два компьютера, и сервер debian с виртуальной машиной с HAOS. Пользуюсь только я один. Всё работает уже 5 месяцев. Трафика я генерирую мало. Может в этом причина, что меня не блокируют? А vpn который на продажу, те ркн и блокирует.
Чем больше подобных статей, тем быстрее блочат.
А про то о чем нет никаких статей - живёт себе и работает как часики )
Во-первых, технология VPN - это вообще не про обход блокировок, это придумка отечественных запретителей.
VPN - это про организацию частной сети поверх публичной. И в том числе возможно применение для обхода злонамеренных запретителей.
Во-вторых, предложенный вариант страдает от нескольких недостатков по существу (но указывать на них не буду, потому что вот сотрудник РКН уже приготовился записывать)
В третьих, сам по себе вариант так себе: вот зачем там нужна база данных, если это не публичный сервис с кучей аккаунтов, а для себя любимого?
Извините конечно, но про то, что впн это частная сеть поверх публичного интернета я написал в статье и так.
По второму нечего мне сказать, так как вы сами не назвали эти недостатки, чтобы их как-то парировать. Ну и я нигде не писал, что это лучшая связка. Я написал, что это быстро и возможно скоро мой VPN упадёт как и при предыдущей связке.
Про базу данных. Я не писал, что это VPN только для себя любимого. Я написал лишь то, что при выборе SQLITE он не подходит под большие охваты и коммерческие цели (что показано на скриншоте).
Поэтому выходит, что вы сами придумали недостатки моей статьи и сами на них ответили
По второму нечего мне сказать, так как вы сами не назвали эти недостатки, чтобы их как-то парировать. Ну и я нигде не писал, что это лучшая связка. Я написал, что это быстро и возможно скоро мой VPN упадёт как и при предыдущей связке
Потому и упадёт.
Но пояснить не могу - к сожалению, сейчас это та тема, детальное обсуждение которой приводит только к более лучшим блокировкам.
Могу только посоветовать обратиться к опыту китайских товарищей, у них есть хорошие конфигурации.
не писал, что это VPN только для себя любимого
По тексту статьи это и подразумевается. Потому что, зная минусы прямых ссылок:
и вставляете туда ссылку начинающуюся с vless://
— вы бы вряд ли советовали вставлять именно их. Для поддержки гибкости для этого придуманы подписки. Вдобавок не увидел в стате работу с доменом, TLS и self-steal SNI (кто-то ещё использует чужие домены для маскировки в REALITY?). Всё это подразумевает развертывание решения исключительно для себя.
Вдобавок, решение годится разве что для уровня 2022 года (не считая нового xHTTP). С тех пор гонка щита и меча ушла далеко вперёд... Ковровые бомбардировки хостеров, 16-20, "сибирская блокировка", БС... Такие простые сетапы уже давно не актуальны на масштабе. Но для себя пойдёт! Если, конечно, заработает.
Лучше бы написали как проанализировать проблему) Например как выяснили что соединение рвётся при рукопожатии)
У меня например NAIVE по HTTPS иногда блокировался на 5 минут, а при смене на QUIC пока нормально
Кому-то уже об этом писал, но повторюсь - поднимая панель на голом http сразу отправляйте логин и пароль на почту rsoc_in@rkn.gov.ru, сэкономите всем время.
И простите за прямоту, но за реалити на google.com Вам должно быть стыдно. Только ленивый на хабре не оттоптался, почему это хреновая идея в 2к26
Этот VPN только для показа, очевидно, что я не буду показывать свой SNI
Это еще не самый плохой вариант, запустите https://github.com/xtls/RealiTLScanner у меня в подсетях они максы и яндексы сидят :)
Автор только забыл упомянуть, что панель сама по себе глючная и если у вас вдруг никак не может система заработать, сносите панель и делайте без нее. С ИИ оно даже ставится проще чем с панелью, если на ИИ навесить часть создания конфига.
У меня ушло больше 5 часов, чтобы понять, что панель прекрасно отображает в интерфейсе все параметры, только вот приваткей в конфиг почему то записать забывает. Это был стандартный глюк в марте. В мае, когда у меня возникла другая проблемка, у меня уже ИИ по собственной инициативе спросил, не стоит ли случайно у меня панелька, потому что в мае был другой какой-то стандартный глюк (не вникал).
Включите SOCKS5 авторизацию, чтобы другие приложения не обнаружили туннель.
А разверните поподробнее, о чем речь. Где подразумевается авторизация? Куда/где вводить ее Логин/Пароль? Заранее спасибо. Из-за поломанной кармы не могу спрашивать чаще, чем раз в сутки(дебилы бл@) Так что не обессудьте, если вопрос покажется странным и не кидайтесь тапочками, я не настоящий сварщик. Просто подробнее разжуйте, как построена цепочка. Я вообще не понимаю этот финт с двумя хопами(чем прямое обращение клиента за кордон к VPS с VPN отличается от прямого обращения за кордон промежуточного хопа-туннеля, с точки зрения блокираторов? И там и там зашифрованные пакеты со странным поведением и странными паттернами).
Напишите мне в телеграмм, там сможете задать вопросы без лимитов. @pxi_ru
В VPN-клиентах в настройках трафика или маршрутизации обычно есть возможность включить SOCKS5 авторизацию, логин и пароль вводятся там же или можно оставить то, что сгенерировало приложение.
Про цепочки. Можно напрямую отправлять пакеты на VPN сервер, а он уже на нужные ресурс обращается (функция проксирования больше), но это считается слишком открыто и небезопасно.
Для решения этой проблемы делают цепочки: сначала вы отправляете на VPS внутри вашей страны, а этот VPS отправляет зарубежному VPN серверу
Это если максимальное упростить
Про цепочки. Можно напрямую отправлять пакеты на VPN сервер, а он уже на нужные ресурс обращается (функция проксирования больше), но это считается слишком открыто и небезопасно.
Поясните, пожалуйста, почему "считается слишком открыто и небезопасно"?
Цепочку можно построить как угодно и на каких угодно протоколах. Иногда, чтобы повысить скорость внутри РФ, на чистом WG, но лучше всего на том же стеке, что и Xray/sing-box предлагают: TLS-Reality/xHTTP. Итого: между каждым сервером в цепочке реализуется максимально замаскированное bleeding-edge решение. В чем открытость и, тем более, небезопасность? Кроме теоретической возможности задетектить "зеркальный" трафик на одном из промежуточных хопов в цепочке, проблем я не вижу.
Знаете, вот по вашим комментариям мне всё больше кажется, будто вы берете советы из рубрики "вредных". Либо что-то не то с матчастью, либо вы имеете в виду какие-то технические условия, далёкие от обобщенных.
UPD: увидел последний абзац, и ваш совет внезапно стал правильным. Да, тут вы правы, беру слова назад.
Можно напрямую отправлять пакеты на VPN сервер, <...> но это считается слишком открыто и небезопасно.
Скорее не "небезопасно", скорее "менее удобно". Вот начнут после осени зарубежный трафик считать, и тут только цепочка через РФ хоп поможет не упереться в 15 ГБ лимит.
Пишите подробней! Вас внимательно читают!
Дописать еще клиент на фингерпринт яндекс браузера я в популярных клиентах не нашел яндекса
Чем читать статью, максимально поверхостную, советую тем, кому интересно просто почитать ntc
Вот также думаю. В статье буквально практикуется самый наивный из сетапов - без TLS, без self-steal, просто для себя. Даже в 2022-м это было пусть и ещё рабочим, но уже слишком простым вариантом. Такие сетапы мало того, что цензор щёлкает на раз-два, так ещё и палят всю подсетку хостеру со стороны РФ. Вот с такими соседями мне и приходится жить...
Вариант с бд pg не нужен для себя даже если добавить ноду, проблема была не в самом tcp транспорте, а внезапно в отпечатке chrome и множестве соединений к серверу. Mux решал одну задачу смена отпечатка другую.
В итоге эту проблему решил, и придумал как сделать классический https прокси вместе с сайтом на одном домене... это транспорт на самый плохой исход,.
Связка reality хороша правда, но зачем вам reality вместе с xhttp, когда лучше повесить какой нибудь свой сервис, поставить обратный прокси, и на основе пути решать /xhttp пошёл в панель, а / перешёл на сайт, схема самое главное рабочая в контексте можно откатить tls1.3 на сервере до max 1.2 тем самым исключить вмешательства в tls 1.3 по сибирской схеме. Да reality отвалится там обязательно 1.3 но xhttp, ws, grpc, классический connect останется жив.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как быстро реализовать современный работающий VPN в эпоху блокировок: теория и практика