Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 72
Sing-box великолепен использую его уже несколько лет..очень простая и быстрая настройка .. Позволяет очень многое в том числе буквально прям в конфиге писать правила маршрутизации для доменов..ip..или использовать списки geoip ..делать для них разные аутбаунды..причем аутбаунды могут иметь совершенно другой протокол) короче очень рекомендую) на мой взгляд более удобного инструмента в нашей нынешней ситуации просто нет)
На Windows оригинального удобного клиента нет.
A multi-platform proxy client based on Sing-box universal proxy tool-chain. Hiddify offers a wide range of capabilities, like automatic node selection, TUN mode, remote profiles etc. Hiddify is ad-free and open-source. With support for a wide range of protocols, it provides a secure and private way for accessing free internet.
Хотел еще изначально вставить мнение автора sing-box о VLESS. Подумал, что в статье будет лишним (не по теме). Но для комментариев пойдет. Его претензии:
Вред чужим серверам — каждое новое подключение к прокси создает паразитную нагрузку на сервер, чей домен используется (и это же создает вам дополнительную задержку). При каждом новом подключении к такому прокси, прокси сначала соединяется с доменом, указанном в конфиге (под который маскируемся). Если этот сторонний сайт не ответил, то и прокси не будет работать.
Решение несуществующей проблемы — на самом деле ни РКН, ни GFW не особо смотрят на сертификаты. Насколько я знаю, у нас еще никого не блокировали за самоподписанные сертификаты. Да, SNI смотрят, но не более.
Первоначальный отказ от мультиплексирования (лишние подключения, лишние задержки). Да, сейчас уже используют xhttp, но это уже другое.
Использование uTLS, который вроде бы и маскируется под конкретный браузер, но делает это очень топорно. Имитируем буквально один пакет, а всё остальное другое.
Вторичность архитектуры — Sekai называет сам протокол VLESS низкокачественной копией Trojan. По его мнению, все эти надстройки (Vision и Reality) можно было точно так же прикрутить к старому доброму Trojan, а сам по себе VLESS не принес никаких реальных инноваций.
По его мнению
Её.
Вред чужим серверам — каждое новое подключение к прокси создает паразитную нагрузку на сервер, чей домен используется (и это же создает вам дополнительную задержку). При каждом новом подключении к такому прокси, прокси сначала соединяется с доменом, указанном в конфиге (под который маскируемся). Если этот сторонний сайт не ответил, то и прокси не будет работать.
Есть другой вариант: открыть несколько пайпов и держать их незакрывающимися (делать хелсчек), пайпы (outbounds) объединить в “type”: “urltest” и юзать потом его с опцией “interrupt_exist_connections”: false
Большая часть этих пунктов - не про «вред VLESS», а про «вред» Reality и других штук (типа uTLS), никакого отношения к самому VLESS не имеющих.
про п.2 классическое: сейчас не смотрят, а в любой момент могут начать смотреть. «Решать проблемы по мере их возникновения» в вопросе обхода блокировок и противодействия цензуре - это плохая и очень опасная практика.
Еще про sing-box vs Xray и про автора sing-box. Многие считают его токсичным (неохотно идет на контакт, часто игнорирует чужие pull request, жестко защищает свое детище от чужого вмешательства). Впрочем, это не всегда плохо (все мы слышали про характер Линуса Торвальдса). Автор Xray, наоборот, часто общается в комментариях к issue, предлагает какие-то решения, вносит правки в угоду пользователям. Популярности Xray поспособствовал протокол VLESS (в том числе благодаря статьям на хабре), который появился именно там (а потом уже был интегрирован в sing-box).
Спасибо за статью. Месяц назад очень пригодился бы хороший готовый конфиг. Было потрачено много времени и нервов на попытку настройки nekoray_core на линуксе. В итоге через гуй всё стабильно, быстро и без ошибок, но сервисом запускать core так и не осилил. Плюнул, перешёл на другое ядро и стэк, за 10 минут настроил и теперь оно просто работает, как должно. Быстро, стабильно, перманентно.
Автору спасибо. Познавательно для затравочки.
Но в современных реалиях, когда любой российский сайт, и любое российское приложение, могут отслеживать всю эту маршрутизации по IP и доменам, просто добавив коннект на западный IP и домен, как это реализовали в скаме, сложные настройки маршрутизации видимо и не требуются. Актуальной становится только маршрутизация на уровне как раз приложений на смартфоне или на Windows/MacOS.
Так что большой и страшный конфиг можно и подсократить.
Схема для примера. Плюс для примера мессенджер Max идёт всегда в direct как на уровне исключения из tun, так и на уровне маршрутизации по процессам. По этому примеру можно пустить, например, Firefox всегда через прокси, а условный Chrome всегда напрямую. Все варианты конфигов не рассмотреть (да и ситуации у всех разные), хотелось дать минимальную базу для старта.
Так форки этот тоже умеют, только в виде галочек и переключателей. Не нужно писать конфиг, просто тыкнул хром ходить через впн, фф не ходит через впн и все.
Другой интересный момент, к примеру на андроид приложения видят, что есть подключенное vpn-соединение, на винде тоже видны были, просто не все это отслеживают, но такие приложения как банки точно проверяют, макс уверен так же ну и разные там госуслуги думаю тоже могут молча чекать
Насколько мне известно sing-box клиент для iOS есть свежий, но чтобы получить его надо немного задонатить (сколько не знаю). подробности на этой странице: https://sing-box.sagernet.org/clients/apple/
Да, об этом написано в статье. Нужно задонатить любую сумму, но обязательно через github. После этого вступить в телеграм-канал и дать их боту ограниченный доступ к своему github. После этого бот добавит в спонсорский чат, где будет ссылка на TestFlight. Проблема в том, что sing-box будет постоянно обновляться, нужно будет постоянно заходить в приложение, принимать правила и каждый раз заново запустить ядро кнопкой. Не очень удобно, но работает.
В качестве современного решения автор sing‑box видит протокол NaiveProxy, который использует код сетевого стека Chromium, что хорошо маскирует трафик под обычный браузер
Это очень интересно! Можете подробнее рассказать? Сам сижу на sing-box, настроил как хочу, всё устраивает. Доку вкуривал довольно долго... :) Вот про NaiveProxy не понял, как/чем он лучше VLESS+reality over ws
Этот протокол добавили в sing-box недавно. Вот основной репозиторий: https://github.com/klzgrad/naiveproxy
Тут просто взяли весь сетевой стек от chromium и стали использовать его для проксирования. Со стороны трафик один в один соответствует трафику браузера (в плане всевозможных отпечатков). Не нужно никаких uTLS. Встроенное мультиплексирование. Плюс легко настраивается fallback. Нужно настроить Caddy перед sing-box, но там буквально несколько строк конфига. Разделение на фейковый сайт или прокси проходит через http-заголовок авторизации. При активном пробинге открывается сайт. Если клиент передает нужные логин и пароль, то идет проксирование.
Ещё, заметил, что sniff довольно сильно просаживает пропускную способность канала (да, понятно, зато можно ru отлавливать). Прям показательно просаживает. До снифа - почти 90% утилизации максимальной пропускной способности. После снифа - около 20-30% (правда я в dns по tls хожу)
Ещё хорошо бы подтюнить vps по сетевому стэку
net.ipv4.tcp_keepalive_time = 60net.ipv4.tcp_keepalive_intvl = 10net.ipv4.tcp_keepalive_probes = 5net.core.somaxconn = 65535net.ipv4.tcp_max_syn_backlog = 16384net.core.default_qdisc=fqnet.ipv4.tcp_congestion_control=bbrnet.ipv4.tcp_slow_start_after_idle=0net.core.netdev_max_backlog=16384net.core.rmem_max=16777216net.core.wmem_max = 16777216net.ipv4.tcp_rmem = 4096 87380 16777216net.ipv4.tcp_wmem = 4096 65536 16777216net.ipv4.udp_rmem_min = 16384net.ipv4.udp_wmem_min = 16384net.ipv4.tcp_fin_timeout = 30
А не страшно ставить такого клиента не из официального Google Play или App Store?
Я изначально, когда перешел с iOS на Android, тоже боялся ставить из F-Droid. Но потом понял, что из F-Droid даже безопаснее, чем из официального магазина. В F-Droid всё собирается из открытых исходных кодов (100% кода должно быть открыто). И гарантируется, что сборка именно из публичного кода. Что за бинарник в магазине Google - никто не знает. Так что при наличии выбора я всё ставлю теперь из F-Droid.
Что за бинарник в магазине Google - никто не знает.
Что-то сомнительно, я для браузера делал расширение с селективной маршрутизацией (т.е. чтобы один сайт шел через один прокси, другой сайт через другой прокси, а YouTube/Netflix - напрямую). Так в Chrome Store каждая новая версия проходит ручную модерацию, даже если несколько стилей поправил (в Firefox после первоначальной модерации быстро проверяют, видимо на автомате diff смотрят)
На всякий случай укажу несколько недостатков sing-box с которыми столкнулся сам..ни смотря на то, что считаю его сегодня лучшим решением....
Sing-box работает в юзерспейсе со всеми вытекающими т.е. если захочется использовать его на роутере с жирным каналом в 1 гигабит..то будет грустно .. Тк он использует 1 поток и в реальности грузит одно ядро .. Хотя инструменты вроде htop могут показывать загрузку всех ядер ..соответственно на двух разных достаточно производительных роутерах мне не удалось выжать из него более 450 мегабит).
Еще одна головная боль это его tun интерфейс .. Во первых он поднимается далеко не во всех ОС куда можно sing-box поставить и даже на ubuntu разных версий не всегда взлетает) во вторых этот интерфейс довольно специфичен..он умеет пропускать только tcp и udp т.е. icmp и другие специфичные протоколы мимо) другими словами он не будет работать как привычный tun интерфейс как этого ожидаешь когда слышишь tun)
Он в целом умеет в ICMP, но видимо есть какие-то ограничения. Из документации:
https://sing-box.sagernet.org/configuration/inbound/tun/#loopback_address
For legacy reasons, when neither
strict_routenorauto_redirectare enabled, all ICMP traffic will not go through TUN.
Если рассматривать роутер на Openwrt, то в чём отличия sing-box от пакета PBR? Я не успел до конца ознакомиться с подробностями, но кажется, что PBR делает примерно то же самое (направление трафика на разные интерфейсы), но на уровне TCP/IP-стека ядра.
В комментарии выше уже сказано, что sing-box работает в юзерспейсе.
2 дня увлекательного секса, но удалось написать рабочий конфиг под socks5.
Да, это только для локальной сети. Основной профит - удобство включения/выключения и возможность настроить, для каких приложений (Android) оно будет применяться. Даже если приложение вообще не работает с socks5. Например, chatgpt.
{ “dns”: { “servers”: [ { “type”: “https”, “tag”: “proxy-dns”, “detour”: “proxy”, “server”: “8.8.8.8” } ], “strategy”: “ipv4_only” }, “inbounds”: [ { “type”: “tun”, “tag”: “tun-in”, “address”: “172.19.0.1/30”, “auto_route”: true, “strict_route”: true, “route_exclude_address”: “your_socks5_proxy_ip/32”, “stack”: “gvisor” } ], “outbounds”: [ { “type”: “socks”, “tag”: “proxy”, “server”: “your_socks5_proxy_ip”, “server_port”: your_socks5_proxy_port, “version”: “5”, “username”: “yourlogin”, “password”: “yourpassword”, “udp_over_tcp”: false }, { “type”: “direct”, “tag”: “direct” } ], “route”: { “rules”: [ { “port”: 53, “action”: “hijack-dns” }, { “protocol”: “dns”, “action”: “hijack-dns” }, { “inbound”: “tun-in”, “action”: “sniff” }, { “protocol”: “quic”, “action”: “reject” } ], “final”: “proxy”, “default_domain_resolver”: “proxy-dns” } }
а можно, пожалуйста, еще инструкцию по настройке сервера под такой клиент
Да, планирую написать статью, но на сервере всё намного проще.
Ставим sing-box из их репозитория (буквально несколько команд с официального сайта): https://sing-box.sagernet.org/installation/package-manager/
Правим конфиг sing-box /etc/sing-box/config.json. Вот полная версия конфига для naive сервера:
{
"inbounds": [
{
"type": "naive",
"tag": "naive-in",
"network": "tcp",
"listen": "0.0.0.0",
"listen_port": 443,
"users": [
{
"username": "naive",
"password": "change-me"
}
]
}
],
"outbounds": [
{
"type": "direct"
}
]
}Вот и всё.
Если на outbounds у клиента указано как в вашем примере: tls enable, server "example.com", то в inbound конфиге должны быть ещё пути до сертификатов. Или я что-то путаю?
Прошу прощения, я поспешил с ответом и ответил неверно. Пытался на ходу чуть упростить конфиг. У меня перед sing-box стоит обычный Caddy из официального репозитория (непатченный): https://caddyserver.com/docs/install
У меня есть свой домен, использую его. Caddy автоматически получает бесплатный сертификат на поддомен. Есть свой fallback-сайт (example.example.com).
Caddyfile:
{
email admin@example.com
auto_https disable_redirects
}
:443, https://example.example.com {
tls {
issuer acme {
disable_http_challenge
}
}
route {
@naive {
method CONNECT
header Proxy-Authorization "Basic change-me"
}
handle @naive {
reverse_proxy h2c://127.0.0.1:1080 {
header_up Proxy-Authorization {header.Proxy-Authorization}
}
}
handle {
root * /srv/naive-fallback
file_server
}
}
}Конфиг sing-box на сервере:
{
"inbounds": [
{
"type": "naive",
"tag": "naive-in",
"network": "tcp",
"listen": "127.0.0.1",
"listen_port": 1080,
"users": [
{
"username": "naive",
"password": "change-me"
}
]
}
],
"outbounds": [
{
"type": "direct"
}
]
}В Caddyfile после Basic нужно вставить base64 от username:password из конфига sing-box.
А! Вот в чём нюанс! header Proxy-Authorization "Basic change-me"
Могли бы вы написать статью небольшую именно про Naive server side. Я сегодня попробовал прокинуть - как раз об этот нюанс споткнулся. Ещё такой вопрос про udp транспорт: если рядом посадить порт на udp, он же должен в теории быть лучше tcp с точки зрения rtd и пропускной способности?
Опубликовал статью о настройке сервера с naive: https://habr.com/ru/articles/1024990/
И Вы не спешите :) Напишите как надо :)
а как там с пробросом UDP, я у себя настроил, но дискорд голос не заработал((
Автор,а подскажи пожалуйста. Если у меня есть собственный арендованный сервер VPN,допустим через HIP,в Швеции. Куда нужно поместить ip сервера в конфиг чтобы работало через него?
Отличная статья! Попробовал базовый конфиг на андроид, по субъективным ощущениям работает быстрей чем популярные клиенты из гугл плэй. Автор подскажите! Посмотрел примеры, почитал документацию, попробовал варианты, но сам не смог разобраться как сделать обратный конфиг: выбранные приложения идут через tun, остальные напрямую так как в моем случае намного проще добавить 3-4 приложения в include_package, чем выискивать более 10 названий пакетов для exclude_package
Вы можете все равно направлять все в tun, но дальше уже управлять гибкими правилами маршрутизации.
Вам нужно редактировать секцию route. Сначала поменять значение final на direct. Это через что все будет идти, если не будет совпадений по правилам. Правила из rules проверяются сверху вниз до первого действия с action route. Если хотите конкретные приложения в прокси, то указываете их список в package_name, а outbound меняете на proxy-select или на tag конкретного сервера.
Странные дела. Взял за базу ваш конфиг, как клиента так сервера и немного допилил для под свои задачи. Установил нативный клиент SFA(sing-box for Android). Использовал протокол NaiveProxy поэкспериментировать. Соединение устанавливается все работает ютуб вацап... все кроме телеграм, в логах видно, что вроде как телеграм обнаружен и уходит в туннель, но в активных соединениях его нет и в целом он не работает. С vless такой проблемы нет. Получается все таки он каким то образом детектируется и пакеты блокируются. Не могу понять в чем причина такого поведения.
Может в самом telegram настроен прокси (в настройках приложения)?
Придумал тут интересную реализацию на базе вашего конфига :)
У меня проводной провайдер поступает значительно проще - поставил request rate на запросы к одному и тому же IP адресу и это убивает работу XRay.
Догадался я далеко не сразу - у меня начала очень нестабильно работать WEB UI от живущего в интернете proxmox'а - панелька генерит по 5-20 запросов в минуту, долгое время пытался починить сам proxmox. Обнаружил после того, как уже отчаялся, загнал трафик через локальный прокси (для улучшения диагностики), а на стороне proxmox'а смотрел трафик wireshark'ом. Во время срабатывания request rate'а до хоста даже SYN пакеты не доходят.
Решается ли как-то эта проблема в XRay / Sign-Box'е? К примеру, можно балансировать сессии между 5-10-XX IP адресами, но имея единую exit node'у.
Скорее всего у вас используется протокол, который не совместим с мультиплексированием (или мультиплексирование отключено). Мультиплексирование - это когда несколько ваших соединений помещаются в один туннель до прокси. Соответственно без этого подключений до прокси много, что детектируется и приводит к блокировке IP. Решение - использование протоколов с мультиплексированием. Например, VLESS + XHTTP или NaiveProxy.
Свежая статья о NaiveProxy: https://habr.com/ru/articles/1024990/
Вопросик есть по использованию. Не могу заставить sing-box использовать dns в сети, к которой подключаюсь. Все локальные ресурсы доступны по ip, на внешние маршрузирует по правилам локалки. Но все dns запросы идут на внешние ip, или вообще никуда не идут.
В конфигурации выше используется 2 DNS для разных доменов, но все внешние. Можете просто указать один local, или добавить какие-то особые правила. Конфигурация очень гибкая, добиться можно почти чего угодно.
https://sing-box.sagernet.org/configuration/dns/server/local/
А что скажите про mihomo? Нравится, что в него можно добавлять автообновляемые списки серверов.
У кого-нибудь был опыт настройки роутинга для mdns адресов .local? Не могу сообразить почему не работает. В серверах днс есть dhcp, в правилах днс есть geosite-private -> dhcp, в роутинге есть geosite-private -> direct. Но почему то не работает такая связка.
upd: разобрался. в firefox стояла галка отправлять днс-запросы в socks5 :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Знакомство с sing-box