Если вы через HTTPS-прокси запрашиваете HTTPS-сайт, что там будет два разных TLS-хэндшейка, один между браузером и прокси, и второй между браузером и уже конечным сайтом. Снаружи просматривается SNI первого, внешнего TLS-соединения. Но дело не в них.
Скажем, если я поднял прокси на mycoolproxy.myvps.net и включил опцию прятать 407, то на все запросы без авторизации прокси будет отвечать 400. Браузеру будет невдомёк, что нужно запросить у пользователя логин и пароль и отправить его заголовком авторизации. Для этого опция поддерживает секретный "домен", который если запросить через прокси, то прокси ответит 407 и тогда триггернётся авторизация в браузере и он будет уже дальше благополучно всегда слать заголовок Proxy-Authorization. Скажем, если я настроил там какой-то несуществующий домен afdgfesrgsdfgdfsgsdf.com и запрошу его через браузер, это приведёт авторизацию в браузере в порядке.
Если нужно, я могу поднять один такой сервер и скинуть кренделя в личку, чтобы можно было потыкать.
Нет, Вы не правы, потому что в SNI передаётся домен запрашиваемого сертификата прокси, а не самого запроса. Фильтр настраивается на выдачу 407 на секретный домен в запросе, который может и не существовать.
Здравствуйте! Я пробовал такое же с 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/
А что б трафик не палился так, есть tls-crypt (правда поддержка не всеми клиентами пока реализована, например на routeros)
Скажем проще: в Китае это всё помогает? Если нет, то всё очевидно.
Если в доме (или хуже, в офисе) много компов, а еще есть мобильные устройства, то проще настраивать не каждый поштучно, пусть даже и скриптом или каким расширением, или pac файлом, а просто рулить на маршрутизаторе?
Попробуйте опцию WPAD в DHCP на том же маршрутизаторе.
В остальном - крайне капризный протокол, где нужно много настраивать руками, в т.ч. MTU, в противном случае тормозит адски. В режиме TCP тоже крайне плох из-за известной проблемы TCP-в-TCP. Ему пора на свалку истории это точно.
Правильно ли я понимаю, что единой точкой отказа может быть сервер балансировки, на котором работает nginx? Как лучше обеспечить защиту от отказа этого сервера?
Вывод напрашивается крайне простой, что для прям безопасности, надо делать свой openvpn сервер, на своей виртуалке
OpenVPN - пережиток прошлого и самый убогий VPN, какой сегодня есть. Кроме того, к безопасности сервисов отношения не имеет: то что они не умеют применять криптопротоколы не значит, что все сервисы страдают тем же. Не нужно размазывать их случай на всех остальных.
А если кому полистать инсту и посмотреть ролики иностранных сми, так этого решения должно хватить и бесплатно.
Согласился бы с этим утверждением при одном условии: что пользователям будет известен весь расклад наперёд, а не как у них сейчас написано на сайте, что шифрование - высший класс!
2 - ну, например в РФ вам потребуется лицензия сетевого оператора для этого. Что проще, получить AS, блок адресов, пириться с кем-то или просто установить демон на две виртуалки? Как по мне так вообще даже не сравнимо.
DNS failover к высокой доступности имеет отношение весьма опосредованное из-за кэширования промежуточными DNS-серверами
И всё-таки имеет прямое отношение.
Более того, этот файловер работает гораздо медленее, чем просто перебор A-записей клиентом.
Нет. Может быть разве что при условии, что 1. клиент перебирает адреса (что обычно так для HTTP-клиентов, но в общем случае это не так), 2. Сбойный сервер будет не таймаутить, а слать TCP-reset.
Более того, в случае отказа предложенная мной схема через ~30 секунд приведёт всё в норму для всех без дополнительных задержек на каждый запрос, а схема с перебором A-записей так и будет таймаутить для части запросов.
Кстати, получается, что у меня сделано то же самое, что probe_resistance в плагине forwardproxy для Caddy: https://github.com/caddyserver/forwardproxy
Если вы через HTTPS-прокси запрашиваете HTTPS-сайт, что там будет два разных TLS-хэндшейка, один между браузером и прокси, и второй между браузером и уже конечным сайтом. Снаружи просматривается SNI первого, внешнего TLS-соединения. Но дело не в них.
Скажем, если я поднял прокси на mycoolproxy.myvps.net и включил опцию прятать 407, то на все запросы без авторизации прокси будет отвечать 400. Браузеру будет невдомёк, что нужно запросить у пользователя логин и пароль и отправить его заголовком авторизации. Для этого опция поддерживает секретный "домен", который если запросить через прокси, то прокси ответит 407 и тогда триггернётся авторизация в браузере и он будет уже дальше благополучно всегда слать заголовок Proxy-Authorization. Скажем, если я настроил там какой-то несуществующий домен afdgfesrgsdfgdfsgsdf.com и запрошу его через браузер, это приведёт авторизацию в браузере в порядке.
Если нужно, я могу поднять один такой сервер и скинуть кренделя в личку, чтобы можно было потыкать.
Можно научить, но особо не вижу полезного юзкейса. Если считаете, что нужно - пуллреквесты велкам!
А скиньте ссылочку, пожалуйста.
Да, 400
Нет, Вы не правы, потому что в SNI передаётся домен запрашиваемого сертификата прокси, а не самого запроса. Фильтр настраивается на выдачу 407 на секретный домен в запросе, который может и не существовать.
Учите матчасть.
Здравствуйте! Я пробовал такое же с nip.io и скажу вам, что плохо получается. Рейтлимиты (https://letsencrypt.org/docs/rate-limits/) выпуска сертификатов общие на весь sslip.io и nip.io. Чтобы такого не было, владельцы этих доменов должны были добавиться в public suffix list и тогда рейтлимиты на каждый поддомен считались бы отдельно, но они этого не сделали.
На nip.io я по итогу получал вот такую ошибку:
Скажем проще: в Китае это всё помогает? Если нет, то всё очевидно.
Попробуйте опцию WPAD в DHCP на том же маршрутизаторе.
Да это практически один в один из документации: http://nginx.org/en/docs/http/load_balancing.html
И кому этот L2 нужен? Если кому-то и понадобится L2-туннель, едва ли он прибегнет к использованию именно OpenVPN.
sslh? Не имеет смысла, трафик всё равно выглядит как OpenVPN.
В режиме TCP, через внешние врапперы? Оно же тормозит.
Я из адептов обычных HTTP-прокси через TLS: https://habr.com/ru/post/506356/
В остальном - крайне капризный протокол, где нужно много настраивать руками, в т.ч. MTU, в противном случае тормозит адски. В режиме TCP тоже крайне плох из-за известной проблемы TCP-в-TCP. Ему пора на свалку истории это точно.
Да. Есть вот такой простенький вариант как раз для такого случая: https://habr.com/ru/post/683770/
Да: http://nginx.org/en/docs/http/load_balancing.html#nginx_load_balancing_health_checks. Впрочем, об этом и в статье написано.
Не Псион, а Псифон.
OpenVPN - пережиток прошлого и самый убогий VPN, какой сегодня есть. Кроме того, к безопасности сервисов отношения не имеет: то что они не умеют применять криптопротоколы не значит, что все сервисы страдают тем же. Не нужно размазывать их случай на всех остальных.
Согласился бы с этим утверждением при одном условии: что пользователям будет известен весь расклад наперёд, а не как у них сейчас написано на сайте, что шифрование - высший класс!
Непонятно, я пока так и не понял, откуда соль берётся: https://shadowsocks5.github.io/en/spec/AEAD-Ciphers.html
Я почтальон Печкин, принёс вам заметку про вашего мальчика: https://habr.com/ru/post/684676/
А, вижу, что новые
Не совсем понятно, это новые подключения или старые keepalive-сессии?
2 - ну, например в РФ вам потребуется лицензия сетевого оператора для этого. Что проще, получить AS, блок адресов, пириться с кем-то или просто установить демон на две виртуалки? Как по мне так вообще даже не сравнимо.
И всё-таки имеет прямое отношение.
Нет. Может быть разве что при условии, что 1. клиент перебирает адреса (что обычно так для HTTP-клиентов, но в общем случае это не так), 2. Сбойный сервер будет не таймаутить, а слать TCP-reset.
Более того, в случае отказа предложенная мной схема через ~30 секунд приведёт всё в норму для всех без дополнительных задержек на каждый запрос, а схема с перебором A-записей так и будет таймаутить для части запросов.
На хабре, кстати, тоже есть статьи про него: https://habr.com/ru/post/122238/
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html