Неприступный VPS. Строим защищенный канал с внешним миром.

Blxck.

⭐️
Сообщения
218
Реакции
667
Баллы
94
Доброго времени суток, в данной статье я расскажу Вам как защитить свой трафик с помощью VPS.

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

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

Кто может интересоваться твоими сетевыми соединениями? Да кто угодно! От хакерских группировок до злобных админов, которые любят шейпить разные типы трафика (например, наши любимые торренты). Да и просто иногда требуется сменить IP (например, чтобы посмотреть зарубежную новинку в онлайн‑кинотеатре).

Итак, перед настройкой софта нам придется заняться необходимыми подготовительными работами:
  • купить VPS;
  • купить доменное имя;
  • зарегистрироваться на Cloudflare и выполнить необходимую настройку.
Разберем по порядку.

VPS.


Чтобы свести риски к минимуму, необходимо выбирать хостера VPS достаточно дотошно — обращай внимание на то, в каком государстве зарегистрировано юридическое лицо, в каких странах физически расположены серверы. Предпочтение следует отдавать тем, где законодательство строго относится к личной информации (например, Швейцария или Исландия). Это касается как места регистрации юридического лица, так и физического нахождения серверов.

Кроме того, не следует забывать про «альянс 14 глаз» (Австралия, Бельгия, Великобритания, Германия, Дания, Испания, Италия, Канада, Нидерланды, Новая Зеландия, Норвегия, США, Франция, Швеция) — это страны, которые свободно обмениваются разведданными друг с другом (законодательство у них соответствующее). Если твои данные попали в руки одной страны из этого списка, можно считать, что остальные тоже их получили.

Кроме того, есть страны, которые так или иначе сотрудничают с альянсом: Южная Корея, Япония, Израиль, Сингапур. Это на уровне слухов, но, как известно, дыма без огня не бывает. Можно много говорить о том, что конкретно ты им не нужен, что у них и без тебя забот полно, — тут каждый решает для себя, что ему важнее. Например, автор эти страны сразу вычеркнул из списка кандидатов. Итак, VPS купили, идем дальше.

Доменное имя.


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

info:
Почему не следует использовать ESNI/ECH? Все очень просто: если некоторые сетевые фильтры не могут определить сайт назначения, то они просто блокируют соединение.

Cloudflare.


Cloudflare в нашей цепочке играет роль защитного механизма: мы скрываем настоящий IP нашего VPS и защищаем его от некоторых видов атак. Трафик от нашего компа будет идти сначала в сеть Cloudflare и только из нее — к нашему VPS. Кроме того, Cloudflare сгенерирует сертификат для TLS-соединения, и весь трафик на всем пути следования будет завернут в TLS 1.3.

Для начала нам нужно пройти регистрацию и привязать к сервису купленный домен. Далее на вкладке DNS нужно заполнить строки А (две штуки), в которые мы вводим наш домен (в одну строку с приставкой www, в другую без нее) и IP нашего VPS.

1660772405600.png
Заполнение записей «A».

После этого необходимо ввести показанные нам серверы имен Cloudflare в панель управления нашего доменного регистратора на вкладке DNS.

1660772437600.png
Серверы имен Cloudflare.

Далее на вкладке SSL/TLS:
  • выбираем шифрование Full (strict);
  • включаем Always Use HTTPS;
  • включаем TLS 1.3;
  • устанавливаем Minimum TLS Version на 1.3;
  • включаем Opportunistic Encryption;
  • включаем Automatic HTTPS Rewrites.

1660772466400.png

Уф‑ф, немного укрепили TLS, можно двигаться дальше. Теперь идем в Client Certificates на той же вкладке и жмем кнопку Create Certificate для генерации сертификата и ключа (условимся, что файлы будут называться secret-site.pem и secret-site.key).

Теперь идем на VPS и приступаем к настройке.

Настройка VPS.

Итак, в некоторой степени утомительная подготовительная процедура окончена, давай теперь настраивать сам VPS. Все настройки будут делаться на Debian 11 x64.

Сначала обновим пакеты и установим вспомогательные утилиты:

