С самоподписаными сертификатами https соединение - устанавливается. В случае с браузером- он просто предупреждает что оно "не безопасно"(=не подписано тем, кому браузер доверяет)
Да, можно. Только это не специализованный MTProto - а просто системный прокси, через который ТГ гонит весь свой трафик. Как? В телефоне всё работает из коробки. В windows (скорее всего на macOS и linux также) - в настройках ТГ не менять (продолжать использовать) опцию "использовать системные настройки прокси".
Когда осенью блокировали телегу на юге, через подобный прокси всё работало.
Сертификаты в первую очередь нужны, чтобы трафик между CDN и VPS шифровался.
Ели обойтись без сертификатов, но придётся перенастраивать всё таким образом, чтобы CDN и VPS общались не по зашифрованному https, а по обычному http. Хотя так тоже можно, да, но всё же не хочется передавать свои данные по интернету в открытом виде.
В чем разница между режимами работы в Android приложении: VPN / Proxy?
Proxy - приложение меняет настройку системного прокси, а все другие программы (браузеры например) - если умеют и хотят его учитывать - учитывают
VPN (он же TUN) - создаёт виртуальное сетевое подключение и делает его главным. Таким образом прокси будут использовать 99.5% программ. Исключение - софт, который "умный слишком" и умеет перебирать сетевые подключения, например qbittorrent.
Лучше использовать доменную зону отличную от .ru или нет разницы и .ru подойдет?
Если речь идёт про домен для CDN - то не вижу разницы. Если про домен для маскировки VPS - то лучше маскироваться под сайт из той же страны, маскировка под ru-домен может нести риски.
CDN... Российский трафик есть, иностранного и заблокированного / нет
Мне сложно диагностировать неполадки с помощью телепатии:) Но пока все случаи неработоспособности CDN, с которыми я встречался, сводились к ошибкам реализации инструкции.
Единственное, у домена созданы NS-записи, но нет DNS-записей. Они должны быть? И если да, то какие?
Если вопрос в том, нужно ли где-то прописывать что-то, чего нет в инструкции, то ответ - нет:)
То что warp светит свой московский IP - это подозрительно и может быть причиной блокировки чатгпт. (если варп считает что соединение к нему идёт из РФ - то и свой IP тоже предоставит из РФ). Что делать: проверить IP своего VPS по разным базам, возможно он где-то светится как российский. если так - либо ждать когда базы обновятся, либо предоставить доказательства хостеру и попросить поменять. Других идей пока нет.
Лично у меня связка nuxt(GE)-warp-openai работает.
никогда его не смотрел, и слышал что нетфликс не любит любые IP, которые определяются как принадлежащие датацентру, так что через VPS не зайдёшь.
Однако в панели 3x-ui есть опция - проксировать нетфликс через warp, возможно она поможет. (напомню, после изменений в панели нужно сохраняться и перезагружать xray).
Другой вариант о котором слышал - через прокси подключаться к одному из заблокированных в РФ бесплатных VPN-ов с американскими серверами(какие именно - не знаю), специально чтобы смотреть нетфликс.
да, вероятно проблемы где-то на магистрали я(рф) -- vdsina(nl). У меня сейчас скорость скачивания через vdsina - от 2 до 30 Mbps, но когда соединяюсь с vdsina через промежуточный сервер в германии, то поднимается до максимума. что с этим делать - не знаю (хочу верить что это авария и её устранят :).
Возможно ваши ответы на эти два вопроса помогут что-то прояснить:
1) в какой стране VPS? 2) Route OpenAI (ChatGPT) through WARP: доступа к ChatGPT нет и с включённой и с выключенной опцией? (напомню, после изменений нужно сохраняться и перезагружать xray)
смог повторить подобную ошибку, когда захожу по условному адресу `habraproxy.store/my-gRPC-3049382` из браузера, то есть по адресу, по которому происходит соединение vless-grpc-tls поэтому предположу, что некорректно настроены правила на шаге 8
ERR_INVALID_RESPONSE -- там же должен быть код ошибки, например 521 или что-то в этом роде. если погуглить код ошибки - это может дать ясность что не так.
Как понять что ошибки при генерации сертификата не было?
прочитать результат вывода каждой команды
пишет что сертификат недействительный, поэтому и http
вот это странно. если панель увидела сертификаты (пусть даже и "недействительные", самоподписанные), она не даст зайти в себя по http, будет упрямо менять адрес на https. (в адресной строке будет видно https перечёркнутый, типа небезопасный). если вы можете войти в панель по http - значит она не увидела сертификаты.
вообще предлагаю попробовать зайти в панель по https с любого другого устройства, например с телефона. это чтобы убедиться, что дело не в компе а именно в панели.
Если так, то прошу указать что прописать в Debian, чтобы вернуться к нужному шагу.
к сожалению не понял эту фразу.
А вот стратегия "снести и попробовать заново" меня самого спасала много раз, рекомендую:)
чтобы соединение стало защищённым, нужно сгенерировать сертификаты, скопировать их в докер (инструкция ч.1 шаг 7), а затем в настройках панели (инструкция ч.2 шаг 3) в нужные места вписать имена файлов /private.key и /public.key. Как только панель видит пару корректных ключей - она начинает работать исключительно по https.
так что либо ключи не вписаны, либо вписаны но не скопированы в докер, либо случилась ошибка при их генерации.
--- я также допускаю, что может в панели всё настроено верно и дело в каких-то настройках бразуеров или ОС компьютера, которые не дают открывать "не очень защищённые" https-сайты, но сам с таким не встречался.
Добавить сайт whatismyipaddress.com в правила проксирования варпа (перезагрузить+сохранить), зайти на этот сайт и убедиться что IP поменялся, и он принадлежит CloudFlare
... в фаерволе
К сожалению я не изучал WARP достаточно глубоко, поэтому не знаю, по каким портам он общается со своими серверами. Гугл вам в помощь. В своей инструкции "для чайников", я использую чистую Debian 12 без фаерволла, там таких проблем не возникает.
у меня не было проблем с CDN:)
С самоподписаными сертификатами https соединение - устанавливается. В случае с браузером- он просто предупреждает что оно "не безопасно"(=не подписано тем, кому браузер доверяет)
Да, можно. Только это не специализованный MTProto - а просто системный прокси, через который ТГ гонит весь свой трафик.
Как? В телефоне всё работает из коробки. В windows (скорее всего на macOS и linux также) - в настройках ТГ не менять (продолжать использовать) опцию "использовать системные настройки прокси".
Когда осенью блокировали телегу на юге, через подобный прокси всё работало.
Сертификаты в первую очередь нужны, чтобы трафик между CDN и VPS шифровался.
Ели обойтись без сертификатов, но придётся перенастраивать всё таким образом, чтобы CDN и VPS общались не по зашифрованному https, а по обычному http. Хотя так тоже можно, да, но всё же не хочется передавать свои данные по интернету в открытом виде.
Благодарю за комментарии!
Отвечаю:
Proxy - приложение меняет настройку системного прокси, а все другие программы (браузеры например) - если умеют и хотят его учитывать - учитывают
VPN (он же TUN) - создаёт виртуальное сетевое подключение и делает его главным. Таким образом прокси будут использовать 99.5% программ. Исключение - софт, который "умный слишком" и умеет перебирать сетевые подключения, например qbittorrent.
Если речь идёт про домен для CDN - то не вижу разницы. Если про домен для маскировки VPS - то лучше маскироваться под сайт из той же страны, маскировка под ru-домен может нести риски.
Мне сложно диагностировать неполадки с помощью телепатии:) Но пока все случаи неработоспособности CDN, с которыми я встречался, сводились к ошибкам реализации инструкции.
Если вопрос в том, нужно ли где-то прописывать что-то, чего нет в инструкции, то ответ - нет:)
всё верно, если WARP(а он принадлежит cloudflare) посчитает что к нему подсоединились из РФ, но выходной IP будет российским.
Вижу, что заработало после отключения варпа, поздравляю!
То что warp светит свой московский IP - это подозрительно и может быть причиной блокировки чатгпт. (если варп считает что соединение к нему идёт из РФ - то и свой IP тоже предоставит из РФ).
Что делать: проверить IP своего VPS по разным базам, возможно он где-то светится как российский. если так - либо ждать когда базы обновятся, либо предоставить доказательства хостеру и попросить поменять. Других идей пока нет.
Лично у меня связка nuxt(GE)-warp-openai работает.
никогда его не смотрел, и слышал что нетфликс не любит любые IP, которые определяются как принадлежащие датацентру, так что через VPS не зайдёшь.
Однако в панели 3x-ui есть опция - проксировать нетфликс через warp, возможно она поможет. (напомню, после изменений в панели нужно сохраняться и перезагружать xray).
Другой вариант о котором слышал - через прокси подключаться к одному из заблокированных в РФ бесплатных VPN-ов с американскими серверами(какие именно - не знаю), специально чтобы смотреть нетфликс.
да, вероятно проблемы где-то на магистрали я(рф) -- vdsina(nl). У меня сейчас скорость скачивания через vdsina - от 2 до 30 Mbps, но когда соединяюсь с vdsina через промежуточный сервер в германии, то поднимается до максимума.
что с этим делать - не знаю (хочу верить что это авария и её устранят :).
Возможно ваши ответы на эти два вопроса помогут что-то прояснить:
1) в какой стране VPS?
2)
Route OpenAI (ChatGPT) through WARP: доступа к ChatGPT нет и с включённой и с выключенной опцией? (напомню, после изменений нужно сохраняться и перезагружать xray)смог повторить подобную ошибку, когда захожу по условному адресу `habraproxy.store/my-gRPC-3049382` из браузера, то есть по адресу, по которому происходит соединение vless-grpc-tls
поэтому предположу, что некорректно настроены правила на шаге 8
ERR_INVALID_RESPONSE -- там же должен быть код ошибки, например 521 или что-то в этом роде. если погуглить код ошибки - это может дать ясность что не так.
если речь идёт о вставке ключа в приложение Hiddify-Next, то нужно использовать опцию "добавить из буфера", а не "ввести вручную"
к сожалению с подписками я не разбирался (и не планирую в ближайшее время), может другие читатели подскажут
У меня с этим хостером скорость скачивания тоже сейчас не радует, в причинах пока не разобрался. может у них проблемы, может на магистрали.
Добавлю: если использовать CDN - то скорость может уменьшаться за счёт доп.узла, лучше соединяться напрямую если возможно.
Переустановка происходит не через команды сервера, а через панель хостинга. Но судя по комментарию ниже, вам это не нужно, т.к. всё работает верно.
Верно
прочитать результат вывода каждой команды
вот это странно. если панель увидела сертификаты (пусть даже и "недействительные", самоподписанные), она не даст зайти в себя по http, будет упрямо менять адрес на https. (в адресной строке будет видно https перечёркнутый, типа небезопасный). если вы можете войти в панель по http - значит она не увидела сертификаты.
вообще предлагаю попробовать зайти в панель по https с любого другого устройства, например с телефона. это чтобы убедиться, что дело не в компе а именно в панели.
к сожалению не понял эту фразу.
А вот стратегия "снести и попробовать заново" меня самого спасала много раз, рекомендую:)
чтобы соединение стало защищённым, нужно сгенерировать сертификаты, скопировать их в докер (инструкция ч.1 шаг 7), а затем в настройках панели (инструкция ч.2 шаг 3) в нужные места вписать имена файлов /private.key и /public.key.
Как только панель видит пару корректных ключей - она начинает работать исключительно по https.
так что либо ключи не вписаны, либо вписаны но не скопированы в докер, либо случилась ошибка при их генерации.
---
я также допускаю, что может в панели всё настроено верно и дело в каких-то настройках бразуеров или ОС компьютера, которые не дают открывать "не очень защищённые" https-сайты, но сам с таким не встречался.
Добавить сайт
whatismyipaddress.comв правила проксирования варпа (перезагрузить+сохранить), зайти на этот сайт и убедиться что IP поменялся, и он принадлежит CloudFlareК сожалению я не изучал WARP достаточно глубоко, поэтому не знаю, по каким портам он общается со своими серверами. Гугл вам в помощь.
В своей инструкции "для чайников", я использую чистую Debian 12 без фаерволла, там таких проблем не возникает.
https://habr.com/ru/articles/785186/comments/#comment_26395888