Вопрос об отношении С. к материи составляет основной вопрос философии. Диалектико-материалистич. решение этого вопроса состоит в том, что С. есть свойство высокоорганизованной материи, функция того сложного “куска материи”, к-рый называется мозгом человека.
Философская Энциклопедия. В 5-х т. — М.: Советская энциклопедия. Под редакцией Ф. В. Константинова. 1960—1970
Смысл моего суждения состоял в том, что нахождение сознания внутри материального объекта не означает материальности самого сознания и превалирования материи над сознанием. Иными словами, даже если согласиться с материалистическим пониманием сознания в этом аспекте, вышеизложенное не подтверждается.
Тот факт, что сознание заключено в материальный объект (головной мозг), не говорит о том, что всё материально, и даже о первичности материи, поскольку помимо материальной формы есть и содержание — деятельность сознания, и она носит по большей части идеалистический характер. Все сведения об окружающем мире, которые известны человечеству, были приобретены посредством неё: будь то познание через органы чувств или построение логических конструкций, опытным или теоретическим путём.
Я вовсе не отрицаю вклада нейробиологов, изучающих деятельность мозга, но то, что происходит внутри нашего сознания, не может быть в достаточной степени объяснено на основе данных, полученных таким путём.
Если всё, что мы знаем о мире, прошло через «фильтр» сознания, то мы в принципе не можем безапелляционно заявлять об объективном существовании чего-либо в материальном мире в том виде, в котором оно предстало нашему сознанию. Вся наша жизнь решающим образом зависит от идей. Даже слова обусловлены ими. Предательство, ложь, героизм, правда, добро, зло — от того, что человек вкладывает в их смысл, зависит и выраженная ими мысль, а мысль порождает наше поведение. А значит, утверждения о всеобщей материальности и примате материи неверны.
Реальное iCloud-соединение от iPhone имеет характерный паттерн: конкретные API-эндпоинты, характерные тайминги, специфичные заголовки. VLESS-туннель с произвольным трафиком ведёт себя иначе: постоянный двунаправленный поток без пауз, нетипичные размеры пакетов, никаких iCloud API-запросов.
Каким образом можно определить API-эндпоинты, если путь, заголовки, параметры и тело запроса зашифрованы и стороннему наблюдателю виден только SNI?
WebSocket умер по конкретной причине: соединение начинается с HTTP Upgrade, после чего переходит в постоянный двунаправленный поток без характерных HTTP запрос-ответных пар. Этот паттерн детектируется давно и надёжно.
Вовсе он и не умер. WS/HTTPUpgrade-транспорт работает до сих пор. А причина его потенциальной уязвимости кроется главным образом в alpn HTTP/1.1, что при использовании CDN может быть подозрительным (по умолчанию они работают по HTTP/2 и HTTP/3, если поддерживается браузером). Подчеркиваю: может быть. Мне неизвестно ни об одном случае блокировки по этому признаку.
XHTTP разделяет восходящий и нисходящий трафик на отдельные HTTP-транзакции
Непонятно, о каких транзакциях идёт речь. Если о HTTP-запросах, то режим stream-one создаёт только один. Если про разделение нисходящего и исходящего потоков, то это работает только при дополнительной настройке.
packet-up — <...> Стартовый выбор по умолчанию.
Неправда. По умолчанию сервер принимает все три режима. А поведение клиента зависит от параметров TLS и alpn.
stream-up — <...> Быстрее, но не проходит через все CDN и реверс-прокси. Для прямого соединения без CDN.
Первое утверждение противоречит второму. Если некоторые CDN (в том числе самая популярная — Cloudflare) поддерживают этот режим, зачем безапелляционно утверждать, что он предназначен только для прямого соединения?
stream-one — <...> Медленнее, но единственный режим совместимый с XTLS-Vision.
Снова неправда. XTLS-Vision поддерживается всеми режимами xHTTP (и другими транспортами) при включении VLESS Encryption. (Но TLS-in-TLS будет устранён только при использовании RAW (TCP)-транспорта с TLS 1.3).
Nginx для stream-one требует конкретных директив: ...
Достаточно grpc_pass
Версии Xray на клиенте и сервере обязаны совпадать. Несовпадение даёт либо глюки, либо полную неработоспособность без понятных ошибок. Это не «желательно» — это условие работоспособности.
Это отнюдь не условие работоспособности. Версии могут быть разными. Более того, насколько мне известно, во VLESS реализован механизм обмена информацией о версиях ядра клиента и сервера и функционал подстраивается под это соотношение. Да, отсутствие некоторых функций на одной стороне может привести к невозможности подключения, но далеко не всегда.
Ну и напоследок про таблицу. Сначала вы пишете про IP/ASN несоответствие, а потом называете связку VLESS + XHTTP + Reality «лучшей из доступных», даже лучше сервера со своим собственным доменом. Хотя в таком случае проблема несоответствия домена IP-адресу сохраняется.
Далее в таблице указано, что xHTTP работает через CDN только в режиме packet-up, что не соответствует действительности: функционально это поддерживается каждым из режимов. Packet-up лишь обеспечивает максимальную совместимость со всеми CDN.
По неизвестной причине TLS-отпечаток в конфигурации VLESS + xHTTP без Reality у вас удостоился лишь звания «хорошего», хотя utls работает одинаково и с ним, и без. Про XTLS-Vision уже писал.
Но самое удивительное, что вы заявляете о частичной поддержке работы через CDN конфигурацией VLESS + XHTTP + Reality. Это исключено. Reality никоим образом не может проходить через CDN, это противоречит принципу его работы.
Складывается ощущение, что ИИ принял самое непосредственное участие в написании этой статьи, потому что человек, который ознакомился с документацией, не допустил бы таких глупых ошибок.
Это обязательно? В документации рекомендовано использовать maxConcurrency вместо maxConnections:
Я выбрал maxConcurrency вместо maxConnections, чтобы предотвратить превращение количества соединений в фиксированный шаблон (fixed pattern). Конечно, если вам нравится второй вариант, можете настроить его вручную.
Вы упомянули, что многие советуют переход на проксирование через Cloudflare. Это странно, потому что он под блокировкой ещё с лета. У меня, например, к июлю полностью отвалился на нём xhttp — сначала только в режимах stream-up/stream-one, а затем и на packet-up. Не открывается и множество сайтов под ним — как на мобильных операторах, так и на ПК.
Протестировал xhttp с Reality — та же беда. Видимо, остается только вариант с размещением xray за обратным прокси. Но в таком случае, полагаю, можно использовать просто транспорт HTTP/2 вместо xhttp (по идее мультиплексирование должно работать на уровне протокола h2).
Смысл моего суждения состоял в том, что нахождение сознания внутри материального объекта не означает материальности самого сознания и превалирования материи над сознанием. Иными словами, даже если согласиться с материалистическим пониманием сознания в этом аспекте, вышеизложенное не подтверждается.
Зависит от настроек tun в клиенте и конфигурации xray/sing-box.
Тот факт, что сознание заключено в материальный объект (головной мозг), не говорит о том, что всё материально, и даже о первичности материи, поскольку помимо материальной формы есть и содержание — деятельность сознания, и она носит по большей части идеалистический характер. Все сведения об окружающем мире, которые известны человечеству, были приобретены посредством неё: будь то познание через органы чувств или построение логических конструкций, опытным или теоретическим путём.
Я вовсе не отрицаю вклада нейробиологов, изучающих деятельность мозга, но то, что происходит внутри нашего сознания, не может быть в достаточной степени объяснено на основе данных, полученных таким путём.
Если всё, что мы знаем о мире, прошло через «фильтр» сознания, то мы в принципе не можем безапелляционно заявлять об объективном существовании чего-либо в материальном мире в том виде, в котором оно предстало нашему сознанию. Вся наша жизнь решающим образом зависит от идей. Даже слова обусловлены ими. Предательство, ложь, героизм, правда, добро, зло — от того, что человек вкладывает в их смысл, зависит и выраженная ими мысль, а мысль порождает наше поведение. А значит, утверждения о всеобщей материальности и примате материи неверны.
К статье есть серьёзные вопросы.
Каким образом можно определить API-эндпоинты, если путь, заголовки, параметры и тело запроса зашифрованы и стороннему наблюдателю виден только SNI?
Вовсе он и не умер. WS/HTTPUpgrade-транспорт работает до сих пор. А причина его потенциальной уязвимости кроется главным образом в alpn HTTP/1.1, что при использовании CDN может быть подозрительным (по умолчанию они работают по HTTP/2 и HTTP/3, если поддерживается браузером). Подчеркиваю: может быть. Мне неизвестно ни об одном случае блокировки по этому признаку.
Непонятно, о каких транзакциях идёт речь. Если о HTTP-запросах, то режим stream-one создаёт только один. Если про разделение нисходящего и исходящего потоков, то это работает только при дополнительной настройке.
Неправда. По умолчанию сервер принимает все три режима. А поведение клиента зависит от параметров TLS и alpn.
Первое утверждение противоречит второму. Если некоторые CDN (в том числе самая популярная — Cloudflare) поддерживают этот режим, зачем безапелляционно утверждать, что он предназначен только для прямого соединения?
Снова неправда. XTLS-Vision поддерживается всеми режимами xHTTP (и другими транспортами) при включении VLESS Encryption. (Но TLS-in-TLS будет устранён только при использовании RAW (TCP)-транспорта с TLS 1.3).
Достаточно
grpc_passЭто отнюдь не условие работоспособности. Версии могут быть разными. Более того, насколько мне известно, во VLESS реализован механизм обмена информацией о версиях ядра клиента и сервера и функционал подстраивается под это соотношение. Да, отсутствие некоторых функций на одной стороне может привести к невозможности подключения, но далеко не всегда.
Ну и напоследок про таблицу. Сначала вы пишете про IP/ASN несоответствие, а потом называете связку VLESS + XHTTP + Reality «лучшей из доступных», даже лучше сервера со своим собственным доменом. Хотя в таком случае проблема несоответствия домена IP-адресу сохраняется.
Далее в таблице указано, что xHTTP работает через CDN только в режиме packet-up, что не соответствует действительности: функционально это поддерживается каждым из режимов. Packet-up лишь обеспечивает максимальную совместимость со всеми CDN.
По неизвестной причине TLS-отпечаток в конфигурации VLESS + xHTTP без Reality у вас удостоился лишь звания «хорошего», хотя utls работает одинаково и с ним, и без. Про XTLS-Vision уже писал.
Но самое удивительное, что вы заявляете о частичной поддержке работы через CDN конфигурацией VLESS + XHTTP + Reality. Это исключено. Reality никоим образом не может проходить через CDN, это противоречит принципу его работы.
Складывается ощущение, что ИИ принял самое непосредственное участие в написании этой статьи, потому что человек, который ознакомился с документацией, не допустил бы таких глупых ошибок.
Это обязательно? В документации рекомендовано использовать maxConcurrency вместо maxConnections:
Вы упомянули, что многие советуют переход на проксирование через Cloudflare. Это странно, потому что он под блокировкой ещё с лета. У меня, например, к июлю полностью отвалился на нём xhttp — сначала только в режимах stream-up/stream-one, а затем и на packet-up. Не открывается и множество сайтов под ним — как на мобильных операторах, так и на ПК.
Протестировал xhttp с Reality — та же беда. Видимо, остается только вариант с размещением xray за обратным прокси. Но в таком случае, полагаю, можно использовать просто транспорт HTTP/2 вместо xhttp (по идее мультиплексирование должно работать на уровне протокола h2).