apt update && apt upgrade -y

apt install -y dnsutils nethogs vnstat sendmail fail2ban nano wget unzip htop psmisc nginx


Теперь разберемся с сертификатами и ключами от Cloudflare — их мы положим на наш VPS в папку /etc/ssl/ и выдадим ей права только на чтение.

Далее надо сгенерировать параметр Диффи — Хеллмана:

openssl dhparam -out /etc/ssl/dh-param.pem 4096

Положим его в ту же папку /etc/ssl/.

Теперь приступим к настройкам Nginx в файле /etc/nginx/nginx.conf — в его стандартную структуру достаточно добавить наш сертификат, ключ, DH и некоторые служебные настройки:

server{

listen 443 ssl http2 reuseport backlog=131072 fastopen=256;

ssl_certificate /etc/ssl/secret-site.pem;

ssl_certificate_key /etc/ssl/secret-site.key;

ssl_dhparam /etc/ssl/dh-param.pem

ssl_protocols TLSv1.3;

ssl_ecdh_curve secp384r1;

add_header X-Robots-Tag "noindex, nofollow" always;

add_header X-Content-Type-Options "nosniff" always;

add_header X-Xss-Protection "1; mode=block" always;

add_header Strict-Transport-Security 'max-age=63072000; includeSubdomains; preload' always;

resolver localhost valid=300s;

ssl_buffer_size 8k;

ssl_prefer_server_ciphers off;

Далее добавим локации:

location / {

limit_req zone=one burst=5 nodelay;

index index.html index.htm;

limit_rate 19k;

set $limit_rate 19K;

proxy_redirect off;

}

location /secretline {

proxy_redirect off;

proxy_buffering off;

proxy_http_version 1.1;

proxy_pass http://localhost:8008/;

proxy_set_header Host $http_host;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Early-Data $ssl_early_data;

proxy_set_header Connection "upgrade";

}

В location / я вписал index.html — это просто сайт‑заглушка, который будет болтаться на нашем серваке для того, чтобы противостоять активному зондированию. Проще говоря, если какой‑то зонд будет сканировать сервер в поисках Shadowsocks или чего‑то еще, он просто увидит нашу заглушку. Тогда он подумает, что это обычный сайт, оставит нас в покое и уйдет пить пиво.

Локация location /secretline — это и есть наш Shadowsocks. Вместо строки secretline нужно придумать что‑то более оригинальное и трудноподбираемое, эта строка будет передаваться в качестве параметра на клиенте к плагину xray.

Далее скачиваем и устанавливаем Shadowsocks и xray-plugin:

wget https://github.com/shadowsocks/shadowsocks-rust/releases/download/v1.14.3/shadowsocks-v1.14.3.x86_64 unknown-linux-gnu.tar.xz &&

tar -xf shadowsocks-v1.14.3.x86_64-unknown-linux-gnu.tar.xz

wget https://github.com/teddysun/xray-plugin/releases/download/v1.5.4/xray-plugin-linux-amd64-v1.5.5.tar.gz &&

tar -xf xray-plugin-linux-amd64-v1.5.5.tar.gz


Создаем папку shadowsocks и копируем в нее нужные файлы:

mv ssserver /bin

mv xray-plugin /etc/shadowsocks/xray-plugin


Настраиваем разрешения:

setcap 'cap_net_bind_service=+eip' /etc/shadowsocks/xray-plugin

setcap 'cap_net_bind_service=+eip' /bin/ssserver


Теперь создадим файл конфигурации сервера Shadowsocks:

touch /etc/shadowsocks/shadowsocks-rust.json

nano /etc/shadowsocks/shadowsocks-rust.json


И запишем туда такой текст:

{

"server":["127.0.0.1"],

"server_port":8008,

"password":"Password123",

"timeout":300,

"method":"chacha20-ietf-poly1305",

"fast_open":true,

"reuse_port":true,

"plugin":"/etc/shadowsocks/xray-plugin",

"plugin_opts":"server;loglevel=none",

"nameserver":"1.1.1.1",

"mode": "tcp_and_udp",

"no_delay": true,

"workers":1

}

Давай пройдемся по основным пунктам:
  • "server_port"порт, на котором будет висеть сервер shadowsocks;
  • "workers"количество ядер на сервере;
  • "ipv6_first"поддержка протокола IPv6;
  • "nameserver" — IP DNS-сервера, если есть локальный, то 127.0.0.1;
  • "plugin" и "plugin_opts" используются для плагина xray;
  • "reuse_port"оптимизация для более быстрого использования сети;
  • "method"используемое шифрование;
  • "password"пароль для подключению к серверу.
Теперь создадим сервис ss-xray.service:

nano /etc/systemd/system/ss-xray.service

Записываем туда следующий текст:

[Unit]

Description=Shadowsocks with XRAY

After=network.target


[Service]

Type=simple

User=nobody

Group=nogroup

LimitNOFILE=51200

ExecStart=/bin/ssserver -c /etc/shadowsocks/shadowsocks-rust.json

ExecStop=/bin/killall ssserver

Restart=always

RestartSec=10


[Install]

WantedBy=multi-user.target

Сохраняемся и выходим: Ctrl + O, Ctrl + X. Включаем сервис:

sysctl -p && systemctl enable ss-xray.service

С основной настройкой мы закончили, теперь можно немного оптимизировать сетевой стек. В файл /etc/sysctl.conf дописываем следующее:

fs.file-max = 131072

net.core.rmem_max = 8388608

net.core.wmem_max = 8388608

net.core.rmem_default = 8388608

net.core.wmem_default = 8388608

net.core.optmem_max = 8388608

net.core.netdev_max_backlog = 131072

net.core.somaxconn = 131072

net.ipv4.ip_local_port_range = 1024 65535

net.ipv4.tcp_mem = 25600 51200 102400

net.ipv4.tcp_rmem = 4096 1048576 4194304

net.ipv4.tcp_wmem = 4096 1048576 4194304

net.ipv4.tcp_fastopen=3

net.ipv4.tcp_low_latency = 1

net.ipv4.tcp_no_metrics_save = 1

net.ipv4.tcp_adv_win_scale = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_timestamps = 0

net.ipv4.tcp_fin_timeout = 30

net.ipv4.tcp_window_scaling = 1

net.ipv4.tcp_keepalive_time = 150

net.ipv4.tcp_keepalive_probes = 5

net.ipv4.tcp_keepalive_intvl = 30

net.ipv4.tcp_synack_retries = 1

net.ipv4.tcp_slow_start_after_idle=0

net.ipv4.tcp_max_syn_backlog = 65536

net.ipv4.tcp_max_tw_buckets = 720000

net.ipv4.tcp_mtu_probing = 1


Опять сохраняемся и перезагружаем сервер. Теперь все должно работать.

Что в итоге у нас получилось? Запрос от нашего компа уходит в CDN Cloudflare, а возвращается от нашего VPS. Для внешнего наблюдателя создается впечатление, будто комп общается по TLS с каким‑то сайтом, но что передает — узнать не получится, ибо шифрование. Другими словами, наблюдается обычная сетевая активность, чего мы и хотели добиться.

В качестве клиентов к серваку можно смело юзать:

Как еще можно укрепить наш VPS? Например, так:
  • сменить порт SSH для того, чтобы автоматические сканеры не ломились на стандартный порт;
  • настроить Fail2ban, чтобы ограничить количество попыток ввести неправильный пароль для входа на сервер;
  • вместо прямого обращения к DNS-серверу можно настроить локальный сервер, который связывается с внешним миром при помощи DoH или DoT, чтобы даже хостер VPS не знал, какие DNS-запросы ты шлешь;
  • настроить учет трафика, чтобы не получить внезапный счет от хостера (если трафик у него лимитирован).

Одним словом, включай фантазию и обустраивай свой неприступный VPS!


Спасибо всем, кто прочёл эту статью. А тем, кто применил её спасибо ещё больше! :)
Если я где-то ошибся или Вы знаете какие-то интересные моменты которые я не упомянул - пишите комментарии.

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

