В книге Виктора Суворова «Аквариум», которая впервые вышла в 1985 году, упоминалось снятие звука лазером с оконного стекла, так и стёкла с особыми отражающими свойствами, которые этому препятствуют. Выходит, это направление совсем не новое и давно имеет реальные применения. И, действительно, наверняка за 35 лет прогресс в этом деле давно шагнул вперёд.
Представленные реализации, скорее некий Proof of Concept, на основе которого можно допилить ту или иную реализацию по своим требованиям.
Proof of Concept из документации? Звучит инновационненько.
Касаемо лока в цикле — это стандартный механизм retry.
Стандартный для чего? Наличие активного опроса по сети в приложении — существенный недостаток и что угодно, но точно не стандарт. И для взятия локов в частности. Посмотрите, как выглядит взятие распределённого лока с использованием Consul, например.
Если посмотреть на внутренности готовых реализаций по Вашей ссылке, там будет ретрай лока также выставляться в цикле.
Поэтому я пишу:
Но лучше что-то ещё поискать, редис для этого очень слабо подходит.
Даже если Вы на чём Вам удобно напишете сетевой демон, который будет принимать две команды lock и unlock, и при этом не отправлять ответ на lock пока он уже не взят, то это будет уже существенно лучше, чем то решение на редисе. На чём-то однопоточном и асинхронном это реализовать тривиально. Но лучше использовать что-то наподобие консула.
По поводу rate limiter так же может быть большее количество различных реализаций, в моем посте представлен базовый вариант, который решает большую часть кейсов. Если же вам нужно что-то более кастомное и сложное, с равномерным распределением нагрузки — можно реализовать более сложные алгоритмы.
Что это за рэйтлимит, если он не имеет этой самой функции разравнивания мгновенной частоты запросов? Какой такой кейс он решает, каких «большинство»?
Бывают реализации хорошие, бывают не очень. Об этом и был весь мой пассаж с предложением лучших готовых решений.
Рецепты скорее вредные, чем полезные. Я понимаю, что они по сути все взяты с сайта документации Redis или с Redis Labs и предложены там как каноничные паттерны, но в результате просто получается скверная реализация.
Мьютексы тоже странные: лок нужно получать в цикле, это крайне неэффективно. Сам метод тоже предложен в документации к Redis: https://redis.io/commands/set#patterns. Однако там же рекомендуют не изобратать велосипед, а использовать готовые реализации локов на редисе для различных языков. Но лучше что-то ещё поискать, редис для этого очень слабо подходит.
Rate limiter взят вот отсюда: https://redislabs.com/redis-best-practices/basic-rate-limiting/. Проблема с ним в том, что это никакой не рэйтлимитер, это буквально ограничение числа запросов в какой-то определённый временной интервал, а не ограничение частоты запросов. К примеру, все запросы могут придти в первые секунды временного отрезка и все они будут взяты в работу, а оставшееся время бэкенд будет сидеть без дела. А потом, в следующий временной интервал, бэкенд снова будет готов вычерпать весь лимит в первые мгновения.
То есть, он просто делает не то, что нужно. Правильная реализация должна использовать что-нибудь вроде алгоритма leaky bucket. В nginx это реализовано корректно, лучше пользоваться им для этих целей.
Вы не поняли: речь шла о связке shadowsocks+v2ray, вы же ее назвали «велосипедом». Сам shadowsocks отлично и шифрует, и мультиплексирует, и скорость не режет, и работает на всех платформах.
Так про мобильные клиенты: есть или нет? Получается какое-то половинчатое решение у вас.
Сам он не отлично шифрует и легко провалился. А при зависимости от TLS он и не нужен как протокол. Да, клиенты shadowsocks на телефоны сейчас есть, для HTTPS-прокси тоже есть, но плохие. Тем не менее, это не отменяет ущербности shadowsocks как протокола.
Докажите наличие active probing в России.
Я такого утверждения не делал, но при этом не считаю правильным дожидаться, когда active probing появится. А Вам своё заявление подкрепить нечем, я так понимаю?
Я конечно читал, вот только это не актуально для России. Для Китая — да, для России — нет. Это китайцам приходится прорываться сквозь Золотой щит, это у них прокси обнаруживаются с помощью зондирования и блокируются. У нас такой проблемы нет. У вас несколько надуманная модель угроз.
Ну значит тогда в России и shadowsocks не нужен, так получается?
А что, если я скажу, что вы со своими прокси не защищены от атак сопоставлением?
Что же касается shadowsocks с v2ray-плагином — в режиме HTTP он так же подвержен активным пробам, потому что сторонний наблюдатель так же сможет воспроизвести то, что видел в открытых фрэймах вебсокета.
В режиме HTTPS всё вроде бы неплохо, но возникает вопрос: а зачем сам shadowsocks в этой схеме, если сокрытие начала диалога возложено на TLS? Вот он и есть как раз велосипед, в итоге, который сам по себе провалился с точки зрения цензуроустойчивости, но может использоваться под TLS. А под TLS и стандартный HTTP-прокси отлично работает, который в браузерах из коробки поддерживается.
На андроиде есть клиент HTTPS-прокси Drony, который имитирует VPN и может заворачивать все TCP-соединения любых приложений через прокси. Но он не очень удобный, его муторно настраивать и я пока так и не понял, как заставить его не отправлять DNS-запросы напрямую.
Есть ещё системная настройка прокси в Андроиде, но это вариант нерабочий по сути: какие-то приложения будут посылать какую-то часть трафика через прокси, что-то будет идти напрямую.
Лучшее, что доступно на андроиде и нормально работает — это VPN-клиент Wireguard. Возможно, если у меня наберётся достаточно материала, я напишу пост про то, как можно использовать Wireguard и получить дополнительные преимущества по скорости как у прокси путём прозрачного проксирования TCP-соединений на сервере Wireguard.
Прошлый раз, когда я тестировал CF, там не работал OCSP Stapling и от браузера плэйнтекстом шёл запрос OCSP с серийным номером сертификата, по которому можно узнать, какой это домен. Сейчас, вроде, всё нормально, но я не тестировал повторно.
Существуют VPN, которые работают так же через «обычный» TLS — например, SoftEther, AnyConnect/OpenConnect и SSTP и со стороны DPI видны как обычный HTTPS. С помощью некоторых трюков можно так же заставить отвечать вместо них безобидный веб-сайт, чтобы избежать active probing.
Вопрос только в том, как это сделать.
Я экспериментировал с SSTP и ставил перед сервером haproxy, который в начальном состоянии маршрутизирует входящее соединение на веб-сервер (который тоже встроен в haproxy). При поступлении особого запроса (который извне не читаем из-за TLS) он запоминает адрес клиента и дальше маршрутизирует соединения от него на SSTP-бэкенд. Получилась примерно такая конфигурация:
Решение всё равно получается неполноценное, потому что если активные пробы осуществляются с того же адреса, с которого приходит клиент, то всё равно можно будет увидеть начало диалога SSTP после того, как клиент пошлёт секретный запрос. Но, тем не менее, это уже кое-что и такой сервер будет работать со стандартным SSTP в винде. Чтобы это работало полноценно, такое переключение должно происходить в рамках одного соединения, а со стандартными клиентами SSTP такого добиться не получится.
И даже если это всё проделать, на выходе получится тормозной VPN, работающий через один TCP-коннект.
Решается настройкой маршрутов — удаляется дефолтный роут в системе, прописывается дефолтный роут на шлюз внутри VPN, и отдельный маршрут до VPN-сервера. Тогда при падении туннеля доступ во внешнюю сеть прекращается полностью до возобновления соединения.
Да, эта проблема решаемая. Кроме этой, есть ещё проблема с DNS leak, в особенности на винде: VPN-клиент добавляет свои DNS-серверы, но винда может пройтись по всем сконфигурированным DNS-серверами, посылая запрос мимо туннеля в DNS-сервер в локальной сети. А у прокси всех этих проблем просто нет.
Не нашел в вашей инструкции по конфигурированию клиентов dumbproxy ничего про клиентские сертификаты, можно подробнее?
Сначала нужно сгенерировать сертификаты для клиентов. Я обычно использую свой же quickcerts. Затем на сервере нужно указать параметры -cert, -key, -cafile, где сертификат и ключ — любой ваш сертификат для TLS, а cafile — сертификат CA, которым выпущены серты для клиентов. Кроме этого, нужно выставить параметр -auth в значение cert://
Далее есть два варианта:
Установить клиентский сертификат прямо в браузер и дальше настройка как обычно. У меня в Firefox и вроде бы даже в Chrome это работало, но я наблюдал кое-какие странности в поведении браузеров.
Запустить steady-tun или ptw на клиенте, указав в нём клиентский сертификат и адрес сервера, а браузер уже настроить на подключение к локальному порту steady-tun или ptw как к обычному HTTP-прокси без TLS.
Поддержка HTTP/2 между клиентом и прокси, и между прокси и целевым веб-сервером.
Есть возможность прятать 407ой ответ, чтобы не давать обнаруживать прокси.
Есть аутентификация клиентов по сертификатам.
Нет кэширования, ненужной буферизации ответов, добавления заголовков Via и X-Forwarded-For. Клиент через dumbproxy начинает получать ответ как можно более оперативно и его не нужно долго и внимательно конфигурировать, чтобы он просто «тупо» форвардил трафик без лишних действий. Он только под это заточен изначально. Проще настроить.
Возможность развёртывания на почти любой платформе/ОС путём запуска единственного статически слинкованного исполняемого файла.
Иными словами, squid это вебкэш из эпохи, когда они были актуальны, а моё решение узкоспециализировано под задачу из поста. Но squid, конечно, имеет массу других возможностей, это большой «комбайн».
DuckDuckGo так же данными может торговать, а qwant маловероятно — они заявляют, что торгуют самой технологией поисковика.
Там и описание, и реализация на Postfix-е в обе стороны (публикация политики и применение политик других доменов).
Стандартный для чего? Наличие активного опроса по сети в приложении — существенный недостаток и что угодно, но точно не стандарт. И для взятия локов в частности. Посмотрите, как выглядит взятие распределённого лока с использованием Consul, например.
Поэтому я пишу:
Даже если Вы на чём Вам удобно напишете сетевой демон, который будет принимать две команды lock и unlock, и при этом не отправлять ответ на lock пока он уже не взят, то это будет уже существенно лучше, чем то решение на редисе. На чём-то однопоточном и асинхронном это реализовать тривиально. Но лучше использовать что-то наподобие консула.
Что это за рэйтлимит, если он не имеет этой самой функции разравнивания мгновенной частоты запросов? Какой такой кейс он решает, каких «большинство»?
Бывают реализации хорошие, бывают не очень. Об этом и был весь мой пассаж с предложением лучших готовых решений.
Очередь ещё более-менее, хотя и без подтверждений. В самой документации к Redis описано, как делать правильно: redis.io/commands/rpoplpush#pattern-reliable-queue
Мьютексы тоже странные: лок нужно получать в цикле, это крайне неэффективно. Сам метод тоже предложен в документации к Redis: https://redis.io/commands/set#patterns. Однако там же рекомендуют не изобратать велосипед, а использовать готовые реализации локов на редисе для различных языков. Но лучше что-то ещё поискать, редис для этого очень слабо подходит.
Rate limiter взят вот отсюда: https://redislabs.com/redis-best-practices/basic-rate-limiting/. Проблема с ним в том, что это никакой не рэйтлимитер, это буквально ограничение числа запросов в какой-то определённый временной интервал, а не ограничение частоты запросов. К примеру, все запросы могут придти в первые секунды временного отрезка и все они будут взяты в работу, а оставшееся время бэкенд будет сидеть без дела. А потом, в следующий временной интервал, бэкенд снова будет готов вычерпать весь лимит в первые мгновения.
То есть, он просто делает не то, что нужно. Правильная реализация должна использовать что-нибудь вроде алгоритма leaky bucket. В nginx это реализовано корректно, лучше пользоваться им для этих целей.
Я такого утверждения не делал, но при этом не считаю правильным дожидаться, когда active probing появится. А Вам своё заявление подкрепить нечем, я так понимаю?
Сказать-то легко, доказать трудно.
Что же касается shadowsocks с v2ray-плагином — в режиме HTTP он так же подвержен активным пробам, потому что сторонний наблюдатель так же сможет воспроизвести то, что видел в открытых фрэймах вебсокета.
В режиме HTTPS всё вроде бы неплохо, но возникает вопрос: а зачем сам shadowsocks в этой схеме, если сокрытие начала диалога возложено на TLS? Вот он и есть как раз велосипед, в итоге, который сам по себе провалился с точки зрения цензуроустойчивости, но может использоваться под TLS. А под TLS и стандартный HTTP-прокси отлично работает, который в браузерах из коробки поддерживается.
Есть ещё системная настройка прокси в Андроиде, но это вариант нерабочий по сути: какие-то приложения будут посылать какую-то часть трафика через прокси, что-то будет идти напрямую.
Лучшее, что доступно на андроиде и нормально работает — это VPN-клиент Wireguard. Возможно, если у меня наберётся достаточно материала, я напишу пост про то, как можно использовать Wireguard и получить дополнительные преимущества по скорости как у прокси путём прозрачного проксирования TCP-соединений на сервере Wireguard.
Я экспериментировал с SSTP и ставил перед сервером haproxy, который в начальном состоянии маршрутизирует входящее соединение на веб-сервер (который тоже встроен в haproxy). При поступлении особого запроса (который извне не читаем из-за TLS) он запоминает адрес клиента и дальше маршрутизирует соединения от него на SSTP-бэкенд. Получилась примерно такая конфигурация:
frontend sstp
bind 10.19.0.5:443 ssl crt /etc/haproxy/example.com.combined.pem
acl allowed src,map_ip(/etc/haproxy/wl_map.txt) 1
use_backend sstp-server if allowed
default_backend sstp-decoy
backend sstp-decoy
server decoy 127.0.0.1:41720 send-proxy-v2
frontend sstp-decoy
bind 127.0.0.1:41720 accept-proxy
mode http
http-request set-map(/etc/haproxy/wl_map.txt) %[src] 1 if { path /mysecretlocation }
http-request deny deny_status 400
backend sstp-server
server sstp 127.0.0.1:4433
Решение всё равно получается неполноценное, потому что если активные пробы осуществляются с того же адреса, с которого приходит клиент, то всё равно можно будет увидеть начало диалога SSTP после того, как клиент пошлёт секретный запрос. Но, тем не менее, это уже кое-что и такой сервер будет работать со стандартным SSTP в винде. Чтобы это работало полноценно, такое переключение должно происходить в рамках одного соединения, а со стандартными клиентами SSTP такого добиться не получится.
И даже если это всё проделать, на выходе получится тормозной VPN, работающий через один TCP-коннект.
Да, эта проблема решаемая. Кроме этой, есть ещё проблема с DNS leak, в особенности на винде: VPN-клиент добавляет свои DNS-серверы, но винда может пройтись по всем сконфигурированным DNS-серверами, посылая запрос мимо туннеля в DNS-сервер в локальной сети. А у прокси всех этих проблем просто нет.
Сначала нужно сгенерировать сертификаты для клиентов. Я обычно использую свой же quickcerts. Затем на сервере нужно указать параметры
-cert,-key,-cafile, где сертификат и ключ — любой ваш сертификат для TLS, а cafile — сертификат CA, которым выпущены серты для клиентов. Кроме этого, нужно выставить параметр-authв значениеcert://Далее есть два варианта:
Иными словами, squid это вебкэш из эпохи, когда они были актуальны, а моё решение узкоспециализировано под задачу из поста. Но squid, конечно, имеет массу других возможностей, это большой «комбайн».