Сегодня в автохостлист запрета упал ocsp.digicert.com
, что довольно тревожно, т.к. это сервер проверки статуса сертификатов. Хостится вроде за edgecast, но саму cdn edgecast у меня вроде не блокируют. Странные дела.
А он по 443 не отвечает. Только по 80?
ПРЕДУПРЕЖДЕНИЕ: альтернативное имя субъекта сертификата не совпадает с именем
запрошенного узла ‘ocsp.digicert.com
’
Что же светит всё провайдеру или там внутри шифрование.
Да.
Есть, блокировки на VPS в РФ почти такие же как и у ISP.
В соседней теме предположили, что триггером является SSH-соединение с авторизацией по ключу (не паролю). Возможно, нестандартный порт тоже влияет.
У меня такое соединение есть, и блокировка была. Хотя вот прямо сейчас нет.
Это предположение противоречит с наблюдением массовых жалоб на недоступность arma31.battleye.com
у игроков, которые SSH не пользуются. Несколько дней не работает у одних, затем начинает работать и тут же перестаёт работать у других, и так уже две недели. Пятиминутное отключение роутера помогает у одних на пол-часа, у других доступность восстанавливается и не теряется (чаще всего). Больше похоже на случайное A/B тестирование для сбора статистики.
Не сильно разбираюсь что это, но если там свой протокол, то он тоже может попадать под ту же неведомую сигнатуру, по которой блочат.
UDP там, а почему всех тогда не блочат, а только примерно у 1% игроков проблема? Я тоже думал на паттерн пакета, но это происходит веерно случайным образом.
Тогда предположу, что тестируют белый список IP/протоколов, блокируя всё, что в него не входит. Но не массово, а для случайной небольшой выборки, чтобы по реакции и крикам понять, что зацепили, и насколько это чувствительно.
Эту версию подтверждает то, что по выходным блокировки нет - потому что нет определенных сотрудников, и некому быстро отреагировать при необходимости.
В общем, спустя десятки тикетов в поддержку мне подключили спеца постарше, видимо с третьей линии, с которым можно было разговаривать на техническом языке. Я ему вкратце описал проблему с хетцнером, привёл пруфы в виде дампов трафика неудачных попыток входа на легитимные сайты, и дампы с другого оператора снятые в то же время, где все работает. Он сказал, что все понял, 10 минут что-то смотрел, затем сайты на хетцнере стали доступны. Внешний адрес у меня при этом НЕ изменился, то есть, видимо, буквально вручную снимали фильтры примененные непосредственно к моему адресу.
После этого на мониторинге сайт арчлинукса не отваливался:
Сейчас в качестве эксперимента избегаю использования “классических” впн протоколов и ssh через этот канал, использую только vless-over-cdn. Посмотрим, вернется ли блок, как писали выше.
Так ты спросил что это было? Раз тспу крутить не могут, какая провайдерская железяка от хетзнера решила защитить и почему?)
Я спросил, мне ответили кратко “ошибка маршрутизации”, я конечно понимаю, что дело не может быть в этом, но уж не стал докапываться т.к. меня вся эта ситуация и общение с провайдером уже утомили. Скорее всего какие-то срочные запросы на корректировку фильтров они направлять могут, если дело не касается официально заблоченых ресурсов или ютуба.
Почему дело не может быть в этом? Хз где точно стоят тспу, но может быть их несколько на пути, на первом маршруте 1 конфиг, на втором маршруте другой конфиг (без блока hetzner). Здесь уже писали что для обхода блока некоторых сайтов через gdpi требуется ставить высокий ttl (8), что уже выходит за рамки сети провайдера
Может провайдер пустил разрешённые ресурсы в обход тспу, это тоже можно назвать маршрутизацией.
Последовал примеру и тоже написал провайдеру. Неожиданно, но это действительно сработало. После стандартных процедур “перезагрузите роутер” итд, что-то они у себя сделали и все заработало. Адрес тоже не менялся.
Теперь посмотрим сколько проживет.
Так что у кого проблемы - обращайтесь к провайдеру. Похоже это вполне поддается исправлению на их стороне.
Я и пологал что это именно пров делает, а не тспу. Пакет по трассе теряется ДО тспу. По курлу похоже на блок по ип (после резолва тишина, нету syn вообще) НО, я проверил реальные ип блоки для сравнения, там пакеты проходили через тспу по трассе. Поэтому тут 100% пров это делает. И кстати, тем кто звонил, поздравляю, вас добавили в черный лист. Вы теперь будете подопытными кроликами
Если так специально блочили, значит мы уже подопытные. У них есть договор с паспортными данными клиента, и всю историю трафика они хранят по закону. То есть от обращения здесь ни холодно ни жарко.
До этого ты был в сером списке (особенно если за дин ип или нат), а со звонком ты себя выявил
Это уже надуманная паранойя с изобретением 50 оттенков списков.
Да и хоть какой нат, провайдер прекрасно в курсе кто какой адрес в какой момент времени использовал. И судя по сообщениям о том, что в одной квартире может быть блок, а в соседней нет, внешний адрес тут даже и ни при чем.
В моем понимании “проблема с маршрутизацией” это полное либо частичное отсутствие сетевой связности по любым протоколам, а когда ICMP ходит и TCP сессия стабильно устанавливается, но сессия фризится на TLS ClientHello, это явно чьи-то проделки. У меня все симптомы были в точности как тут:
Между делом я вернулся домой и оказалось, что хетцнер снова в блоке. Отлетел в блок примерно через сутки после разблока. Ба дум тсс.
Написал этим товарищам последний тикет со ссылкой на предыдущий и сказал, что либо решают проблему окончательно, либо завтра еду к ним в офис разрывать договор. Дам им последний шанс, после этого скакну к другим и оформлю на другого человека, благо сейчас не на меня договор и есть еще люди.