BTC - bc1qlchn9j7ya3hdfz29sfqaapjch7c3c5ws4c2ase
 
Достаточно интересная и полезная статья, выражаю уважение автору. Вместе с этим, мне кажется, что данный вариант больше подходит либо для параноиков, либо для крупных фигур в управлении бизнесом. Рядовому пользователю или курьеру настолько сильно заморачиваться особого смысла нет, там достаточно связи VPN+Tor, учитывая то, что среди первых есть достаточно качественные и защищенные сервисы, для которых "анонимность" — отнюдь не пустое слово. Сам лично в последнее время очень сильно задумываюсь о подобном решении, начинате немного просвечивать моя пристращенность к конфиденциальности, но установка собственного VPN — это лишь один кирпичик для бронебойной стены анонимности
 
Достаточно интересная и полезная статья, выражаю уважение автору. Вместе с этим, мне кажется, что данный вариант больше подходит либо для параноиков, либо для крупных фигур в управлении бизнесом. Рядовому пользователю или курьеру настолько сильно заморачиваться особого смысла нет, там достаточно связи VPN+Tor, учитывая то, что среди первых есть достаточно качественные и защищенные сервисы, для которых "анонимность" — отнюдь не пустое слово. Сам лично в последнее время очень сильно задумываюсь о подобном решении, начинате немного просвечивать моя пристращенность к конфиденциальности, но установка собственного VPN — это лишь один кирпичик для бронебойной стены анонимности
Добрый день, можете в ЛС поделиться вашими наблюдения по сервисам которые на ваш взгляд эффективны и безопасны?
 
