да, для смены локации нужен masque
писал об этом ранее
https://ntc.party/t/cloudflare-warp-первый-среди-всех/15292/364
Поделитесь, пожалуйста, информацией как сменить colo по вашему способу?
Ещё не пользовался официальным клиентом, только через awg подключался к warp.
так у вас эндпойнты для masque могут по умолчанию вести к зарубежному colo
можно сделать трассировку 162.159.198.2 / 162.159.199.2 и посмотреть переходит ли границу icmp
(аналогично можно попинговать энпдойнты для wg, возможно и настраивать ничего не потребуется, только поменять эндпойнт в awg)
по дальнейшим действиям пока не понимаю, что от меня требуется. далее в случае положительной трассировки надо либо настраивать zapret для подключения к warp либо использовать usque
если masque/wg по прежнему идет в dme:
делать цепочки vpn я не умею, и будет ли awg-warp конфликтовать с другими vpn интерфейсами я не знаю. (скорее всего будет)
вариант с amnezia vpn (не-warp) + офф warp (masque) одновременно подключиться не сможет (варп зависнет на создании правил брандмауера), но у офф warp есть несколько секунд пока он будет пытаться восстановить соединение, в течение этого времени можно выключить amnezia vpn (не-warp) и подключиться к warp с локацией амнезии.
остальные варианты я не проверял. я просто не хочу писать инструкции, потому что все это максимально костыльно для этого форума.
Цепочка прокси варп-протон нормально работает в sing-box, но с tun у меня не вышло настроить
Все вами перечисленные на РТК идут туда же, куда и 162.159.198.1, трассировка для них практически одинаковая, подключение идет к DME.
Смените провайдера. РТК плохой выбор.
Да я себе домой два провайдер завел для экспериментов. У местного провайдера маршруты совершенно другие, варп идет в Хельсинки.
Можно достаточно быстро чекнуть COLO
Три разных провайдера дают разные COLO, РТК естественно выдает DME
WARP in WARP сейчас всегда гарантировано выдает тот же COLO, в который и произведен вход. DME в DME, WAW в WAW, LED в LED.
Видимо глобально пофикшено.
А можете пример конфига прислать?
Кажется причина сегодняшнего падения найдена и уже более предметна и локализирована (с утра была неразбериха).
Телеграм перестал посылать TCP пакеты даже во внутренних подсетях провайдеров без ТСПУ, с учётом что они находятся в РФ.
Это объясняет всё — если раньше была цепочка (очень условно):
Сервер — провайдер — ТСПУ — клиент
то теперь цепочка стала:
Сервер — ТСПУ — провайдер — клиентС сегодняшнего дня включили ТСПУ то ли на пограничных линках, то ли на магистральных. Даже у российских хостеров/дата-центров, у которых нет ТСПУ (есть такие), с сегодняшнего дня началась фильтрация зарубежного трафика. Работает всё, само-собой, максимально криво: пинги за рубеж выросли, что-то фильтруют, что-то нет, что-то частично.
Из интересного - все силы брошены на Телеграм. Его прямо жёстко фильтруют. А подключения к facebook, например, проходят за рубеж (хотя сначала тоже резали, но, видимо, пропускной способности фильтрации не хватило).
Это уже подтверждает несколько независимых владельцев серверов + объясняет почему отвалились именно РФ MTProxy.
Это ещё один этап к постепенному окукливанию интернета — теперь РКН начал блокировать трафик не ВНУТРИ страны а ещё ДО того как этот трафик попадёт в РФ.
Пример конфига для расширенного сингбокса. С ним запрет не нужен, только параметры амнезии
Спойлер
{
"certificate": {
"store": "system"
},
"dns": {
"servers": [
{
"tag": "DoH",
"type": "https",
"server": "anycast.uncensoreddns.org",
"path": "dns-query",
"domain_resolver": "dns-local"
},
{
"tag": "hosts",
"type": "hosts"
},
{
"tag": "dns-local",
"type": "local"
}
],
"strategy": "ipv4_only",
"disable_cache": false,
"rules":
[
{
"domain": ["ntc.party"],
"server": "DoH",
"strategy": "ipv6_only"
},
{
"ip_accept_any": true,
"server": "hosts"
}
]
},
"log": {
"level": "info",
"timestamp": true,
"output": "ProtonByWarpSingboxExt.log"
},
"inbounds": [
{
"tag": "in",
"listen": "127.0.0.1",
"listen_port": 18085,
"type": "mixed"
}
],
"endpoints": [
{
"tag": "proton",
"type": "wireguard",
"peers": [
{
"address": "ip_сервера_протона",
"port": 51820,
"public_key": "ваш_ключ",
"allowed_ips": ["0.0.0.0/0", "128.0.0.0/1"],
"persistent_keepalive_interval": 25
}
],
"private_key": "ваш_ключ",
"address": [
"10.2.0.2/32"
],
"mtu": 1420,
"detour": "warp"
},
{
"tag": "warp",
"type": "wireguard",
"peers": [
{
"address": "162.159.192.1",
"port": 500,
"public_key": "ваш_ключ",
"allowed_ips": ["0.0.0.0/1", "::/1", "128.0.0.0/1", "8000::/1"],
"persistent_keepalive_interval": 2
}
],
"private_key": "ваш_ключ",
"address": ["172.16.0.2/32", "10.0.0.1/32"],
"mtu": 1280,
"amnezia": {
"jc": 0,
"jmin": 0,
"jmax": 0,
"s1": 0,
"s2": 0,
"s3": 0,
"s4": 0,
"h1": 0,
"h2": 0,
"h3": 0,
"h4": 0,
"i1": "Значение_из_генератора",
"i2": "",
"i3": "",
"i4": "",
"i5": "",
"j1": "",
"j2": "",
"j3": "",
"itime": 0
}
}
],
"route": {
"default_domain_resolver": "DoH",
"rules": [
{
"inbound": "in",
"action": "resolve"
}
],
"final": "proton"
}
}
Но можно и c обычным сингбоксом + варп через masque.
Запустить варп через usque
usque.exe socks -b 127.0.0.1 -p 18087 --http2 -s cloudflare.com -P 4500
Затем обычный сингбокс
Пример конфига сингбокс
{
"certificate": {
"store": "system"
},
"dns": {
"servers": [
{
"tag": "DoH",
"type": "https",
"server": "anycast.uncensoreddns.org",
"path": "dns-query",
"domain_resolver": "dns-local"
},
{
"tag": "hosts",
"type": "hosts"
},
{
"tag": "dns-local",
"type": "local"
}
],
"strategy": "ipv4_only",
"disable_cache": false,
"rules":
[
{
"domain": ["ntc.party"],
"server": "DoH",
"strategy": "ipv6_only"
},
{
"ip_accept_any": true,
"server": "hosts"
}
]
},
"log": {
"level": "info",
"timestamp": true,
"output": "ProtonByWarpSingbox.log"
},
"inbounds": [
{
"tag": "in",
"listen": "127.0.0.1",
"listen_port": 18085,
"type": "mixed"
}
],
"outbounds": [
{
"tag": "warp",
"type": "socks",
"server": "127.0.0.1",
"server_port": 18087
}
],
"endpoints": [
{
"tag": "proton",
"type": "wireguard",
"peers": [
{
"address": "ip_сервера_протона",
"port": 51820,
"public_key": "ваш_ключ",
"allowed_ips": ["0.0.0.0/0", "128.0.0.0/1"],
"persistent_keepalive_interval": 25
}
],
"private_key": "ваш_ключ",
"address": [
"10.2.0.2/32"
],
"mtu": 1420,
"detour": "warp"
}
],
"route": {
"default_domain_resolver": "DoH",
"rules": [
{
"inbound": "in",
"action": "resolve"
}
],
"final": "proton"
}
}
Может ли это быть причиной того, что тг не работает через opera-proxy? Как говорят люди.
Вчера геоблок просто включили на SurfEasy API.
Да не. На 4pda говорят, что иногда opera-proxy подключается. И вот когда она работает, на ней работает всё, даже ютуб, но не тг. Вот что интересно.
Ещё интересней то, что если opera-proxy пустить через upstream proxy, то тг через неё работает.
Какой у них тг, правда, вопрос. Может, с mtproto на ru vps (забыли отключить).
Получается, депутат был прав. Нихрена не работает даже с впн (частенько).
Интересно почему?
Не исключена и кривость тг. Неизвестно куда он лезет.
Или может айпишники оперы тг забанил, т.к. на них много юзеров.
Сегодня с, примерно, 17.00 по Мск наблюдаю странную картину на билайне москва. В warp_cli пинг подскочил до 40+ (обычно было 5-15) а скорость упала до 50+/20+ с 150+/150+. В сторонних клиентах пинг такой же но скорость не порезана.
Забавно, что ipv6 на Мегафон идёт к WAW (Польша), но при этом WARP выдает нам московский IP.
Мне кажется, Xunlei прав, там геоблок. На ру-борде пишут, что геоблок обходится опцией -api-proxy (не путать с -proxy) Это правда, к примеру, через протон у меня заработало. Но через варп с ру айпи уже нет. Мой вывод, что таки геоблок. Но можете перепроверить
А тг кстати работает, если там в настройках прокси прописать opera-proxy
Но имхо, проще получить финский ip для варп через usque, чем возиться с opera-proxy
не работает
по крайней мере на проводе
при том что 192dme а 195lde
сколько вложений не делай чебурнильные ip из трассировки не исчезают
да и с чего бы?
кто вообще эту пулю пустил что варп-ин-варп должно что-то менять?
в лучшем случае через первый можно заюзать nat64 если ipv6 на прове нет
да и то тогда проще прокладкой (пока живо) воспользоваться - хотя бы с вложенностью меньше геммора
Внезапно перестал логиниться баттлнет, когда активен warp в clash’e
Причём баттлнет то пока в РФ не заблочен, он в splittunneling настроен напрямую ходить.
Но пока не оффнешь подключениек Варпу в clash - в баттлнет теперь не войти(
Проблема случается при первом входе после включения ПК, повторные входы уже и при запущенном варп проходят.
Это что, близзард исполняют требования РКН с включенным vpn не пускать юзеров?
Так ведь он и так настроен на direct, без варпа ходить