Просто выбрать endpoint не получится, т. к. Cloudflare автоматически его определяет в зависимости от вашего провайдера. Я смог подключиться к датацентру DME через VPS от Serv.Host, расположенный в Швеции.
Edit: Если вы хотите подключиться к DME через российский IP адрес, то почти любой российский VPS подойдёт.
Я, кажется, разобрался, почему у меня получается именно так – через VPS+WARP сайт не работает, а через VPS без WARP открывается.
Просто я, как все чайники, вношу изменения в конфигурацию, не учитывая последствий, а потом забываю что куда внёс )
В hosts у меня ничего не прописано (когда-то пробовал, ничего не дало), IPv6 на компьютере нет, но каким-то образом происходит резолв доменного имени на VPS, где IPv6 есть. Не знаю как, специально я для этого ничего не делал, но, как только я отключил IPv6 на VPS, ntc.party у меня открываться перестал. И тогда я вспомнил, что для WARP я отключил там IPv6 ещё раньше, по каким-то своим чайницким соображениям )
В общем, сам WARP в моём случае ни при чём, дело именно в доступности IPv6 и соответствующего DNS, извините что не указал всех деталей сразу.
Не могли ли CF сами включить фильтрацию у себя на WARP эндпоинтах в РФ?
Фильтры слишком точечные и кореляции между маршрутом трафика и наличием/отсутствием фильтра я не заметил. Как маршруты идущие сразу на крупных международных магистралов напрямую из сети CF, так и маршруты идущие по сети российских провайдеров подчиняются фильтрации.
При этом фильтр работает только на конкретный адрес и sni. Запрос с доменом 3го уровня уже проходит без проблем даже на тот же айпи, что и “заблокированный” домен 2го уровня. Это не сосвем походит на работу наших ТСПУ, которые умеют блочить поддомены. Так же, как и запрос с “заблокированным” доменом 2го уровня проходит на соседние айпи адреса от оригинала.
Из этого складывается подозрение, что это фильтрация от самого КФ, а не от ТСПУ на апстримах.
Еще один аргумент в пользу моей гипотезы, фильтры одновременно появились в ДЦ LED и DME и работают одинакого, несмотря на разные маршруты и разные ДЦ.
P.S. CF на своем сайте говорит, что еще остался рабочий ДЦ в Красноярске, но подключиться к нему у меня нет возможности, было бы интересно увидеть тесты от тех, у кого есть к нему доступ
Я подключился к DME через кемеровскую впс. В принципе, блокировок нет, но есть две странности:
proton.me не резолвится через 1.1.1.1. Вроде бы SERVFAIL.
При этом сам https://proton.me открывается. Его ns сервера пингуются.
ping 205.132.47.1
ping 176.119.200.150
ping 185.70.42.150
ipv4 https ntc.party (в hosts) не открывается.
BoringSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ntc.party:443
closing connection #0
curl: (35) BoringSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ntc.party:443
но
ipv6 https
ipv4 http (редирект на https)
открываются.
Т.е. связность есть.
mtr до ntc.party:
104.28.0.0 82ms (CF MSK)
172.68.167.1 79ms (CF MSK)
172.68.8.52 74ms (CF MSK)
mow-b5-link.ip.twelve99.net 80.239.193.240 101ms MSK
sto-bb2-link.ip.twelve99.net 62.115.141.22 102ms (Швеция)
…
Сайты на CF имеют 1 хоп к DME варпу:
rutracker.org 172.67.182.196 1 hop открывается
thepiratebay.org 162.159.136.6 1 hop открывается
chatgpt.com 8.6.112.0 1 hop
Выходной IP варпа 104.28.244.75.
Да, он считается Новосибирск (впска в Кемерово).
Но
curl https://www.cloudflare.com/cdn-cgi/trace
curl https://cloudflare.com/cdn-cgi/trace
curl https://engage.cloudflareclient.com/cdn-cgi/trace
показывают colo=DME под варпом и имеют описанные в других сообщениях симптомы.
В colo=HEL проблем с proton.me и ntc.party нет.
У меня тоже блокировки на DME.
Но у ntc.party немного по другому. Думает 30 сек, потом есть пакеты от сервера, но ошибка SSL.
tuta, mullvad и прочие задумываются на 5 минут и никаких ответов от сервера, таймаут.
rutracker открывается через раз, чаще открывается.
curl -v -4 -k ``https://ntc.party/`` --connect-to ::130.255.77.28
Connecting to hostname: 130.255.77.28
Trying 130.255.77.28:443…
Connected to 130.255.77.28 (130.255.77.28) port 443
ALPN: curl offers h2,http/1.1
TLSv1.2 (OUT), TLS handshake, Client hello (1):
зависание 30 сек
BoringSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ntc.party:443
closing connection #0
curl: (35) BoringSSL SSL_connect: SSL_ERROR_SYSCALL in connection to ntc.party:443
curl -v -4 -k ``https://tuta.com/
Host ``tuta.com:443`` was resolved.
IPv6: (none)
IPv4: 185.205.69.12
Trying 185.205.69.12:443…
Connected to ``tuta.com`` (185.205.69.12) port 443
ALPN: curl offers h2,http/1.1
TLSv1.2 (OUT), TLS handshake, Client hello (1):
зависание 5 мин
SSL connection timeout
closing connection #0
curl: (28) SSL connection timeout
mtr tuta.com
Со sni vk.com открывается.
Я удивляюсь, у рутрекера 1 хоп до варпа (т.к. рутрекер за CF), но иногда не открывается.
Теперь попробуйте подключиться к DME с нероссийским IP адресом, и увидите, что такие блокировки отсутствуют.
На DME ещё не так-то просто попасть. Даже с московским IP меня кидало зарубеж. Т.е. IP как бы ru, но colo не в России.
Все так, вероятнее всего их заставили включить фильтрацию под угрозой забрать сервера
Эти фильтры не похожи на обычное поведение ТСПУ и связи между трассировками и блокировками не нашел
Речь про подключение не из РФ к дата центру в DME или LED
У прибалтов есть хостинги с выходом на DME в варпе
Когда их итальянцы попросили фильтровать пиратские сайты, они сказали мы лучше уйдём из страны. И что это очень сложно, мол трафик огромный (даже фильтрация на dns, не то что sni).
Как раз фильтрация по sni больше пахнет ркном.
Попробуйте сервера в прибалтике или в Швеции, возможно ещё в Финляндии. Но я лично смог подключиться к DME через Швецию.
Если это был бы РКН, то по идее трафик бы всегда заблокировался у DME. Но как только подключаешься к DME зарубежом, всё прекрасно работает.
Я попробую, но немного позже. Надо найти шведскую впску или впн. А потом у меня две виртуалки, чтобы пускать wireguard через wireguard.
Забавно, что если подключаться с московского IP, то меня кидает в шведский colo.
А если из шведского IP, то как вы говорите, в московский DME colo.
Такая вот рокировка.
Кстати, сейчас 1.1.1.1 резолвер хоть и пишет SERVFAIL на proton.me, но после небольшой задумчивости также возвращает и айпишку (как и doh), но довольно странную: 3.68.80.83 на амазоне. В то время, как у proton.me должно быть 185.70.42.45 на своём хостинге. При этом https://proton.me открывается.
Напоминает подмену dns или dns проксирование (как у comss).
Слишком много разных блокировок:
proton.me по dns
у ntc.party ошибка SSL, возможно в следствии EOF (end of file) как в логе в начале темы, т.е. немного данных проходит, потом резка
рутрекер то открывается, то нет, с прямым коннектом (сайт-warp)
сайты почтовиков и впнов tuta, mullvald timeout
а ещё я помню несколько месяцев назад резолв www.youtube.com (именно с www) под варпом, но 8.8.8.8 резолвером (именно им, хотя думаю мало кто пользуется им на варпе) приводил к задержке с ответом. Тормоза при резолве, в общем. Потом их правда поправили.
Я думаю, если бы блокировал CF, то всё было бы однообразней. Похоже просто российские colo разваливаются. Но точно в этом замешана инфраструктура CF. Как они подделали IP протона? В doh’е и у них наверняка dnssec. Всё это очень странно.
upd: 3.68.80.83 выдают и некоторые другие (российские) резолверы.
На rutracker.org вообще не стоит полагаться, его DDoS-ят аццки, и он часто просто перегружен
Для Турции тоже такой отдается
Google, AliDNS тоже отдают 3.68.80.83, потому что у них есть серверы в РФ. А OpenDNS отдает 185.70.42.45, потому что серверов в РФ нет
Вероятно, это связано с противодействием блокировкам со стороны Proton
конкретно >3 секунд:
doggo proton.me @https://cloudflare-dns.com/dns-query --timeout=4s
NAME TYPE CLASS TTL ADDRESS NAMESERVER
proton.me. A IN 30s 3.68.80.83 https://cloudflare-dns.com/dns-query
doggo proton.me @https://cloudflare-dns.com/dns-query --timeout=3s
NAME TYPE CLASS TTL ADDRESS NAMESERVER
Из шведского кидает в московский colo не всегда, только у определённых хостеров так настроен роутинг.
Это валидный IP адрес для Proton, у них не только 185.70.42.45. Про него ещё писали, что есть проблемы с DNSSEC, хотя не знаю насколько это правда или нет, т. к. проблема с резолвингом наблюдается только в РФ (по крайней мере по моему опыту).
Это всё ещё не объясняет, почему блокировки происходят только в том случае, когда подключаешься к российским датацентрам, находясь в РФ, но не в других странах.
Может ТСПУ проверяют GeoIP у Source IP, чтобы не ломать транзитный зарубежный трафик?
У CF ведь цепочка серверов. Входной IP 162.159.192.1 (anycast) не равен выходному. В одном ли они датацентре или стойке я не знаю. При этом выходной IP (который видят сайты и который и осуществляет коннект к ним) по базе данных имеет страну или город клиента. Если ТСПУ стоит между клиентом и входным IP, то он не может видеть сайты, потому что wireguard трафик зашифрованный. Если ТСПУ стоит после выходного IP варпа и между сайтами, то он конечно видит домены и sni и по базе данных может проверить локацию выходного=входного IP, см. выше.
Может ли он стоять между цепочки входного anycast и выходного, не знаю. Врядли.
upd: Со шведского IP меня кинуло на шведский colo. Там блокировок понятное дело нет. Единственное, что ntc.party тоже не открывается с той же ошибкой. Но он глючит и на других впнах.
Значит, надо попробовать сервер у другого хостера. На GitHub есть файл-подписка с VLESS-серверами по всему миру, я оттуда взял и настроил chain proxy по схеме клиент → VLESS → WARP.
Да, я в принципе верю, что блока нет. А раз нет, то нет и смысла тестировать.
Сегодня 1.1.1.1 снова перестал выдавать IP для proton.me.
nslookup proton.me 1.1.1.1
server can’t find proton.me: SERVFAIL
server can’t find proton.me: SERVFAIL
curl -v -4 --doh-url https://1.1.1.1/dns-query https://proton.me
Bad RCODE type A for proton.me
Соединение с https://mullvad.net/ можно установить, изменив sni:
curl -v -4 -k https://vk.com --connect-to ::45.83.223.209
В ответ будет 400 Bad Request, но всё-таки ответ.
Причём, вместо vk.com может быть что угодно, главное не mullvad.net.
Посему решил пробить блок с помощью ByeDPI (ciadpi). Но безуспешно.
Правда, одна очень хитрая стратегия (которую выкладывали здесь на форуме) пробивает через раз, но только mullvad, не tuta.com.
Я склоняюсь к тому, что это или ТСПУ или проблема связности.
Но поскольку ByeDPI иногда помогает, это намекает на ТСПУ, на очень хитрый ТСПУ. Но в котором очень мало правил, поскольку трафик магистральный.
curl -v -4 -k https://vk.com --connect-to ::45.83.223.209
позволяет увидеть ответ сервера. Но там в ответ приходит только заголовок 400. Возможно, заголовок пролезает, а всё, что крупнее, режется.
Подмену sni в ByDPI не применял, не знаю как.
mailfence.com не пробивается vk.com, но max.ru/hltv.org работает. У tuta.com походу полноценный блок по IP адресу, попробовал разные SNI и ни один из них не сработал.
С IP адресом mullvad.net у меня просто выдаёт Invalid host header.
Zapret не захотел ставить. Попробовал подмену sni на vk.com в PowerTunnel (MITM proxy на Java).
mullvad.net пробивается (под варпом, имею в виду). mailfence.com гораздо менее успешно, но иногда открывается (тоже через PowerTunnel под варпом). Остальные глухо.
Кстати, на кемеровской впске с ТСПУ (без варпа) mullvad.net и mailfence.com тоже заблокированы.
И поведение обхода очень похожи. mullvad.net пробивается чаще, mailfence.com гораздо реже. tuta блок по IP.
В общем, можно сказать наличие ТСПУ на варпе удалось подтвердить.
Добавили на магистрал блок почтовиков.