А много это сколько? VPN редко отключаю.
я не работаю в ркн как бы мое имя не выглядело, но вот есть интересная статья про иран https://raw.githubusercontent.com/irgfw/irgfw-website/ad91766f62b8b666eb705a5d90136bba0f72fc42/static/files/project1/IRGFW-Report1-English.pdf
Summary
Time Pattern
We have identified specific patterns related to block timings. The TIC primary firewall synchronizes daily at 6:00 AM and 12:00 PM (UTC+03:30).
Consequently, when referring to a TIC firewall test, it implies that the TIC will block the servers exclusively during these synchronization periods. In
contrast, the MCI firewall may block an IP address or domain at any time during the day, following its time-based patterns.
For clarity, "moderate" traffic is defined as symmetrical traffic of 100 Mbps on the server.
• Time pattern 1: 4h - 1d - 4d - 1w - 40d
• Time pattern 2: 1h - 4h - 2d - 2w - 40d
1. Time Pattern 1: Set up a proxy server with Xray-core like VLESS-TCP-Reality(Vision) (Combination is unimportant). Flow some moderate traffic on it. If
the IP address didn’t block after 4 hours, it will likely work for 1 day (The TIC firewall test). If the IP has not been blocked, it will likely work for 4 days
(Another TIC firewall test). And if it is not blocked yet, it will probably go for 1 week (The MCI firewall test). If passed, it would likely work for 40 days, but
after this period, there were so many random factors that we couldn’t find any patterns.
2. Time Pattern 2: Set up a proxy server like the above. Flow some moderate traffic on it. If the IP address didn’t block after 1 hour, it will likely work
for 4 hours. If the IP has not been blocked, it will likely work for 2 days (TIC firewall test). And if it is not blocked yet, it will probably go for 2 weeks
(The MCI firewall test). If passed, it would likely work for 40 days, but after this period, there were so many random factors that we couldn’t find any
patterns.
When an IP address is Graylisted, it will never go to Whitelist again! So, when IRGFW throttles the IP address, we can say the IP is gray, and when the
IP is blocked, it is in BlackList. Most of the time, after 40 days, the IP will be unblocked again, but now the IP is gray and may have some limitations on
DL/UL speed and high jitter in some cases. This pattern will occur for every foreign IP address range, primarily for famous data centers and hosting
services that can be used for VPN/Proxy servers; or too infamous ASNs that are not in the default firewalls whitelists.
This “gray-listing” can be used for protocols as well. As we discussed, HTTP3/QUIC and UDP are Graylisted by default unless the client's fingerprint
(e.g. User-Agent in HTTP handshakes or UTLS in Client-Hello) does not match any of the firewall databases and the destination IP address has not been
graylisted yet.
1 Like
Possible Solution
Possible Solution
To mitigate the risk of server blocking, the goal is to disrupt the patterns that enable detection. One way to
do this is by modifying traffic patterns that are easily identifiable by servers. Injecting randomized packets
at the start of each stream can help obscure the traffic's intent, making it harder for detection algorithms
to classify it. Additionally, multiplexing multiple streams into fewer connections reduces the visibility of
individual traffic flows, further decreasing the chance of detection.
For authentication traffic, injecting randomized packets and fragmenting them with varying padding and
sizes can prevent the server from recognizing predictable patterns. By making the authentication process
less uniform, you reduce the likelihood of it being flagged.
Blocking effectiveness relies on the inability to modify protocols or propagate changes to users easily. If
users can adjust traffic patterns dynamically and apply these changes broadly, it undermines the server's
ability to block based on fixed patterns. The ability to modify protocols (such as through encryption, traffic
obfuscation, or fragmentation) helps maintain anonymity and reduce the risk of detection, making blocking
attempts less effective.
This strategy hinges on continuous adaptation to avoid predictable behaviour that could be used for
blocking or filtering.
из всего этого доклада идет вывод что дело будет таки в корреляции трафика и его анализ, а @bolvan войдет в историю. само слово desync никогда раньше мне не казалось настолько точным определением того что нас, и всю гонку в кошки-мышки, ждет в ближайшем будущем. нужна десенхронизация фронтов, самой машины dpi чтобы она меньше коррелировала потенциальный трафик
да кто спорит, это как бы из норм впн гигиены следует, хотя я тоже как и Denium редко отключаю впн, заворачиваю его еще и в Cloudflare Warp бывает поверх основного соединения, как в шубу, с периодическим переключением двух клиентов
интересно, каким образом?
всю дорогу начиная с августа указывал ети домены ютуба на некорей прописаны, впска на в эстонии or so, тем не менее пол года ютуп (гугол) меня определял что я из росии (и рекламы не было)) теперь всё приехали кароч теперь ютуб не RU а EE пишит,
так же интирисный эскпириенс - у мен есть арендую впска в москве для организации впна по назначению, а не для каких то обходов, чёто случайно ткнулся гляжу у их там через их ютуп кажет, суде по всему у хостеров ЦОДов прямые конекты к msk-ix или щто а оттудова уж прям к гугло понттыкается если я правельно понел что увидел нас крине, но про ето уже тож писали
теперь кароч ждём ихний следущий шаг:
А вот это уже интересненько. Такой домен впервые вижу. Он как бы в белых списках, или я не так понял?
Только режим белых списков никто не отменял.
Если не понятно что за трафик или не читабелен домен в clienthello, то блочим. И никакие рандомайзеры вам не помогут в этой ситуации
И такая схема уже применяется даже сейчас
я самолично хз, если я правельно понел у российских хостеров (ну или у масковских)) прямые конекты к msk ix и\или у гугла там же, а там походу пока что не режут ничего т.к. трогать IX ето последнее дело (не то чтобы ето их остановит или щто))
Тем кто использует v2rayN рекомендую обновить клиент. Появились региональные пресеты. Выбрав Россию клиент сам закачает нужный набор geoip:geosite и создаст шаблоны маршрутизации. Теперь завернуть (только!)блокируемый трафик в тунель можно в два клика. Ютуб заворачивается корректно.
Суд признал что Роскомнадзор не виноват в замедлении.
Я не буду это комментировать, разве что становится понятно что замедление Ютуба теперь носит стратегический характер.
я самолично сталкивался с такой проблемой тока телики не самсунговские а элджи, там кароч не всё так прост с етим прилолжением на тв, на компе может работать веб версия на смаратафоне работает прилолжение а на телике не кажет, как написано здесь (или на скрине ниже вижимка оттудова)
нужно кароч подобрать понтходящую сратегию здесь есть попадробнее тема на етот счёт, тока яна запрете делал, который на распере пи который понттыкается в сроутер ане байдпи не делал не понтскажу
Чел, нереально огромное спасибо.
Tizen OS. Починил так:
- сбросил на завод
- поставил тытруб
- подключился к обычной сети
- загрузил интерфейс
- запретил udp/443 (in/out)
- …
- profit
Теперь и на телеке всё работает.
Настроил ведение логов в dnscrypt, удобно смотреть последние домены. Интересную вещь заметил. Смотрел сугубо местные корейские новости (запостены на ru форуме) с нидерландского VPN. Но GGC судя по пингу был не Нидерланды, а UK.
там много разных алгоритмов
откуда больше/чаще смотрят (врядли кэшируют из за пары человек/ИП)
с какого ИП ДНС сервера запрашивают (может даже сам хостинг по GeoIP не считаться Нидерландами)
обычно в https://redirector.googlevideo.com/report_mapping?di=no видно
врядли кэшируют из за пары человек
Кэшируют, знаешь. Сам видел как заливался на местный российский ggc от моего просмотра. Раньше, другое видео.
Но сейчас это видео по прежнему грузится из Лондона. Я второй раз кликнул. Может быть нидерландские ggc переполнены или и правда другие алгоритмы. В конце концов, страны же рядом. А в NL врядли смотрят корейское, ты прав.
rr1.sn-aigl6n6s.googlevideo.com (173.194.3.70)
rr3.sn-aigl6ney.googlevideo.com (173.194.183.168)
А в ваших кэшах есть это видео?
VPN в DK (Дания)
https://redirector.googlevideo.com/report_mapping?di=no
149.88.109.83 => par10s47 : router: “pr04.par21” next_hop_address: “213.248.67.160”
rr4.sn-25ge7nzd.googlevideo.com. 29m55s A 173.194.0.233 (AS15169 Google LLC) (par10s46-in-f9.1e100.net.) Париж?
rr1.sn-5hne6nzy.googlevideo.com. 19m39s A 172.217.132.166 (AS15169 Google LLC) (ams15s49-in-f6.1e100.net.) Амстердам?
У меня 720p приехал в Нидерланды rr1---sn-5hne6nzy.googlevideo.com 172.217.132.166.
А 1080p остался UK rr3---sn-aigl6ney.googlevideo.com 173.194.183.168
Но я раньше 1080p не смотрел, только сейчас решил проверить.
Кстати, похоже redirector.googlevideo.com палит выходной IP VPN, осторожнее.
А у меня вот так:
X.150.196.106 => lhr48s34 : router: “pf04.lhr48” next_hop_address: “72.14.203.103” (X.150.196.0/24)
72.14.203.103 это UK.
А X.150.196.* NL.
Странно, почему у меня next hop UK для NL VPN.
У тебя redirector Дания>Париж. А GGC у того видео Париж и Амстердам (GGC Амстердама совпал с моим!)
Вообще, датские GGC у тебя встречаются или всё в соседние идёт?