Аналогичная история на МГТС Москва. Можно также на локальном dns-сервере запретить ipv6 ресолвинг по проблемным доменам, чтобы не отключать целиком. ria.ru тож не работает.
upd: ria.ru починили, ipv6 на cdn мегафона тоже.
Они много чего сломали по ipv6 ни в чем не повинного. Бесконечно дергает ajax.cloudflare.com ajax.googleapis.com fonts.googleapis.com Браузер конечно по fallback откатывается потом на ipv4 но ждать по 30 секунд раздрожает.
Я так и не понял вот с пк сейчас зашел - риа и коммерс не ворк, а с телефона на вафле - да, бред вообщем
А может это не проделки РКН, а просто криво настроенный IPv6? у меня например с мобильного МТС не открываются ресурсы хостинг-провайдера Джино, и поддержка даже не знает, как это исправить. Если проверить на сайтах вроде ping.pe, запускающих пинг с разных точек по всему миру, доступность примерно 50/50.
В случае с Джино проблема скорее всего на стороне оператора РТКомм.
Хотя у CDN РИА оператор Мегафон, и по пингу у него нормальная доступность, но может проблема где-то на более высоком уровне.
Сомневаюсь, 6in4 прекрасно работает. Это у них хрень какая-то. Да и многие провы до сих пор дают ipv6 в “тестовом“ режиме. Всегда найдут отмазку. Кстати, оба поддомена от риа и коммерсанта ресольвятся в канонические мегафоновские адреса по v6. Тут вроде уже проскакивало что-то про сети мегафона и их ужесточение белых списков. Может сами и прихлопнули свои же домены с дури. P.S. Я слепой, пардон, про мегафон, вы уже сказали =)
забавный факт
белые sni теперь превратились в чёрные - т.е. теперь их юзание как показатель для блока у чебуродов
есть www.wireguard.com (именно www чтоб больше чем 16к страница)
у него ip 192.248.189.215 The Constant Company, LLC
хостинг захерачен на 16к
белого sni нету vultr.com не подходит
но дело даже не в этом
если будете искать с –dpi-desync-fake-tls-mod=sni= всёчтовамизвестно ничего не найдёте.
не помогут никакие отосру и прочие айтюнсы с озонами
НО rndsni,padencap неожиданно помогает продырявить 16к
как минимум в курле блокчека
и в ie11 тоже
но вот уже в хроме не аллё х.з. почему
но опятьже не это главное, а то что sni помогающие продырявить одни cidr для других не то что не помогают а наеборот как чёрная метка
О наконец-таки кто-то поднял эту тему. Я называю это аномалией, потому что IP пингуется, а пробития через zapret нет. Я встречал такое же поведение на Fastly для следующих доменов:
waveform-speedtest-5.global.ssl.fastly.net
151.101.193.194
151.101.129.194
pypi.org
151.101.64.223
www.lumen.com
151.101.67.10
151.101.3.10
ну ваще правильней и проще не sni мифические искать а стунхаком дырявить - но эрэфийские сайты стали анально огорождаться и массово дохнуть если стунхак в стратегии
ещё месяц назад ничего подобного не было и не дохли
а тут те же фуллинги, которые работают без стуна, со стуном не спасают - и х.з. запрет бажит или х.з.
Скинь айпи адрес и полную стратегию
ip чего?
nslookup www.wireguard.com
Non-authoritative answer:
Server: one.one.one.one
Address: 1.1.1.1
Name: wireguard.com
Addresses: 2001:19f0:6c00:1634:925a:8ff:fe78:43ec
192.248.189.215
Aliases: www.wireguard.com
- SUMMARY
curl_test_https_tls12 ipv4 www.wireguard.com : winws --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=fake --dpi-desync-fooling=badsum --dpi-desync-fake-tls-mod=rnd,dupsid,rndsni,padencap
curl_test_https_tls13 ipv4 www.wireguard.com : winws --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=fake --dpi-desync-fooling=badsum --dpi-desync-fake-tls-mod=rnd,dupsid,rndsni,padencap
вы уверены? может быть DPI внепланово реагирует на вашу страту? а не так как вы думаете (вы думаете что рандомный SNI пробивает блок, а белые sni наоборот блочат?)
вебсервер принимает любой SNI и без дурений запретом.
curl -vk --connect-to ::www.wireguard.com -H "Host: www.wireguard.com" https://gkjflgkjfgk.co
у меня не проходит запрос, у вас? если так же, то значит страта запрета что-то ломает в логике ТСПУ и вывод неверный.
есть белый sni на его же родном айпи адресе
https://spectator.osu.ppy.sh/
но он блокируется, хотя ранее работал при 16кб блоке чисто по айпи адресу. при этом к серверам oracle он пробивает 16кб блок.
здесь всё не так просто.
winws --wf-l3=ipv4 --wf-tcp=443 --dpi-desync=fake --dpi-desync-fooling=badsum --dpi-desync-fake-tls-mod=rnd,dupsid,sni=spectator.osu.ppy.sh,padencap
без изменений
ie11 да
хром нет
без padencap оба нет
#!/bin/sh
EXEDIR=“$(dirname “$0”)”
EXEDIR=“$(cd “$EXEDIR”; pwd)”
SECURE_DNS=0 PKTWS_EXTRA=‘–dpi-desync-fake-tls-mod=sni=gosuslugi.ru’ CURL_HTTP_GET=1 CURL_HTTPS_GET=1 CURL_MAX_TIME=0.6 MAX_TTL=0 MAX_AUTOTTL_DELTA=0 “$EXEDIR/blockcheck.sh” 2>&1 | tee “$EXEDIR/../blockcheck.log”
вот так никаких стратегий не находится!!!
а так
SECURE_DNS=0 PKTWS_EXTRA=‘’ CURL_HTTP_GET=1 CURL_HTTPS_GET=1 CURL_MAX_TIME=0.6 MAX_TTL=0 MAX_AUTOTTL_DELTA=0 “$EXEDIR/blockcheck.sh” 2>&1 | tee “$EXEDIR/../blockcheck.log”
находится и я их уже приводил
ну так sni белый, а у вас пробило блок, вывод неверный значит
goguslugi слишком популярный sni, могли прибить его к айпи адресам (мегафон так сделал уже давно и с десятком других sni тоже)
самый что ни на есть верный
с –dpi-desync-fake-tls-mod=sni=gosuslugi.ru нет пробивки
без –dpi-desync-fake-tls-mod=sni=gosuslugi.ru есть пробивка (и вообще без любого sni)
впрочем я уже вернулся к безглючному варианту стунхака
https://ntc.party/t/zapret-обсуждение/726/9536
классический его вариант стали палить и не давать использовать
перечитайте моё сообщение пожалуйста
я вижу что помогает паденкап с рандомным sni, но если sni из известных белых(госы для примера - перебирал с десяток работающих на других cidr), то идёт блок
osu.ppy.sh это известный белый с которым у вас запрос проходит
он работает на том же клауде etc?
если да - бох с ним
мой вывод более правильный чем неправильный, ибо другие sni что пробовал более популярны и чаще на ум приходят
на cloudflare, ovh, DO, oracle. (ну не на всех айпи т.к. spectator.osu.ppy.sh на своём же родном айпи не работает)
Спойлер
и
тоже можно сказать
это с безглючным стуном