URL автоматической настройки такой же, как и в других случаях. Разница только в том, что чтобы браузер начал отправлять логин и пароль нужно сначала посетить в браузере страницу этого самого hidden_domain, тогда всплывёт окно с запросом логина и пароля, браузер запомнит и будет дальше отправлять.
То есть hidden_domain это опция, которая говорит прокси не отвечать кодом 407 для требования авторизации на всех доменах кроме одного секретного. 407ой код ответа нужен только браузерам, который логин и пароль к прокси не отправляют до явного требования со стороны прокси.
Либо, в качестве альтернативного варианта, можно просто запустить на клиенте локально dumbproxy и ему опцией -proxy указать уже URL dumbproxy на сервере, чтобы dumbproxy на клиенте всегда отправлял логин и пароль. Т.е. использовать цепь: браузер -> локальный dumbproxy без пароля -> удалённый dumbproxy с паролем и hidden_domain -> интернет.
Ответил ниже. Можете ещё с nginx или haproxy поиграться, поставив его на фронт с реальным сайтом, а dumbproxy сделав одним из бекендов. Но в целом оно и само по себе достаточно правдоподобно, особенно если защиту от active probing включить. Из плюсов что это стандартный протокол и можно настроить клиент без какого-то дополнительного софта.
Из плюсов то, что это стандартный протокол и можно им пользоваться даже без какого-либо клиента.
Насчёт а) тут всё очевидно, это вполне себе HTTPS.
Насчёт б) доступно несколько опций:
Парольная авторизация, но с использованием опции hidden_domain, чтобы запрашивать пароль 407-ым статусом только на "секретном" домене, а дальше уже браузер запомнит его и будет всегда слать. То есть вы добавляете в опции авторизации hidden_domain=abracadabra.tld и ставите у себя в браузере этот прокси в настройках. На все запросы без заголовка авторизации прокси будет отвечать 400-ым кодом, но на запрос секретного домена прокси ответит 407-ым статусом, браузер спросит пароль и дальше всегда будет слать авторизационные заголовки.
Парольная авторизация, но с клиентом прокси, который всегда шлёт пароль (в виде заголовков авторизации). Например, адгард так умеет. Либо сам dumbproxy запускать на клиенте локально, а он уже пускай дальше форвардит соединение с заголовками авторизации в dumbproxy на сервере.
Авторизация по клиентским сертификатам TLS. Тут удобнее всего воспользоваться steady-tun или каким другим TLS-враппером, а браузер настроить на плэинтекстовый порт враппера.
Сначала люди себе придумывают, что целые числа в компьютере это целые числа из математики, а потом удивляются, что это не так. А задать вопрос, кто вас так жестоко обманул, не пробовали?
Целые числа в компьютере из математики, и автор посвятил статью описанию из какой именно математики.
Обманул не то что вместо одних чисел подсунул другие, а в том что убедил что в компьютере должна быть реализована математическая теория не через программы, а сразу встроено, чтоб программист сразу общался с компьютером теоремами, прямо на уровне железа.
Демагогический приём подмены тезиса. Автор не высказывал подобных ожиданий.
Всё бы ничего, но выставлять своё непонимание как критику — это уже слишком.
Автор как раз всё понял и разъяснил. А Вы-то суть прочитанного поняли?
А ещё вот так сильно разбавив математикой как водой, это даже тянет на оскорбление математики. Ей всё равно, а вот читателям неприятно
Говорите за себя.
А ещё вот так сильно разбавив математикой как водой, это даже тянет на оскорбление математики. Ей всё равно, а вот читателям неприятно. У меня ощущения как будто читал ссору между недоматематиком и недопрограммистом.
А точнее — они были на одной стороне конфликта.
В Вашем комментарии 0 фактов, демагогия и хамство. Отвратительно.
Да, это как раз моя статья. Этот метод полностью перестанет работать в 28 ноября, потому что Heroku закрывает бесплатные продукты.
Надо заметить, что упомянутую возню с доменами и сертификатами берёт на себя PaaS - а так они всё равно требуются. В статье выше описано как всё проделать за минуты, при том без завязки на какой-то конкретный PaaS.
На любой домен, который у вас привязан к виртуалке и через который вы запросили соединение. В руководстве как одна из возможностей используется домен, полученный через freemyip.
Можно поменять на другой, за это отвечает опция -bind-address. По умолчанию выпуск серта идёт через валидацию домена по "tls-alpn-01", для чего нужно отвечать на порту 443. Если это не возможно, то можно валидироваться по "http-01" и тогда нужно, отвечая на запросы на порту 80. Для этого укажите опцию -autocert-http :80, и тогда демон будет слушать ещё порт 80 для ответа на челленджи на нём. Если и это не подходит и этот порт тоже занят, тогда выпускайте сертификаты как-то по-своему и указывайте путь к fullchain через опции -cert и -key.
Если в браузере, или на всю систему, то в браузере всплывёт запрос логина и пароля. Если расширение для браузера, то в нём. Если Android, то в настройках прокси в адгарде.
Надо наверное сделать чтобы, коннектиться можно было на один домен, отправлять в SNI другой, а ожидать в сертификате третий. Добавлю себе заметку, чтобы сделать.
На сервере вот так:
или
URL автоматической настройки такой же, как и в других случаях. Разница только в том, что чтобы браузер начал отправлять логин и пароль нужно сначала посетить в браузере страницу этого самого hidden_domain, тогда всплывёт окно с запросом логина и пароля, браузер запомнит и будет дальше отправлять.
То есть hidden_domain это опция, которая говорит прокси не отвечать кодом 407 для требования авторизации на всех доменах кроме одного секретного. 407ой код ответа нужен только браузерам, который логин и пароль к прокси не отправляют до явного требования со стороны прокси.
Либо, в качестве альтернативного варианта, можно просто запустить на клиенте локально dumbproxy и ему опцией -proxy указать уже URL dumbproxy на сервере, чтобы dumbproxy на клиенте всегда отправлял логин и пароль. Т.е. использовать цепь: браузер -> локальный dumbproxy без пароля -> удалённый dumbproxy с паролем и hidden_domain -> интернет.
Не совсем VPN, но бесплатно. Попробуйте вот это: https://github.com/Snawoot/opera-proxy
Пост на хабре про него: https://habr.com/ru/articles/555368/
Ну или его же можно использовать для обёртывания соединения OpenVPN какого-нибудь на tcp-порт.
Ответил ниже. Можете ещё с nginx или haproxy поиграться, поставив его на фронт с реальным сайтом, а dumbproxy сделав одним из бекендов. Но в целом оно и само по себе достаточно правдоподобно, особенно если защиту от active probing включить. Из плюсов что это стандартный протокол и можно настроить клиент без какого-то дополнительного софта.
Подойдёт и обычный HTTPS-прокси типа такого: https://github.com/Snawoot/dumbproxy
Из плюсов то, что это стандартный протокол и можно им пользоваться даже без какого-либо клиента.
Насчёт а) тут всё очевидно, это вполне себе HTTPS.
Насчёт б) доступно несколько опций:
Парольная авторизация, но с использованием опции hidden_domain, чтобы запрашивать пароль 407-ым статусом только на "секретном" домене, а дальше уже браузер запомнит его и будет всегда слать. То есть вы добавляете в опции авторизации hidden_domain=abracadabra.tld и ставите у себя в браузере этот прокси в настройках. На все запросы без заголовка авторизации прокси будет отвечать 400-ым кодом, но на запрос секретного домена прокси ответит 407-ым статусом, браузер спросит пароль и дальше всегда будет слать авторизационные заголовки.
Парольная авторизация, но с клиентом прокси, который всегда шлёт пароль (в виде заголовков авторизации). Например, адгард так умеет. Либо сам dumbproxy запускать на клиенте локально, а он уже пускай дальше форвардит соединение с заголовками авторизации в dumbproxy на сервере.
Авторизация по клиентским сертификатам TLS. Тут удобнее всего воспользоваться steady-tun или каким другим TLS-враппером, а браузер настроить на плэинтекстовый порт враппера.
Пост на хабре про dumbproxy: https://habr.com/ru/articles/687512/
А зачем знать людей, которые через три ряда сидят? Разве что по работе необходимо.
А семью свою заводить надо, а не предоставленную (а иногда и навязанную под соусом "мы все одна семья") работодателем принимать.
Целые числа в компьютере из математики, и автор посвятил статью описанию из какой именно математики.
Демагогический приём подмены тезиса. Автор не высказывал подобных ожиданий.
Автор как раз всё понял и разъяснил. А Вы-то суть прочитанного поняли?
Говорите за себя.
В Вашем комментарии 0 фактов, демагогия и хамство. Отвратительно.
Так вы и даже сейчас можете создать торрент без трекеров и анонсировать его только в DHT.
Скажите, пожалуйста, а как так у Вас именованные параметры у функций работают? В вашем коде:
Однако, даже передовая версия компилятора Go не допускает такого синтаксиса: https://go.dev/play/p/OgWVn9Tkc8i?v=gotip
Такое же тогда можно и про ansible сказать.
А какая здесь софтина от Cloudflare?
Наверное через DNS-01 челлендж разве что провалидировать домен и выпустить серт.
В целом будет на другом порту, но сертификат автоматически выпустить не получится - придётся как-то иначе придумывать.
Да, это как раз моя статья. Этот метод полностью перестанет работать в 28 ноября, потому что Heroku закрывает бесплатные продукты.
Надо заметить, что упомянутую возню с доменами и сертификатами берёт на себя PaaS - а так они всё равно требуются. В статье выше описано как всё проделать за минуты, при том без завязки на какой-то конкретный PaaS.
Разумная жизнь вышла из воды, в неё и вернётся...
На любой домен, который у вас привязан к виртуалке и через который вы запросили соединение. В руководстве как одна из возможностей используется домен, полученный через freemyip.
Можно поменять на другой, за это отвечает опция
-bind-address. По умолчанию выпуск серта идёт через валидацию домена по "tls-alpn-01", для чего нужно отвечать на порту 443. Если это не возможно, то можно валидироваться по "http-01" и тогда нужно, отвечая на запросы на порту 80. Для этого укажите опцию-autocert-http :80, и тогда демон будет слушать ещё порт 80 для ответа на челленджи на нём. Если и это не подходит и этот порт тоже занят, тогда выпускайте сертификаты как-то по-своему и указывайте путь к fullchain через опции-certи-key.Если в браузере, или на всю систему, то в браузере всплывёт запрос логина и пароля. Если расширение для браузера, то в нём. Если Android, то в настройках прокси в адгарде.
Надо наверное сделать чтобы, коннектиться можно было на один домен, отправлять в SNI другой, а ожидать в сертификате третий. Добавлю себе заметку, чтобы сделать.
Получится, так как другие проги априори отправляют логин и пароль, если заданы - им не нужно триггерить 407 ответ, чтобы понять, что "пора".