Принудительно никак, нужно проверять на практике) Остаток гб не выводится вроде нигде во время работы, в идеале бы проверить как быстро пройдет ротация при исчерпании лимита, доработал билд для более бесшовного переключения токенов, затестишь?
У меня не получилось, все так же ругается на токен свежего аккаунта
firefox-proxy.zip (2,8 МБ)
Вы нихотите оперу впн починить? Раньше у миня работало но уже давно нет.
GitHub - Alexey71/opera-proxy · GitHub - имеешь ввиду? Попробуй использовать флаг:
-api-proxy https://w.net-healer.com:443
или любой другой прокси для доступа к апи
tracert -4 p.m1.fastly-masque.net
Трассировка маршрута к p.m1.fastly-masque.net [23.235.42.11]
с максимальным числом прыжков 30:
…
17 151 ms 151 ms 151 ms 197.157.64.226
18 163 ms 163 ms 163 ms 197.157.64.227
19 152 ms 152 ms 161 ms 197.157.64.226
20 163 ms 163 ms 163 ms 197.157.64.227
21 153 ms 151 ms 152 ms 197.157.64.226
22 164 ms 163 ms 163 ms 197.157.64.227
23 151 ms 151 ms 151 ms 197.157.64.226
24 163 ms 163 ms 163 ms 197.157.64.227
25 151 ms 168 ms 152 ms 197.157.64.226
…
Ага, только быстро не обещаю, ибо мало чего качаю, ютуб тоже мало смотрю. Вот если б через FF-proxy можно было торренты пускать)
Ютуб, если железо современное, нынче мало жрет, т.к. битрейт av1 мизерный по сравнению с вк видео того же av1. Хотя щас бесит, что не могут сделать выбор кодека в плеере, т.к. и на слабом железе он выбирает av1 по умолчанию
Это Африка, Гана. Возле экватора. Меня под варпом (FRA) на icmp, кстати, тоже кидало в Африку. И тоже рекурсия. Но tcp ходил норм.
Полагаю, какой-то баг у Мозиллы, поскольку до FRA руки ркн ещё не дотянулись.
Вот ICMP трассировка до 23.235.42.11 из под варпа (FRA):
Host Loss% Snt Last Avg Best Wrst StDev
- 104.28.0.0 0.0% 3 112.3 111.4 108.6 113.2 2.4
- 172.69.113.1 0.0% 3 127.3 119.8 109.6 127.3 9.1
- 162.158.84.232 0.0% 3 123.9 117.8 110.2 123.9 7.0
- ipv4.de-cix.fra.de.as37271.workonline.africa 0.0% 3 129.6 118.8 109.8 129.6 10.0
- (waiting for reply)
- 41.78.188.179 0.0% 3 216.6 225.8 216.6 238.6 11.4
- 197.157.64.227 0.0% 3 296.8 285.2 272.5 296.8 12.2
- 102.134.20.34 0.0% 3 282.2 275.7 270.2 282.2 6.1
- 102.134.20.35 0.0% 3 288.1 287.3 278.1 295.8 8.9
- 102.134.20.34 0.0% 3 293.8 290.6 276.5 301.4 12.8
- 102.134.20.35 0.0% 3 298.9 286.9 275.1 298.9 11.9
- 102.134.20.34 0.0% 3 284.4 284.1 275.9 292.1 8.1
- 102.134.20.35 0.0% 3 290.1 281.0 274.9 290.1 8.1
- 102.134.20.34 0.0% 3 275.6 280.5 275.6 283.7 4.3
- 102.134.20.35 0.0% 3 288.9 287.7 273.6 300.6 13.5
- 102.134.20.34 0.0% 3 285.5 287.1 279.5 296.3 8.5
- 102.134.20.35 0.0% 3 292.1 284.1 278.1 292.1 7.2
- 102.134.20.34 0.0% 3 318.2 297.5 285.4 318.2 18.0
- 102.134.20.35 0.0% 3 287.1 288.7 285.6 293.5 4.2
- 102.134.20.34 0.0% 3 301.2 290.1 278.9 301.2 15.7
- 102.134.20.35 0.0% 3 285.1 280.2 275.3 285.1 6.9
- 102.134.20.34 0.0% 3 292.0 287.3 282.6 292.0 6.7
- 102.134.20.35 0.0% 3 296.5 285.2 273.8 296.5 16.0
- 102.134.20.34 0.0% 3 281.2 281.1 280.9 281.2 0.2
- 102.134.20.35 0.0% 3 288.1 284.6 281.2 288.1 4.9
- 102.134.20.34 0.0% 3 293.6 290.2 286.8 293.6 4.8
- 102.134.20.35 0.0% 3 301.3 295.0 288.7 301.3 8.9
- 102.134.20.34 0.0% 2 273.2 283.9 273.2 294.7 15.2
- 102.134.20.35 0.0% 2 270.9 272.5 270.9 274.1 2.3
- 102.134.20.34 0.0% 2 296.7 295.3 293.9 296.7 1.9
В конце Нигерия.
Но это icmp. А mtr --tcp норм и консольный firefox vpn работает.
у меня под варпом
AMS,ARN - маршрутизация нормальная, пинг в норме
FRA - отправляет в америку по трассировке, хотя выходной ip показывает европейский. пинг при этом высокий на спидтестах, задержка также чувствуется при открытии страниц
во всех случаях использует ipv6
А у вас AMS, ARN и FRA чистокровные или loc=RU?
У меня loc=RU. Может, дело в этом.
Я использую ipv4.
loc=ru
ipv6 он сам выбирает видимо, т.к варп его поддерживает
родного ipv6 у меня нет
Я FRA получил используя не дефолтный endpoint. Вообще, он значится на сайтах как Новосибирск.
Думаю, FRA бывают разные.
По ipv6 у меня тоже США (Калифорния), без рекурсии. Правда, в середине мелькала Мексика.
(icmp p.m1.fastly-masque.net из warp FRA)
Кстати, возникал несколько раз вопрос. любые соединения, кроме 443,80 откидывает огненныйлис?
dell
Вот, что ответил Claude по поводу зацикливания в Южной Корее. Но ничего в общем нового.
Смотрите, картина очень характерная — и она куда больше похожа на аварию/петлю в маршрутизации на границе сетей, чем на классическую блокировку по DPI (ТСПУ), хотя полностью исключать участие “административного фактора” тоже нельзя. Разберу по пунктам.
Что именно видно в трассировке
Начиная с hop 10 у вас идёт классический routing loop («ping-pong») между двумя соседними маршрутизаторами:
210.57.34.20 → 210.57.34.21 → 210.57.34.20 → 210.57.34.21 ...
TTL честно растёт (10, 11, 12… 30), но пакет каждый раз «отфутболивается» назад между этими двумя узлами и гарантированно умирает на 30-м хопе, не долетая до 23.235.42.11. Это типичный симптом, когда:
- один из роутеров имеет маршрут «эта сеть — туда» (в сторону соседа),
- а сосед в ответ имеет маршрут «эта сеть — обратно» (в сторону первого),
- то есть где-то в паре Telstra/Fastly (AS Telstra в Сеуле, это их точка присутствия Fastly) ↔ Korea Telecom потерялась/не сошлась специфичная маршрутная запись до конкретного anycast-префикса Fastly.
Это ровно то, что происходит при частичном отзыве BGP-маршрута (route withdrawal) без синхронного обновления у соседа, при флаппинге пиринга или после изменения конфигурации anycast-каталогов у Fastly — а не то, что делает DPI-цензура. ТСПУ/DPI обычно режет по TCP RST сразу на границе российской сети или у оператора, а не заставляет пакет доехать до Сеула через Китай и зациклиться там.
Почему через Китай и почему у всех на Ростелекоме одинаково
Ваш hop 5 (87.226.221.111, подписан как «Китай Ростелеком») + hop 4 «возможно Хабаровск» — это явно дальневосточный транзит Ростелекома через China Telecom до Korea Telecom, а дальше — до ближайшей (по BGP-метрикам именно для этого транзитного пути) точки anycast Fastly в Сеуле. У Yota и у других провайдеров, судя по всему, таблица маршрутов до этого же anycast-префикса (23.235.42.11) резолвится через другую точку присутствия (скорее всего европейскую/московскую), где всё штатно работает.
Anycast-адрес — это один и тот же IP физически в разных точках мира; какая точка ответит вам, определяет BGP на стороне вашего провайдера. Поэтому:
- у Ростелекома (по крайней мере в дальневосточном сегменте/с конкретным транзитником) трафик улетает в Сеул и там ловит петлю;
- у других провайдеров — уходит на другой, рабочий узел.
Это объясняет и то, что «несколько дней назад сломалось»: скорее всего у Fastly/Telstra/Korea Telecom произошло изменение анонсов или частичный сбой именно в сеульском PoP, либо у Ростелекома поменялся транзитник/маршрут в сторону Азии.
Стоит ли подозревать целенаправленную блокировку
Полностью сбрасывать со счетов нельзя — в России активно блокируют VPN-протоколы и сервисы, и теоретически транзит через китайскую инфраструктуру мог зацепить фильтрацию GFW (Китай режет по SNI очень агрессивно, и известно, что серверные домены новой Firefox VPN уже попадали под блокировку GFW именно как транзитный трафик). Но конкретно ваш паттерн — L3-петля ICMP TTL exceeded между двумя роутерами в Корее — это не почерк ни ТСПУ, ни GFW (те бы дали RST/timeout гораздо раньше, а не зацикленный маршрут в чужой юрисдикции). Так что версия «сломанный anycast-роутинг на стыке Fastly/Telstra/Korea Telecom, до которого физически докатывается только дальневосточный транзит Ростелекома» — основная.
Сообщить в Mozilla / Fastly
Это баг сети провайдера VPN-сервиса, а не вашего компьютера — с такими диагностическими данными его быстрее всего починят те, у кого есть доступ к BGP-конфигурации.
Итого, коротко: то, что вы поймали — это скорее всего не преднамеренная блокировка, а классическая BGP/anycast-петля на стыке сетей (вероятнее всего между сеульским узлом Fastly/Telstra и Korea Telecom), до которой докатывается именно дальневосточный транзит Ростелекома через China Telecom. Другие провайдеры резолвят тот же anycast-адрес через иной, рабочий узел — отсюда и разница «Ростелеком/Yota». Сама петля (два роутера гоняют пакет туда-сюда, TTL растёт, а адресат не меняется) — это техническая ошибка маршрутизации, а не DPI-блокировка (та обычно рвёт TCP сразу на границе, а не в Корее через 10+ хопов).
Самое полезное, что можно сделать своими силами прямо сейчас — переключиться на другой канал (Yota) на время, а параллельно отправить именно эту трассировку и данные Wireshark в поддержку Mozilla/на Mozilla Connect — с такой точной диагностикой шанс, что сетевые инженеры Fastly быстро поправят анонсы, гораздо выше, чем без неё.
upd: на всякий случай, я ему сказал, что приехал в Россию в гости к семье.
дефолтные ip опять заблочили?
Тоже перестало коннектить без впн, через варп норм коннектит.
До этого не воркало только подгрузка нод
https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/vpn-serverlist/records
Как и в прошлый раз:
https://ntc.party/t/firefox-149-поставляется-с-бесплатным-vpn/22946/264
Добавил правило с DNAT для этих трех ip через .65.91 - пока так работает
Разрешено сделать 5 исключений.
Обновлю информация по поводу исключений по сайтам не использующим VPN, добавил в список исключений более 100 сайтов.
Как всегда, помогает hosts.
ff-proxy.log
Loaded 3 session tokens from tokens.txt
Resuming from token 1/3 (saved state)
Activating session token 1/3... OK
SOCKS5 listen: 127.0.0.1:18082
Upstream proxy: us.m1.fastly-masque.net:2499
Auth source: session-token file tokens.txt (3 tokens)
Transport: 4 upstream HTTP/2 TCP4 connections
Token rotation: 3 tokens, quota check every 15m0s
Proxy sessions refreshed after token rotation
Proxy sessions refreshed after token rotation
Proxy sessions refreshed after token rotation
Proxy sessions refreshed after token rotation
Судя по логу, ротация происходит каждые 15мин, независимо от исчерпания лимита (потому что лимит у меня пока нигде не исчерпан)? Кстати, было б здорово еще добавить в лог, какой именно токен используется в данный момент
Еще довольно странная вещь обнаружилась. У меня в данный момент 3 рабочих токена. Один из токенов использовался для подключения к ТГ. Подозреваю, что FF выписал теневой бан на этот акк (токен). Скорость не превышает 100-500 КБ/сек. Если подключиться к той же локации, но с др. акка(токена), то скорость сразу выше на порядок. У кого-нибудь такое было?