Но не повсеместно, как я почитал это выглядит как обновление vision, исправление его косяков и добавление плюшек по типу QUIC H3 через CDN, xmux, ниже задержки и т.д. Но до сих пор требует своего домена. Я не думаю что много кто будет запариваться со своим доменом + nginx + caddy, если будет работать Reality.
Вот нашёл пример: Xray-examples/VLESS-TLS-SplitHTTP-CaddyNginx at main · XTLS/Xray-examples · GitHub
Насколько я понимаю, иметь свой домен сейчас - это просто правило хорошего тона и дополнительная степень свободы, стоит копейки, настраивается элементарно. А маскироваться под гугл/яшу/вэкашку на какой-нибудь Аезе, ну да, ни разу не палевно.
Кстати, по поводу своего домена - не уверен, reality совместно с xhttp вполне себе работает. И имеет свои плюсы, как то меньше количество открытых сессий
Да и разделение потоков звучит очень даже заманчиво. Мы ведь не знаем, как в будущем будет работать “черный ящик”, поэтому предположу, что xhttp даст много преимуществ
- Актуален, с некоторыми конфигурациями, как и obfs4.
- Я имею в виду цепочку VLESS(VPS1) - N(SERVER 2) - NOISY
- GitHub - 1tayH/noisy: Simple random DNS, HTTP/S internet traffic noise generator
Иначе говоря, провайдер будет видеть один коннект, а на самом деле внутри него подключение к разным сайтам + подключение (уже не мультиплексированное) к другому серверу (хоть публичному, хоть нет. Это не важно, как и протокол.), там так же noisy.
Опознать tls in tls не возможно, как и любая тайминг-шейпинг атака.
При чем в идеале, протокол должен быть отличный от того, что используется то есть не быть 2 reality, можно obfs4, vmess, shadowsocks, amneziawg, cloak, тд и тп, главное не reality и желательно шифрованный протокол (а ещё лучше, с паддингом).
В настройках noisy можно указывать домены не русские, но из-за “имитации кликов”, есть риск того, что вы попадете на русский домен, но емто не страшно если вы проксируете noisy, однако добавляется проблема - лишается один из главные свойств, в ответ на это можно проксировать через тор, а у него есть свойство (в случае определенной конфигурации и мостов), использовать разные мосты под разные подключения - то есть, вот есть у вас 5 мостов, тор будет случайно выбирать каждый из ниж под 15 разных подключений. Таким образом будет достигнута наша цель, дополнительно можно проделать такое же с любым публичным прокси и пустить через него noisy (естественно первичный сервер - ваш REALITY). Тогда будет идеально!
да… крыша моя сьехала шифером с крыши
Обновляйте 3X-UI, на днях XHTTP прикрутили, все работает. Хотите быть гуглом, будете гуглом.
Но тут суровые персы пишут, что у них Reality с маскировкой под популярные сервисы банят на раз-два, свои сайтики с небольшим трафиком живут дольше. По-хорошему для маскировки под чужой сайт надо искать сайт в свой подсети, сканировать порты, чтобы ваш IP вел себя как донор, это все не менее хлопотно настроить, чем свой домен.
Да, нужно только выпустить свой сертификат. Можно даже корневой выпустить без указания доменного имени и его использовать, но пока не понял, насколько это безопасно.
Это верно, но как бы не проморгать момент, когда будут практиковать не только блокировки. Совсем другой уровень ответственности.
Так ли нужен свой домен? Что его наличие принципиально меняет? Свой сайт будет и без домена работать, самоподписанные сертификаты тоже можно без домена выпустить. В чём ценность своего домена?
Можно подробнее, как работает XHTTP, тыкнуть меня в документацию или еще как-то?
Оригинал и перевод лежат здесь.
у аезы есть специальные сайты SNI в той же подсети что и сервер
Лично не вижу смысл тогда запариваться. Может если только он даёт какие-нибудь приемущества от vision или reality
Я обновил, даже до 2.4.9 Видимо я пока не понял как его настроить.
А ты сам прочитал пост? Там идёт речь про Иран, где маскируються под сайты которые в белом списке. И речь в основном идёт об объёме трафика, я думаю возможно это не обнаружение Reality GFW’ом, а используется что-то иное судя по тому что впс’ка умирает от кол-во трафика, а не из-за наличия Reality на нём. В этом же посте написано что после бана ssh рабботает нормально, бан порта?
В иране белый список, напоминаю.
RealityTLSScanner? GitHub - XTLS/RealiTLScanner: A TLS server scanner for Reality
Там думать особо не надо, пару комманд и нашёл донора, а домен ещё купить надо, эта та причина почему большенство вряд ли будут на vision и ему подобные переходить, а пытаться через free домены, типо duckdns начинает достовлять неудобство, чем преимущества. (Дольше сайты грузит, а если отвалиться то будут проблемы, ну по факту тот же Reality и выйдет)
Я уже понял, мы в лс списались и оказалось что мы вообще о разном говорили, я о сервер → сайт, а он про клиент → сервер.
RPRX не рекомендует использовать панели без https по умолчанию. 3x-ui тот же
Веб-панель — ВНИМАНИЕ: НЕ ИСПОЛЬЗУЙТЕ простые HTTP-панели, такие как 3X-UI , так как считается, что они были подкуплены Ираном GFW за поддержку простого HTTP по умолчанию и отказались изменить ( #3884 (комментарий) ), что уже привело к тому, что многие безопасность данных пользователей в последние несколько лет оказалась под угрозой. Если вы уже используете 3X-UI, переключитесь на следующие панели, которые проверены на поддержку только переадресации портов HTTPS и SSH:
На ntc тоже тема висит, решать только Вам Вниманию пользователей 3X-UI
Я бы предпочёл иметь “запас прочности”
Если для Reality - то просто как хороший тон, особо что-то не получите.
А если будете ставить что-то помимо Reality, а именно то что работает исключительно на TLS (я имею ввиду кнопку в панели, так-то и Reality на TLS работает) и Reality не поддерживает, то свой домен обязательно. Как вы тот же vision настроите без своего домена? Откроете сайт гугла или мелкомягких в cf и будете записи менять?))
Это верно, если ходить на панель напрямую. Если заставить панель слушать только 127.0.0.1 и прокидывать порт через ssh, то разницы никакой нет. Однако я говорил не про сертификаты для панели, а про сертификаты для своего сайта. Вроде бы где-то видел рекомендацию не использовать самоподписанные сертификаты, если проксируешься своим же сайтом, но найти сейчас не могу.
- Поднимаешь веб-сервер (с сайтом или без).
- Выпускаешь самоподписанные сертификаты.
- Настраиваешь либо TLS+VISION+FALLBACK, либо TLS+VISION+REALITY.
- В SNI указываешь что угодно или ничего.
С REALITY такое точно работает, с FALLBACK пока не тестировал. Ещё я выпускал только корневые сертификаты (без указания доменного имени), поэтому не уверен, что фокус с SNI работает, если указать в сертификате доменное имя. Пока не понял, проверяет ли XRay соответствие сертификата и SNI. Надо попробовать в DEST указать один сайт, а в SNI указать другой сайт.
TLS нормально заводится и без доменного имени.
Очевидно и бесспорно, если у злоумышленника есть доступ по ssh то никакие серты не помогут. Ну опять же, это рекомендация для большинства, которые не разберутся как так делать или им будет лень каждый раз по ssh подключаться.
Это как минимум бесполезно, для чего свой домен подписываться самоподписом? Если можно к cf привязать домен и там получить серты в разделе SSL абсолютно бесплатно.
Это как? Может быть vision + Reality + uTLS?
Просто звучит как Wireguard+Reality+Vmess
Научите, я в примерах такого не нашёл, видимо Вы знаете больше чем rprx))
Вам нужен домен, который указывает на IP-адрес сервера, и сертификат, например, от Let’s Encrypt.
Также вам потребуется Nginx (или любой другой веб-сервер, такой как Caddy).
А можете показать как в браузере сертификат выглядит и как его другие видят
А зачем козе баян? Для reality нет необходимости в этих действиях
Да, конечно. Ерунду написал, но вы поняли.
Выглядит вот так (я не стал заполнять никакие дополнительные поля типа доменного имени, страны, почты и так далее). Если попробовать в браузере открыть сайт с таким сертификатом, то будет показано предупреждение об угрозе безопасности, но сайт всё равно можно открыть (в Firefox будет замок с восклицательным знаком). Если добавить этот сертификат в систему в качестве доверенного, то предупреждение не будет показано.
Пример корневого сертификата (RSA 4096).
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
25:5e:51:87:21:7a:84:e1:87:31:8a:d4:1f:45:83:87:9e:71:d1:7a
Signature Algorithm: sha256WithRSAEncryption
Issuer:
Validity
Not Before: Dec 19 16:59:07 2024 GMT
Not After : Dec 19 16:59:07 2027 GMT
Subject:
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:de:8b:ed:ff:40:f6:6b:ea:33:c2:fb:ad:84:66:
cd:62:a1:39:b6:c3:00:03:0f:d8:fc:4e:de:41:2c:
db:a6:b6:9f:4a:73:0f:fd:00:04:0a:8e:8c:97:6f:
c5:c3:a6:de:e2:d5:d6:db:10:e1:e1:aa:89:27:37:
5c:e8:c7:f7:ab:80:7a:c1:dc:c9:ba:1f:df:11:1e:
45:64:09:50:04:35:5b:8b:fc:57:28:50:3c:18:65:
7e:f0:b4:89:90:f8:24:73:aa:57:23:96:a1:d7:dd:
c6:52:27:88:77:ce:ac:9f:d9:f8:7b:05:e6:fa:10:
3b:38:c0:2d:b4:a3:c1:a8:75:26:8d:9d:3b:f8:95:
3b:0e:30:1e:01:79:83:4b:2a:8f:7a:10:dc:f7:7c:
b7:78:f0:5c:39:1a:fc:cd:7c:29:12:a5:ff:ab:26:
db:f7:24:c0:a7:0f:28:20:26:9f:57:a1:75:5d:6b:
42:7d:50:1a:ce:19:9f:58:95:33:8e:89:be:71:1e:
0f:55:fd:96:49:41:36:1c:0b:79:54:80:c6:a7:50:
86:1c:1a:af:5e:1a:28:57:36:c0:74:b1:4e:c9:60:
2c:cf:c0:08:5e:58:c9:24:08:e8:ce:05:ec:4c:d1:
8b:51:55:28:d1:93:df:85:fe:8d:4c:1f:b6:a1:d5:
4d:2a:dd:87:43:5d:fe:2a:83:f7:cc:d6:9c:b3:68:
14:ae:58:30:53:92:36:00:01:d3:95:a5:76:dc:45:
b9:73:87:d9:30:f1:fe:70:69:77:53:40:84:42:39:
74:1d:6e:aa:6c:f5:02:53:ab:91:e5:a4:58:47:20:
9a:30:25:56:92:ce:3d:a5:98:c4:e6:4c:4c:63:ab:
46:f3:dd:79:3d:a0:b6:59:fe:eb:ac:0a:d8:22:72:
64:6d:e8:7a:34:2a:7e:c3:5d:cd:6a:c4:a7:39:d5:
d7:cf:3d:23:f3:60:9d:35:37:41:3a:f6:b6:1c:29:
36:66:fc:1d:ce:c3:1a:fa:cf:84:cb:64:43:d8:1f:
0c:36:1a:40:d6:20:61:3a:77:5b:53:2a:83:cc:86:
43:e8:24:f4:f2:da:0f:b7:ab:c0:89:84:b2:2b:2d:
22:6b:7f:b8:a1:d1:ff:c3:bd:6d:68:9b:b9:a2:ed:
73:67:a7:ec:01:05:25:41:ab:9f:78:4c:4b:1b:c8:
87:7e:50:1b:0d:79:27:30:1c:2b:e4:1f:87:c8:6d:
f7:e9:d1:ee:be:94:f7:bc:9b:1b:4c:29:a4:55:3e:
c1:fa:c2:bd:77:5d:16:2f:47:4f:30:41:48:15:4c:
73:12:d7:d6:b1:8d:80:8e:ed:07:29:da:07:d7:f8:
aa:37:45
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
CF:D0:49:AF:94:DC:7E:48:4B:A6:40:A2:00:EA:43:0A:81:10:CA:6E
X509v3 Authority Key Identifier:
CF:D0:49:AF:94:DC:7E:48:4B:A6:40:A2:00:EA:43:0A:81:10:CA:6E
X509v3 Basic Constraints: critical
CA:TRUE
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
58:ea:77:cf:36:72:a4:db:55:25:98:c2:98:8e:a0:d9:82:b8:
38:57:c9:4a:f7:4f:0f:5a:f4:40:7d:c2:da:a0:12:50:7a:4a:
ed:37:17:93:ab:45:2f:03:e8:13:7f:65:ed:75:94:b4:a2:d5:
b9:e9:bf:e1:1e:96:42:78:c3:e7:e0:4e:a3:2d:6e:85:fa:b6:
34:f9:76:be:29:cb:1d:1a:16:72:cf:fb:16:97:48:01:85:ab:
f4:57:b2:5a:9d:79:cd:07:3e:d4:40:af:f9:fa:1d:25:a5:09:
44:00:ec:ab:c8:b3:27:20:77:10:d2:9f:f0:e0:8b:f9:43:fd:
ac:9e:f6:6b:61:f2:59:80:a3:ad:b4:07:82:52:65:fc:24:ba:
f3:75:ee:97:ee:0f:12:43:73:a6:bc:48:84:cd:8e:f4:ba:8d:
ab:dc:70:e7:38:6c:67:7f:d3:93:4e:0a:a9:82:eb:cb:b5:a5:
cc:10:e5:20:5e:8f:d0:45:8f:70:d7:eb:ab:71:6f:ad:2e:d8:
19:b1:2e:fa:16:d1:1b:4d:aa:19:60:6e:89:d7:e7:6b:06:d9:
3f:04:d5:2d:5a:6d:dd:3c:9f:21:65:02:b9:18:39:fc:58:36:
20:d1:4a:84:6f:3e:2b:27:0d:dd:f1:ca:57:f5:5d:b2:d6:1b:
60:a6:60:45:4f:12:f6:5e:fa:05:ae:33:53:ce:43:2b:86:73:
a5:58:55:97:40:bd:c8:c4:17:1c:ef:5f:b5:63:3f:b8:08:89:
2d:91:89:aa:61:1b:ba:50:cf:5b:ed:a8:04:89:eb:6a:ae:92:
1f:83:39:00:65:6c:fe:6b:42:41:f1:2a:f4:93:ce:0d:f1:84:
01:d5:8d:ed:62:51:83:a2:2d:6d:02:43:9d:65:11:33:13:6c:
52:97:6c:93:11:6d:7b:45:18:b8:cc:df:96:58:60:db:3f:77:
4e:df:29:2c:c3:be:4b:c4:24:34:cd:88:19:92:84:8a:41:27:
2b:c5:65:cc:1c:c5:cd:3c:5a:c1:8c:bb:1f:bf:03:d4:bf:08:
93:7d:c3:0b:76:7f:2c:ee:7e:96:12:37:fa:c5:53:d7:5a:3c:
c6:d9:da:de:94:95:cc:63:0b:b1:98:61:36:40:00:62:d0:54:
90:4f:70:3e:20:17:36:5e:2b:4e:a9:2f:b7:00:01:25:06:7a:
b1:cc:ac:04:17:a5:e7:f8:70:d0:4d:71:16:5e:92:bd:71:01:
6c:1b:2c:6a:e8:6a:61:da:50:ee:4e:89:14:15:7d:a7:5c:f9:
c8:5f:51:fe:d7:9f:17:16:03:ec:c9:bb:62:b7:0a:f2:37:99:
23:fe:40:f2:3d:3d:26:bf
-----BEGIN CERTIFICATE-----
MIIE4TCCAsmgAwIBAgIUJV5RhyF6hOGHMYrUH0WDh55x0XowDQYJKoZIhvcNAQEL
BQAwADAeFw0yNDEyMTkxNjU5MDdaFw0yNzEyMTkxNjU5MDdaMAAwggIiMA0GCSqG
SIb3DQEBAQUAA4ICDwAwggIKAoICAQDei+3/QPZr6jPC+62EZs1ioTm2wwADD9j8
Tt5BLNumtp9Kcw/9AAQKjoyXb8XDpt7i1dbbEOHhqoknN1zox/ergHrB3Mm6H98R
HkVkCVAENVuL/FcoUDwYZX7wtImQ+CRzqlcjlqHX3cZSJ4h3zqyf2fh7Beb6EDs4
wC20o8GodSaNnTv4lTsOMB4BeYNLKo96ENz3fLd48Fw5GvzNfCkSpf+rJtv3JMCn
DyggJp9XoXVda0J9UBrOGZ9YlTOOib5xHg9V/ZZJQTYcC3lUgManUIYcGq9eGihX
NsB0sU7JYCzPwAheWMkkCOjOBexM0YtRVSjRk9+F/o1MH7ah1U0q3YdDXf4qg/fM
1pyzaBSuWDBTkjYAAdOVpXbcRblzh9kw8f5waXdTQIRCOXQdbqps9QJTq5HlpFhH
IJowJVaSzj2lmMTmTExjq0bz3Xk9oLZZ/uusCtgicmRt6Ho0Kn7DXc1qxKc51dfP
PSPzYJ01N0E69rYcKTZm/B3Owxr6z4TLZEPYHww2GkDWIGE6d1tTKoPMhkPoJPTy
2g+3q8CJhLIrLSJrf7ih0f/DvW1om7mi7XNnp+wBBSVBq594TEsbyId+UBsNeScw
HCvkH4fIbffp0e6+lPe8mxtMKaRVPsH6wr13XRYvR08wQUgVTHMS19axjYCO7Qcp
2gfX+Ko3RQIDAQABo1MwUTAdBgNVHQ4EFgQUz9BJr5TcfkhLpkCiAOpDCoEQym4w
HwYDVR0jBBgwFoAUz9BJr5TcfkhLpkCiAOpDCoEQym4wDwYDVR0TAQH/BAUwAwEB
/zANBgkqhkiG9w0BAQsFAAOCAgEAWOp3zzZypNtVJZjCmI6g2YK4OFfJSvdPD1r0
QH3C2qASUHpK7TcXk6tFLwPoE39l7XWUtKLVuem/4R6WQnjD5+BOoy1uhfq2NPl2
vinLHRoWcs/7FpdIAYWr9FeyWp15zQc+1ECv+fodJaUJRADsq8izJyB3ENKf8OCL
+UP9rJ72a2HyWYCjrbQHglJl/CS683Xul+4PEkNzprxIhM2O9LqNq9xw5zhsZ3/T
k04KqYLry7WlzBDlIF6P0EWPcNfrq3FvrS7YGbEu+hbRG02qGWBuidfnawbZPwTV
LVpt3TyfIWUCuRg5/Fg2INFKhG8+KycN3fHKV/VdstYbYKZgRU8S9l76Ba4zU85D
K4ZzpVhVl0C9yMQXHO9ftWM/uAiJLZGJqmEbulDPW+2oBInraq6SH4M5AGVs/mtC
QfEq9JPODfGEAdWN7WJRg6ItbQJDnWURMxNsUpdskxFte0UYuMzfllhg2z93Tt8p
LMO+S8QkNM2IGZKEikEnK8VlzBzFzTxawYy7H78D1L8Ik33DC3Z/LO5+lhI3+sVT
11o8xtna3pSVzGMLsZhhNkAAYtBUkE9wPiAXNl4rTqkvtwABJQZ6scysBBel5/hw
0E1xFl6SvXEBbBssauhqYdpQ7k6JFBV9p1z5yF9R/tefFxYD7Mm7YrcK8jeZI/5A
8j09Jr8=
-----END CERTIFICATE-----
Не хочется опираться на чужой сайт, но домен покупать тоже не хочется, поэтому решил поэкспериментировать. Жаль, Let’s Encrypt не разрешает выпускать сертификаты на IP, поэтому приходится самоподписанные сертификаты использовать.
Что делать если рядом с вашим отлично настроенным прекрасно скрытым проксей в той же подсети располагаются миллионы микрочелов которым было плевать на настройку, ведь они настраивали всё по васяно гайдам где бахнул 3x панель и готово ? В итоге цензор явно видит что к этой подсети идут триллионы мегабайт и там очевиднейший обход блокировки. Очень сомневаюсь, что когда у РКН дойдут руки до влесса, они будут выпиливать точечно плохо настроенные серваки, а не закроют всё общежитие. Что думаете по этому поводу ?
Что вас там так пугает, не понимаю? Денег $5 в месяц за VPS платить им не жалко, а $1 в год за домен отдать жаба что ли душит? Ну, личные данные, может, смущают? Ну я под левыми на namechуeap зарегистрировал и никто меня не съел. Сложность? Чо там сложного? Зарегистрировал, прописал DNS записи, через 10 минут заработало, ввел одну команду, получил Let’s Encrypt сертификат, который сам будет обновляться автоматически и все, сидишь как белый человек с нормальным доменом и сертификатом. Что там еще может отталкивать? Зачем искать трудные окольные пути, если есть прямой и простой?
Во-первых, я люблю упрощать решения и избавляться от зависимостей (да, моё понимание простоты не совпадает с вашим). Во-вторых, доллар есть доллар.
Если я правильно понял, вы проксируетесь своим сайтом. Скажите, пожалуйста, какой вариант вы выбрали: REALITY или FALLBACK? И почему?
Ок, принято. Мы все здесь параноики, но на разную тему.
Reality, конечно. Он безопасней. Потому что XTLS с Fallback это хакнутая библиотека TLS и она имеет отпечаток языка Go, на котором написана, что в теории является мишенью для обнаружения, хотя пока на практике по этому признаку не щемят. А Reality не несет собственного TLS отпечатка вашего сервера, он ворует настоящее TLS соединение или просто перекидывает вас на ваш же Nginx, который “пахнет” тем же Nginx, что и любой веб-сервер на нем.
- Мне казалось, что uTLS нужен, чтобы скрывать отпечаток клиента, а не сервера.
- FALLBACK тоже работает с uTLS.
Поправьте, если ошибаюсь, но мне пока непонятна разница этих двух подходов. Пока что у меня складывается ощущение, что REALITY не нужен, если проксирование идёт через свой сайт.