Можно как угодно. А еще проще проверить, когда вы уже залогинены где-то (например на госуслугах). Тогда и матчить ничего особо не нужно. Смотря какая задача решается. Спалить факт юзания сплит впн? Легко. Вы даже и не заметите подвоха. Чтобы у вас не заблокировали выходную ноду на границе? Так сделайте каскад из трех нод: ру - зарубеж - зарубеж. И желательно в разных ДЦ/конторах. Тогда на блокировку выходной ноды вам будет наплевать.
Как бы да :) Для того, чтобы вас спалить, достаточно посетить сайт палящего (ozon/wb/sber/max) а там, например, дёрнуть по js что-то, что должно быть заблокировано, например https://ipinfo.io/ip и всёго делов. Ну узнают IP адрес выходной ноды, дальше чего? Заблокируют его на границе? Ок, я в админке сменю адрес у этой виртуалки. Пфф, делов.
Могли бы вы написать статью небольшую именно про Naive server side. Я сегодня попробовал прокинуть - как раз об этот нюанс споткнулся. Ещё такой вопрос про udp транспорт: если рядом посадить порт на udp, он же должен в теории быть лучше tcp с точки зрения rtd и пропускной способности?
Если на outbounds у клиента указано как в вашем примере: tls enable, server "example.com", то в inbound конфиге должны быть ещё пути до сертификатов. Или я что-то путаю?
Вред чужим серверам — каждое новое подключение к прокси создает паразитную нагрузку на сервер, чей домен используется (и это же создает вам дополнительную задержку). При каждом новом подключении к такому прокси, прокси сначала соединяется с доменом, указанном в конфиге (под который маскируемся). Если этот сторонний сайт не ответил, то и прокси не будет работать.
Есть другой вариант: открыть несколько пайпов и держать их незакрывающимися (делать хелсчек), пайпы (outbounds) объединить в “type”: “urltest” и юзать потом его с опцией “interrupt_exist_connections”: false
Ещё, заметил, что sniff довольно сильно просаживает пропускную способность канала (да, понятно, зато можно ru отлавливать). Прям показательно просаживает. До снифа - почти 90% утилизации максимальной пропускной способности. После снифа - около 20-30% (правда я в dns по tls хожу)
В качестве современного решения автор sing‑box видит протокол NaiveProxy, который использует код сетевого стека Chromium, что хорошо маскирует трафик под обычный браузер
Это очень интересно! Можете подробнее рассказать? Сам сижу на sing-box, настроил как хочу, всё устраивает. Доку вкуривал довольно долго... :) Вот про NaiveProxy не понял, как/чем он лучше VLESS+reality over ws
Там проблема не в JA3, а в JA4 на этапе хендшейка. Порядок cipher suites отличается от chrome кардинально и присутствует extension, которого никогда не может быть в chrome. Это надо чинить.
Варианта два:
Ставишь прокси на зарубежной ноде и на ру ноде слушешь свой порт как inbound и кидаешь трафик через тоннель vless на outbound в направлении прокси.
Ставишь прокси на ру ноде и закидываешь весь трафик по процессу <имя процесса> на outbound.
Я же выше написал, читайте внимательно. Разные провайдеры и прочее и прочее. Так что да: пфф.
Можно как угодно. А еще проще проверить, когда вы уже залогинены где-то (например на госуслугах). Тогда и матчить ничего особо не нужно. Смотря какая задача решается. Спалить факт юзания сплит впн? Легко. Вы даже и не заметите подвоха. Чтобы у вас не заблокировали выходную ноду на границе? Так сделайте каскад из трех нод: ру - зарубеж - зарубеж. И желательно в разных ДЦ/конторах. Тогда на блокировку выходной ноды вам будет наплевать.
Какой атаке? Слить свой адрес выходной ноды? Это не атака.
Как бы да :) Для того, чтобы вас спалить, достаточно посетить сайт палящего (ozon/wb/sber/max) а там, например, дёрнуть по js что-то, что должно быть заблокировано, например https://ipinfo.io/ip и всёго делов. Ну узнают IP адрес выходной ноды, дальше чего? Заблокируют его на границе? Ок, я в админке сменю адрес у этой виртуалки. Пфф, делов.
Очень смелое утверждение. У меня в конфиге inbound только tun интерфейс.
И Вы не спешите :) Напишите как надо :)
Могли бы вы написать статью небольшую именно про Naive server side. Я сегодня попробовал прокинуть - как раз об этот нюанс споткнулся. Ещё такой вопрос про udp транспорт: если рядом посадить порт на udp, он же должен в теории быть лучше tcp с точки зрения rtd и пропускной способности?
А! Вот в чём нюанс!
header Proxy-Authorization "Basic change-me"Если на outbounds у клиента указано как в вашем примере: tls enable, server "example.com", то в inbound конфиге должны быть ещё пути до сертификатов. Или я что-то путаю?
Шикарно! изучу, где накосячил.
Ещё хорошо бы подтюнить 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Есть другой вариант: открыть несколько пайпов и держать их незакрывающимися (делать хелсчек), пайпы (outbounds) объединить в “type”: “urltest” и юзать потом его с опцией “interrupt_exist_connections”: false
Ещё, заметил, что sniff довольно сильно просаживает пропускную способность канала (да, понятно, зато можно ru отлавливать). Прям показательно просаживает. До снифа - почти 90% утилизации максимальной пропускной способности. После снифа - около 20-30% (правда я в dns по tls хожу)
Это очень интересно! Можете подробнее рассказать? Сам сижу на sing-box, настроил как хочу, всё устраивает. Доку вкуривал довольно долго... :) Вот про NaiveProxy не понял, как/чем он лучше VLESS+reality over ws
Deleted
Там проблема не в JA3, а в JA4 на этапе хендшейка. Порядок cipher suites отличается от chrome кардинально и присутствует extension, которого никогда не может быть в chrome. Это надо чинить.
средство доступа к информации
Не смотрел пермишены, у него на BOOT тоже выставлены?
Предлагаю заменить КВН на ВЧС! :)