Gregory's Server
@top @ru_vpn "…- SNI по regexp (api|checkip|assets)\.[0-9a-f]{40}\.com, но при условии, что в имени зоны содержится хотя бы 5 цифр и 4 буквы. Т.е. https://api.abcdef0123456789abcdef012345678900000000.com заблокируется, но https://api.abc0000123456789222222012345678900000000.com — нет
Также он подметил, что метод с триггерами используется в том числе для выявления новых VPN-серверов, но если это и происходит, то не в атематическом режиме.
Таким образом получается, что в каком-то виде Active Probing уже минимум месяц работает в России точечно. Падение во вторник возможно было из-за попытки раскатать Active Probing в автоматическом режиме на весь рунет.”
________________
В сторону OVH (не знаю, только ли его, тестирую только на нём) работают некие пороговые фильтры, приводящие к обнаружению и ручной блокировке HTTPS-прокси.
Предположительно, сценарий следующий:
1. Большое количество соединений к одному IP-адресу и передача данных, похожих на HTTPS-прокси, вызывают срабатывание пороговых фильтров
2. Данные об IP-адресе отправляются оператору
3. Оператор, возможно, проводит ручную валидацию/проверку наличия прокси
4. Оператор блокирует IP-адрес
Выполняется это вручную ежедневно, только по будням. Блокировка происходит в 15-16 часов по Москве.
К отдельным диапазонам адресов (например, 178.32.137.0/24) более пристальное внимание, а другие (например, 94.23.69.0/24) пока, похоже, не отслеживают
_______________
https://ntc.party/t/блокировка-httphttps-в-сторону-linode-ovh-fastly-digital-ocean-scaleway/8029/41
@ru_vpn
________________
В сторону OVH (не знаю, только ли его, тестирую только на нём) работают некие пороговые фильтры, приводящие к обнаружению и ручной блокировке HTTPS-прокси.
Предположительно, сценарий следующий:
1. Большое количество соединений к одному IP-адресу и передача данных, похожих на HTTPS-прокси, вызывают срабатывание пороговых фильтров
2. Данные об IP-адресе отправляются оператору
3. Оператор, возможно, проводит ручную валидацию/проверку наличия прокси
4. Оператор блокирует IP-адрес