Может быть whitelist по гугловским SNI. Надо пробовать UNBLOCKED_DOM
Попробовал UNBLOCKED_DOM=www.google.com, в конце лога.
Все эти домены - забугорные. Скорее всего к ним по пути несколько коробок и попалась какая-то упорная.
С Быстро без проблем открываются все из списка. РТК
Браузер их открывать не хочет по квику или HTTPS? Большая разница.
Хотя не исключаю возможности, что они тупо забанены по квик/хттпс запросам по подсетям. Возможно пров не хочет платить за зар. трафф, впнщики и так его нагнали достаточно.
Тестил только https. quic не пашет совсем, ещё не разбирался почему.
Точно, я чёт сразу не допёр что не работают зарубежные сервера. Интересно, если завернуть трафик к этим серверам через тот же warp, а остальное оставить как есть, ютуб на меня сильно обидится?
Возможно WARP вам ничего и не отдаст, а вообщем конечно так работает без проблем (без проблем, если проксировать *.youtube.com через варп).
rr14.sn-n8v7kn7d.googlevideo.com — московский.
Split tunneling или ZeroOmega в браузере.
Если эти сервера не работают ни по хттпс ни по квику (а стратегии то разные) - то вывод напрашивается сам собой.
По впнам - это ни ко мне вопрос, я их на ютубе не использую ни в каком виде, себе дороже
Это можно считать блоком по IP:port:protocol. Любой пейлоад вызывает блокировку.
Хотя, может существует и такой, который в вайтлисте, но мы не знаем
Можно для интереса туда всякий левак передавать типа http или вообще мусора и смотреть приходят ли хотя бы ACK или даже ошибки TLS. Если да, то это блок по IP, порту и протоколу. Если нет, то блок по IP:port , но уже после handshake
у меня такое выдает блокчек, если на пути ggc находятся 2 тспу разных провайдеров в основном.
сервер может пробиваться при этом (а может и нет), но там весьма странное в wireshasrk
при первом tls соединении оно блочится, при повторном после rst успешно выполняет хэндшейк.
или к примеру местные сервера этого комрада rr1---sn-joug0-n8vl.googlevideo.com с билайна (вероятно, тоже по пути встречающие второе тспу) тоже выдает ошибку curl: (28) Connection timed out after 2001 milliseconds с www.google.com в блокчеке
но при этом эти сервера открываются, если убрать все фейки из стратегии, на чистом сплит
с tls hex от client hello 50/50 при этом
но вцелом поведение у разных ggc совершенно по разному…
А чё там ркн начал местные ggc по айпи блокать?
Слава богу - пока нет )
Это у него провайдерская поипень какая-то, причем никто не может понять - какая (
После ClientHello, сервер присылает ACK и сидит молчит до таймаута.
Если обращаться не по домену, а по IP адресу, сервер не присылает даже ACK. На retransmission не реагирует.
Если вместо ClientHello отправить “GET / HTTP 1.1” на 443 порт, сервер присылает ACK и сразу RST,ACK. Повторные соединения заканчиваются так же.
какому провайдеру принадлежит последний хоп на трассировке перед гугловскими?
по твоему описанию, у меня такое же с частью ростелекомовских ggc (правда у меня на данный момент ютуб к ним и не отсылает)
видео работает наоборот только с тех, которые у тебя недоступны
т.е в основном все ggc с билайна доступны (в том числе других провайдеров), но вот при переходе билайн>ртк в трассировке то часть из них с такими же симптомами
tracert rr14---sn-n8v7kn7d.googlevideo.com
..........
6 6 ms 3 ms 3 ms 5.143.253.245
7 3 ms 3 ms 2 ms 192.178.241.249
8 2 ms 2 ms 2 ms 72.14.233.95
9 2 ms 2 ms 2 ms svo07s06-in-f32.1e100.net [173.194.176.224]
6 - РТК, остальные - х.з., по идее google
Так делает и www.google.com
Значит блок более похож на ip:port:protocol. Возможно, пустой whitelist, то есть блочится любой TLS, кроме “ничего”. Правила для DPI могли написать как угодно
Всем спасибо за помощь, буду рекомендовать абоненту менять провайдера.