Стоило бы добавить более подробное описание настройки клиента. Особенно клиента на шлюзе (роутере).
Tails в tor через этот Shadowsocks запускать? Можно?
 
Стоило бы добавить более подробное описание настройки клиента. Особенно клиента на шлюзе (роутере).
Tails в tor через этот Shadowsocks запускать? Можно?
Добрый вечер, вам нужна цепочка Клиент -> ShadowSocks -> TOR -> Интернет?
 
Как xray ведёт себя с UDP?
 
Как xray ведёт себя с UDP?
xRay поддерживает UDP. Если xtls и меньше нагрузки на проц/сеть + повышенная скорость. Ещё есть v2Ray. Но проблема в том, что UDP не поддерживается плагинами Shadowsocks.
 
xRay поддерживает UDP. Если xtls и меньше нагрузки на проц/сеть + повышенная скорость. Ещё есть v2Ray. Но проблема в том, что UDP не поддерживается плагинами Shadowsocks.
На утечки UDP проверял, если на стороне сервера отключен? Имеется ввиду, если только TCP разрешен, то UDP блокируется на стороне клиента или мимо идёт?
 
Как тут у вас интересно. Пойду пожалуй по этому руководству сделаю себе VPS.
 
«Обычный» VPN (разве что за исключением SSTP) однозначно определяется провайдером как именно VPN. Быть анонимным он не предназначен и HTTPS не имитирует, по этому может быть заблокирован по протоколу. Вы полагаете что ещё не время готовиться к такому?
 
Хорошая пища, автору огромное спасибо
 
Мне одному кажется, или это все как то очень сложно)
 
это все как то очень сложно
Настройка самого Shadowsocks-proxy довольно проста (гораздо проще чем VPN) но в данном руководстве он для пущей безопасности обёрнут в cloudflare и nginx. Для начала, для эксперимента можно просто (без cloudflare и nginx) настроить его прямо в лоакльной сети, разместив клиент и сервер на разных хостах.
 
«Обычный» VPN (разве что за исключением SSTP) однозначно определяется провайдером как именно VPN. Быть анонимным он не предназначен и HTTPS не имитирует, по этому может быть заблокирован по протоколу. Вы полагаете что ещё не время готовиться к такому?
Если всё резать по протоколам начнут, смысл не будет уже конструировать подобные вещи, потому что на таком и подобных форумах будет 20 человек гиков сидеть и всё
 
полезная статья, автору огромное спасибо!
 
  • Знатно
Реакции: DEAd
спасибо за мануалы! даже я свои кривыми лапами вроде всё настроить!
 
Верх Низ