Это руководство описывает развёртывание HTTPS-прокси с помощью dumbproxy на практически любом Linux-сервере. Потребуется только curl и рутовый доступ на какой-то сервер.
Под HTTPS-прокси здесь подразумевается HTTP-прокси с подключением через TLS, а не просто нешифрованный HTTP-прокси, через который может работать и HTTPS. То есть такой HTTPS-прокси привносит дополнительный слой TLS между клиентом и прокси-сервером, обеспечивая таким образом конфиденциальность соединения с прокси-сервером. Такие прокси пригодны для непосредственного использования в браузерах и прочем софте. Так называемые браузерные "VPN-расширения", по сути, работают как раз через такие HTTP-прокси "с шифрованием".
Зачем и почему?
Зачем HTTPS-прокси?
Хорошо подходит для доступа к заблокированному контенту, не требуя при этом переключать трафик всей системы. Можно использовать избирательно для каких-то отдельных сайтов, доменов и т.п.
Стандартный протокол, который внешне выглядит как HTTPS потому что технически он и есть HTTPS.
Альтернативные решения типа shadowsocks зачастую всё равно приходится прятать внутрь TLS с помощью плагинов вроде simple-tls или v2ray. А в таком случае отпадает нужна в самом shadowsocks -- проще непосредственно использовать обычный прокси внутри TLS.
Поддерживается браузерами без дополнительного ПО. Остальное ПО, поддерживающее HTTP-прокси, можно подружить с HTTPS-прокси с помощью вот такого адаптера.
Больше о преимуществе защищённых прокси над VPN можно узнать в одном из моих предыдущих постов.
Почему dumbproxy?
Это довольно простой прокси-сервер, который специально сделан для нынешних реалий, работает на множестве разных платформ и операционных систем. По сути для работы достаточно запустить лишь один исполняемый файл.
В то же время dumbproxy имеет ряд других достаточно важных плюсов:
Возможность прятать ответ прокси кодом 407, чтобы прокси не выдавал себя при активном опросе (по умолчанию отключено).
Легковесные потоки позволяют ему обслуживать существенное количество одновременных соединений (десятки тысяч) в конфигурации по умолчанию, что является преимуществом по сравнению с 3proxy и tinyproxy. В сочетании со скромным расходом памяти на каждое соединение, это позволяет эксплуатировать прокси на VPS минимальных тарифных планов.
Простое управление авторизацией: файл с пользователями автоматически перезагружается тогда, когда обнаружены изменения.
Поддерживает HTTP/2.
Имеется возможность авторизации по сертификатам TLS (вероятно, это будет удобнее использовать, применяя steady-tun на стороне клиента).
Сервер возьмёт на себя выпуск сертификатов для доменных имён, используя протокол ACME (например, через Let's Encrypt или BuyPass).
Шаг 1. Назначение доменного имени
Нам потребуется доменное имя для сервера, чтобы на нём беспроблемно работал TLS (HTTPS). Вы можете либо купить домен и привязать его к IP-адресу вашего VPS, либо использовать какой-либо бесплатный сервис, предоставляющий доменные имена. В последнем случае, родительский домен вашего домена должен быть внесён в список публичных суффиксов доменов. Иначе могут возникнуть проблемы с выпуском сертификата через Let's Encrypt - упрётся в разрешённое число выпущенных сертификатов для родительского домена за какой-то период времени. В этом руководстве мы воспользуемся бесплатным сервисом freemyip.com, который даёт домен пользователю даже без регистрации.
Зайдите на страницу https://freemyip.com/.
Выберите красивое доменное имя и заберите его.
Сохраните куда-нибудь ссылку, которую получите.
Запустите следующую команду на вашем сервере:
curl 'ССЫЛКА', гдеССЫЛКА- та самая ссылка, которую вы получили на предыдущем шаге. Обратите внимание: нужно не забыть взять ссылку в одиночные кавычки!
Проверка: проверьте ваш домен ping-ом, он должен указывать на IP-адрес вашего VPS. Если это не так, то попробуйте подождать несколько минут и попробовать снова.
Шаг 2. Установка dumbproxy
Предполагается архитектура процессора amd64. Для других случаев см. бинарники здесь. Запустите команду:
curl -Lo /usr/local/bin/dumbproxy 'https://github.com/Snawoot/dumbproxy/releases/download/v1.6.1/dumbproxy.linux-amd64' && chmod +x /usr/local/bin/dumbproxyПроверка: команда dumbproxy -version должна выводить v1.6.1.
Шаг 3. Конфигурирование dumbproxy
Создадим файл со списком пользователей и паролей. Запустите следующую команду, заменяя USERNAME и PASSWORD настоящими желаемыми значениями имени пользователя и пароля:
dumbproxy -passwd /etc/dumbproxy.htpasswd 'USERNAME' 'PASSWORD'Сконфигурируйте dumbproxy. Создайте файл /etc/default/dumbproxy со следующим содержимым:
OPTIONS=-auth basicfile://?path=/etc/dumbproxy.htpasswd -autocert -bind-address :443Создайте файл /etc/systemd/system/dumbproxy.service со следующим содержимым:
[Unit]
Description=Dumb Proxy
Documentation=https://github.com/Snawoot/dumbproxy/
After=network.target network-online.target
Requires=network-online.target
[Service]
EnvironmentFile=/etc/default/dumbproxy
User=root
Group=root
ExecStart=/usr/local/bin/dumbproxy $OPTIONS
TimeoutStopSec=5s
PrivateTmp=true
ProtectSystem=full
LimitNOFILE=20000
[Install]
WantedBy=default.targetНаконец, примените новую конфигурацию systemd:
systemctl daemon-reloadШаг 4. Запустите dumbproxy
Включите автозапуск следующей командой:
systemctl enable dumbproxyЗапустите сервис:
systemctl start dumbproxyПроверка: команда curl -x 'https://USERNAME:PASSWORD@DOMAIN' http://ifconfig.co должна выводить IP-адрес сервера.
Примечание: первый запрос может занять несколько секунд из-за выпуска сертификата.
Готово!
Настройка клиентов
Настройка прокси для всех браузеров на Windows
Откройте системные настройки прокси:
Включите опцию скрипта настройки и введите следующий код:
data:,function FindProxyForURL(u, h){return "HTTPS example.com:443";}где вместо example.com укажите ваш домен.
Использование в Firefox
Вариант 1. PAC-скрипт
Откройте настройки прокси в Firefox, переключите режим на "URL автоматической настройки" и введите следующий код:
data:,function FindProxyForURL(u, h){return "HTTPS example.com:443";}где вместо example.com следует написать ваш домен.
Вариант 2. Браузерное расширение для прокси
Воспользуйтесь любым удобным браузерным расширением для переключения прокси. Например, этим.
Вариант 3. Контейнеры файрфокс
Существует расширение Firefox Container Proxy, которое позволяет назначить разным контейнерам Firefox разные прокси. Таким образом, вы можете одновременно открывать один и тот же сайт из разных сетевых локаций. Лично я пользуюсь этим вариантом.
Использование в Chrome
Вариант 1. Параметр командной строки
Прокси-сервер можно передать опцией командной строки браузера Chrome. Например, так:
chromium-browser --proxy-server='https://example.com:443'где вместо example.com следует ваш домен.
Вариант 2. Браузерное расширение для прокси
Воспользуйтесь любым удобным браузерным расширением для переключения прокси. Например, этим.
Использование в Android
Установите AdGuard на Android: руководство.
Следуйте этому руководству, начиная с части про настройку приложения на Андроиде. Укажите тип прокси HTTPS, имя пользователя и пароль.
Использование с другими приложениями
Можно подключаться к удалённому HTTPS-прокси как к обычному локальному плэинтекстовому (нешифрованному) прокси при помощи приложения, которое принимает обычное соединение на локальном порту и дальше уже подключается через TLS к удалённому серверу. В качестве такого адаптера можно использовать steady-tun, который ещё вдобавок предварительно устанавливает соединения с запасом, скрадывая тем самым время установления каждого очередного TLS-соединения.
Комментарии (73)
JPEGEC
11.09.2022 04:44+14А в чем преимущество данного способа перед сокс5 прокси поднимаемое средствами "голого" ssh за 5 секунд?
Как минимум отпадает нужда в ерунде типа доменных имен.
NikaLapka
11.09.2022 05:33+2SSH сегодня работает, а завтра обновят DPI и уже не будет работать, или оставят 33.6 Kbps на соединение. Тот же l2tp, sstp уже некоторые операторы или блокируют или ограничивают. А HTTPS пока ещё свободен.
F0iL
11.09.2022 08:41+9Тот же l2tp, sstp уже некоторые операторы или блокируют или ограничивают.
SSTP работает поверх HTTPS и снаружи от него неотличим. Так что если цензоры уже научились на DPI выявлять SSTP (например с помощью того же active probing'а, т.к. endpoint там фиксированный и описан в протоколе), то легко точно так же вычислят и эту проксю.
Manrus
11.09.2022 11:06SSTP можно выявлять средствами обычного микротика. Достаточно проверять наличие sni заголовка в clienthello пакете. Если его нет, перед нами скорее всего sstp
Manrus
11.09.2022 13:20Те кто поставили минусы, поднимете sstp с самопопидсанными сертификатом без домена и посмотрите трафик через wireshark (как мне кажется 95% sstp настроено именно так )
F0iL
11.09.2022 14:11+3Это слишком радикальный метод с очень высокой вероятностью как false negatives, так и false positives.
Во-первых, вполне есть реализации клиентов SSTP, которые шлют SNI в хендшейшке, и вы их пропустите. Самая известная такая реализация - стандартный SSTP-клиент от Microsoft, который входит в любую современную версию Windows. Я на своей VPS-ке успешно разруливал клиентов к sstp-server'у и к nginx'у с помощью haproxy именно проверяя домен в SNI. Во-вторых, есть и клиенты протоколов, не имеющих отношение к VPN, которые работают поверх TLS и которые не шлют SNI, и вы их ошибочно заблокируете.
Как уже говорили, гораздо надёжнее выявлять SSTP-серверы active-probing'ом, а именно, делать к перехваченному адресу запрос типа 'SSTP_DUPLEX_POST /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/' и смотреть, вернёт ли он что-то осмысленное.
inkvizitor68sl
12.09.2022 17:13+1Или перед нами старый браузер/не очень старая Java. Ну или примерно любая заточенная под безопасность штуковина, которая решила куда-то сходить (считай всё, что касается банков, не посылает SNI - и сами банки приходят без SNI на хост).
Да и SSTP-клиентов уже сильно больше одного, некоторые SNI шлют.
sden77
11.09.2022 10:10+2Клиент голого ssh есть не на каждой системе, а клиент, который к тому же умеет сам коннектится и поддерживать соединение приёдтся устанавливать отдельно в любом случае. А данное решение не требует установки нового софта на клиенте, т.к. всё нужное уже есть в браузере
vikarti
11.09.2022 10:26+3У некоторых провайдеров с таким socks5 proxy какая то фигня творится — скорость не выше 2 мегабит и все тут.
hssergey
11.09.2022 07:16+2Если нет свободного доменного имени, то можно воспользоваться сервисом https://sslip.io/ , который автоматически формирует домен по ip адресу, например, у вас есть сервер с айпишником 1.2.3.4 , тогда можете считать, что у вас уже есть домены 1.2.3.4.ssip.io , www.1.2.3.4.ssip.io , www.1-2-3-4.sslip.io и www-1-2-3-4.sslip.io .
YourChief Автор
11.09.2022 13:50+1Здравствуйте! Я пробовал такое же с nip.io и скажу вам, что плохо получается. Рейтлимиты (https://letsencrypt.org/docs/rate-limits/) выпуска сертификатов общие на весь sslip.io и nip.io. Чтобы такого не было, владельцы этих доменов должны были добавиться в public suffix list и тогда рейтлимиты на каждый поддомен считались бы отдельно, но они этого не сделали.
На nip.io я по итогу получал вот такую ошибку:
Sep 09 20:23:35 clockinstall dumbproxy[3371]: HTTPSRV : 2022/09/09 20:23:35 server.go:3228: http: TLS handshake error from 46.250.24.40:45570: 429 urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many certificates already issued for: nip.io: see https://letsencrypt.org/docs/rate-limits/
lohmatij
11.09.2022 07:30+2Если кто нибудь напишет вариант подключения для iOS и Safari под MacOS, буду премного благодарен. Про PAC файлы в курсе, но хотелось бы что-то с более удобным включением/выключением и желательно с возможностью составлять списки сайтов для проксирования.
entze
13.09.2022 22:21Может покопать в сторону платных proxy клиентов типа ShadowRocket/LanceX/Pharos Pro
Плюс что они регулярно обновляются и функциональны. Но надо разбираться.
F0iL
11.09.2022 08:40Возможность прятать ответ прокси кодом 407, чтобы прокси не выдавал себя при активном опросе
Судя по описанию, оно будет выдавать 400 вместо 407 в случае, если в запросе подключения к прокси будет указан домен не из заданного списка. Учитывая, что даже в TLSv1.3 SNI-домен передается открытым текстом при хендшейшке и прекрасно просматривается на DPI, а ECH, который эту часть шифрует, пока что не поддерживается нормально ни в одном браузере, то защита, прямо скажем, так себе.
Для сравнения, тот же V2Ray работает через вебсокеты, и там для установления соединения нужно знать не только имя хоста прокси, но и URL, который является своеобразным секретным ключом и передается уже в полностью зашифрованном виде.
YourChief Автор
11.09.2022 13:54Нет, Вы не правы, потому что в SNI передаётся домен запрашиваемого сертификата прокси, а не самого запроса. Фильтр настраивается на выдачу 407 на секретный домен в запросе, который может и не существовать.
Учите матчасть.
F0iL
11.09.2022 14:19Но в браузере же задаётся только один адрес, домен из которого он подставит в SNI в хендшейк, в CONNECT-запрос, и для которого он проверит серверный сертификат, разве нет? Понятно, что в каастомном клиенте можно любую комбинацию навернуть, но интересует именно стандартный вариант с браузером.
Можете подробнее механизм рассказать? С конкретным примером, какой домен у вас будет прописан в фильтре прокси, какой домен прописан в конфигурации браузера, и для какого домена сгенерирован сертификат.
YourChief Автор
11.09.2022 14:37+1Если вы через HTTPS-прокси запрашиваете HTTPS-сайт, что там будет два разных TLS-хэндшейка, один между браузером и прокси, и второй между браузером и уже конечным сайтом. Снаружи просматривается SNI первого, внешнего TLS-соединения. Но дело не в них.
Скажем, если я поднял прокси на mycoolproxy.myvps.net и включил опцию прятать 407, то на все запросы без авторизации прокси будет отвечать 400. Браузеру будет невдомёк, что нужно запросить у пользователя логин и пароль и отправить его заголовком авторизации. Для этого опция поддерживает секретный "домен", который если запросить через прокси, то прокси ответит 407 и тогда триггернётся авторизация в браузере и он будет уже дальше благополучно всегда слать заголовок Proxy-Authorization. Скажем, если я настроил там какой-то несуществующий домен afdgfesrgsdfgdfsgsdf.com и запрошу его через браузер, это приведёт авторизацию в браузере в порядке.
Если нужно, я могу поднять один такой сервер и скинуть кренделя в личку, чтобы можно было потыкать.
YourChief Автор
11.09.2022 14:39Кстати, получается, что у меня сделано то же самое, что probe_resistance в плагине forwardproxy для Caddy: https://github.com/caddyserver/forwardproxy
F0iL
11.09.2022 14:49+1А, теперь понятно. Из изначального описания на гитхабе показалось, что идея фильтра в том, что он будет фильтровать только домен обращения к самому прокси (по SNI внешнего соединения, чтобы при попытке пролезть тупо по IP получать отлуп, например). Если же речь идёт именно о том, что после подключения к прокси нужно сделать CONNECT-запрос на специальный домен, и только после этого прокся выявит себя - тогда да, это должно работать, хорошая идея.
sardigital
11.09.2022 10:15-2dumbproxy умеет в chains ?
YourChief Автор
11.09.2022 14:27Можно научить, но особо не вижу полезного юзкейса. Если считаете, что нужно - пуллреквесты велкам!
sardigital
11.09.2022 14:51-1не вижу особого смысла брать этот продукт, среди других которые уже всё это умеют
borovinskiy
11.09.2022 11:04Аналогичную задачу можно решить поставив Nginx + Let's Encrypt перед HTTP-proxy.
Nginx слушает внешний порт по HTTPS и пересылает все на поднятый на localhost Squid уже в дешифрованном виде. Squid авторизует и делает все, для чего он обычно предназначен.
Такой вариант несколько лет вместе со Squid использую в задаче удаленного доступа к подписным ресурсам организации по IP, проблем не было.
MRD000
11.09.2022 12:27+1для nginx есть модуль, который поддерживает connect метод
borovinskiy
11.09.2022 13:12+1А можно чуть подробнее?
Не слышал, чтобы Nginx использовали в качестве прокси, так как умеет только в реверс-прокси. Дак таки можно и проксей?MRD000
11.09.2022 14:09Реверс или не реверс зависит просто от того куда коннектится сам прокси, правильно? точнее можно ли ему динамически сказать куда. В этом плане nginx очень гибкий, можно в proxy_pass указать куда коннектиться и в Host заголовке подправить, если что.
В стандартной установке nginx уже может работать как прокси, но только через URL. Но для https по-нормальному нужен CONNECT метод. Вот тут то модуль этот и помогает: https://github.com/chobits/ngx_http_proxy_connect_moduleborovinskiy
11.09.2022 14:31Что-то мне представляется не все таким простым.
Надо же не просто узнать куда за страницей сходить (это да), надо авторизовать (возможно из ldap или еще откуда), поднять на проксе сессию, закрыть сессию по таймауту, ACL многим хочется.
Вроде все по отдельности можно сделать, но хотелось бы увидеть конфиг Nginx, как это может выглядеть. Нет случаем такого?MRD000
11.09.2022 14:57Я сам не пользовался, просто рассматривал в какой-то момент варианты. Но в общем nginx достаточно гибкий, просто конфигурация там не очень всегда интуитивная или легко читаемая.
borovinskiy
11.09.2022 16:25Ну вот это проверить надо. Я в свое время не смог завести, чтобы именно в браузере работало. Здесь вон люди тоже с трудностями встречаются.
nidalee
11.09.2022 15:53+2В свое время несколько дней с ним провозился, так и не получилось заставить работать.
sden77
11.09.2022 18:23в инете куча гайдов по запросу nginx forward proxy, все они базируются на модуле ngx_http_proxy_connect_module, я присматриваюсь к этому решению, но пока не пытался его у себя реализовать.
borovinskiy
11.09.2022 18:39+1А я пытался. Но если кто-то не только пытался, но и таки смог (и чтоб с браузером совместимо, конечно), хотелось бы увидеть конфиг Nginx.
speicher
11.09.2022 13:51При https-proxy схеме голым остаётся процесс пересылки сертификатов и SNI, по этим данным провайдеры уже давно фильтруют твитеры и линкедины всякие.
MRD000
11.09.2022 15:08+1А разве у описаной схеме не получается https over https?
borovinskiy
11.09.2022 16:29Получается. Но если прокся в России стоит, то уже ее соединение под блокировку попадёт.
F0iL
11.09.2022 16:57Зависит от хостера. У некоторых российских хостеров исходящий трафик с VPS тоже фильтруется (видимо у кого-то из магистралов), а у некоторых полная вольница и можно смотреть всю запрещёнку даже с прокси в пределах страны.
Revertis
11.09.2022 17:56+3А кто в здравом уме прокси для хождения в Интернет будет держать в РФ?
vconst
11.09.2022 18:01Если понимать, что такой способ не анонимный, а всего лишь для обхода блокировок — то, вай нот?
Sergey_Cheban
11.09.2022 22:00Если живёшь за границей, то бывает нужно и такое:
Европа блокирует некоторые российские сайты.
Некоторые российские сайты закрылись от заграницы из-за DDOS'а.
Пиратствовать тоже лучше не напрямую из той страны, где живёшь.
DangerousAndMoving
11.09.2022 14:55Здравствуйте. В описании к steady-tun написано, Supports TLS SNI (server name indication) spoof. Как это сделать?
hidden_domain возможно использовать только с браузером? Я так понимаю, пустить телеграм или другую программу через прокси с таким флагом не получится?
YourChief Автор
11.09.2022 15:04Здравствуйте! Опция
-tls-servernameзадаёт то, что будет отправлено в SNI.DangerousAndMoving
11.09.2022 15:11Это я уже пробовал. Получаю ошибку: Upstream connection error: x509: certificate is valid for мой домен.com, not имя домена в tls-servername
YourChief Автор
11.09.2022 15:20так а сертификат тоже должен соответствовать, иначе смысл теряется - в Client Hello поменяли, а в Server Hello будет как есть. как вы хотите, чтобы было по итогу?
DangerousAndMoving
11.09.2022 15:26+1Понятно. Я просто ожидал, что это как в shsdowsocks + cloak. Задаёшь на сервере и клиенте любой домен, который не фильтруют.
hidden_domain возможно использовать только с браузером? Я так понимаю, пустить телеграм или другую программу через прокси с таким флагом не получится?
YourChief Автор
11.09.2022 15:27Получится, так как другие проги априори отправляют логин и пароль, если заданы - им не нужно триггерить 407 ответ, чтобы понять, что "пора".
YourChief Автор
11.09.2022 15:28+1Надо наверное сделать чтобы, коннектиться можно было на один домен, отправлять в SNI другой, а ожидать в сертификате третий. Добавлю себе заметку, чтобы сделать.
dmitry_dvm
11.09.2022 15:29А где на клиенте указывается логин-пароль, который вписывается в конфиг?
YourChief Автор
11.09.2022 15:38Если в браузере, или на всю систему, то в браузере всплывёт запрос логина и пароля. Если расширение для браузера, то в нём. Если Android, то в настройках прокси в адгарде.
dmitryvolochaev
11.09.2022 16:20-1На андроиде ни одно приложение для VPN не безопасно. Причина в том, что у андроида есть одна неприятная фича. Это именно фича, а не баг, так что жаловаться некуда. Помощи от Гугла не ждите. Фича заключается в том, что для освобождения памяти система останавливает приложения. Это не отключается и не настраивается. Приложения для VPN тоже попадают под раздачу. Так что в процессе просмотра сайта есть риск увидеть ошибку тика "контент недоступен в вашей стране", говорящую, что ваш трафик уже несколько секунд идет на прямую, и ваш айпи засвечен. Так-то вот
В андроиде есть встроенный VPN, который не является приложением. Вот его система без вашей команды не остановит. К сожалению, среди поддерживаемых им протоколов нет SSL/TLS
vconst
11.09.2022 16:27+3Да ладно, как раз в андроиде это все настраивается. Выставить для клиента «не закрывать», «не ограничивать память», «не экономить энергию» — и он будет неубиваемым. Да и при современных количествах памяти, когда ее не меньше, чем на среднем ноуте — это уже не актуально
Еще можно соединяться по встроенному в систему протоколу — его уже ничего из памяти не выгрузит
А вот на айфоне — система может вышибить из памяти любую прогу и настроить это абсолютно невозможно.entze
12.09.2022 10:11+1Прогу - возможно, но если это грамотно написанный VPN клиент, который еще и регистрируется в системе - то с чего?
vconst
12.09.2022 10:52На андроиде у меня никогда не вылетал впн клиент, никакой, ни шс, ни вг. А на айфоне полно было случаев, когда нужная мне в фоне прога — закрывалась системой. И это никак не исправить
entze
13.09.2022 10:52Еще раз, VPN клиент это условно интерфейс и сетевая библиотека. Интерфейс может и выгружается (он фактически всегда в памяти и не нужен), сетевая библиотека остается.
Посмотри Настройки - Основные - VPN - там перечислены все VPNы, даже с нестандартными протоколами. Ни разу не слышал и не видел, чтобы именно VPN выдавливался и трафик начинал идти через оператора.
SerJook
11.09.2022 16:58+1А можно поменять порт на другой?
При выполнении вашей инструкции с другим портом, выдает ошибку
HTTPSRV : 2022/09/11 16:36:12 server.go:3228: http: TLS handshake error from urn:ietf:params:acme:error:rateLimited: Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/
Пришлось поменять на стандартный 443, тогда все ок.Если нет, то что можно сделать, если 443 порт занимает nginx?
YourChief Автор
11.09.2022 18:02Можно поменять на другой, за это отвечает опция
-bind-address. По умолчанию выпуск серта идёт через валидацию домена по "tls-alpn-01", для чего нужно отвечать на порту 443. Если это не возможно, то можно валидироваться по "http-01" и тогда нужно, отвечая на запросы на порту 80. Для этого укажите опцию-autocert-http :80, и тогда демон будет слушать ещё порт 80 для ответа на челленджи на нём. Если и это не подходит и этот порт тоже занят, тогда выпускайте сертификаты как-то по-своему и указывайте путь к fullchain через опции-certи-key.
Bazis007
11.09.2022 17:48Проблема в том, что провайдер отлично видит SNI. По сути смысла в проксях сейчас не много.
F0iL
11.09.2022 17:54+1Выше уже разобрали: провайдер видит только SNI подключения к самой проксе, а не того, что ходит внутри TLS до нее. А у прокси есть специальный режим, когда она прикидывается тупым веб-сервером до момента когда клиент через нее сделает запрос на специальный секретный адрес.
vrb123
11.09.2022 18:03из текста не понял, letsencrypt даст сертификат на поддомен freemyip.com ?
YourChief Автор
11.09.2022 18:04На любой домен, который у вас привязан к виртуалке и через который вы запросили соединение. В руководстве как одна из возможностей используется домен, полученный через freemyip.
AlexGluck
Где были с этой статьей пару месяцев назад, очень бы помогло.