Хабр Курсы для админов
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 87
К сожалению симптомы когда пинг стабильно идет, а SSH и 443 рвутся и фильтруются практически на 100% говорят сейчас, что это "изменения в настройках магистральных провайдеров". Иногда помогают обращения к тому самому ведомству, которое этими "настройками" ведает, но так умеют не все хостеры, к сожалению...
Ваш лайфхак про проверку подсети и её регистратора очень классный, спасибо!
Спасибо) У меня как раз пинг шел идеально, а 443 рвался, поэтому сперва и не думал на магистральных.
Последние 3 месяца сталкиваюсь с тем что многие мои ресурсы постепенно перестают работать с разных провайдеров. Особенно стремно за рабочие. У тебя может открываться а у клиента - нет. Директ вполне бодро списывает за это деньги
Для себя решил пока установкой reverse proxy в Yandex cloud и selectel
Для тестирования накидал сервис - который бы с локальных компьютеров проверял. ставишь клиента, он получает с сервера какие URL надо curl и отправляет отчет в сам сервис.
Клиент открытый, посмотреть можно на GitHub
Но толком не успел раскидать клиенты по друзьям/знакомым, так что пока там всего две ноды для проверки
С первых секунд все было понятно, увы :)
И да, бороться бесполезно, на старте проще выбить себе нормальный IP, что вы по сути и сделали.
полгода мучений, клиентский портал у крупнейшего провайдера, датацентр в Москве (ip меняли по запросу - не помогло). Нет доступа если интернет от МТС. Пинги, ссш - идеально, хттп - отсутствует. Выкручивались как могли (слава богу, клиентов на МТС не было). Потом само рассосалось.
Смена ip не помогла, потому что новый скорее всего был из того же блока. Само рассосалось хуже всего, причину не знаете, значит может вернуться.
ха. у знакомого через кабельный интернет не работает обновление прошивки на телефоне. через мобильный интернет от того же провайдера - все работает. магистрал у них общий и единственный в регионе в лице того же провайдера.
Формулировка "само рассосалось" пугает похлеще любого понятного сбоя, значит причина осталась на месте и однажды ночью радостно выстрелит снова)
Тут причина может в любой момент выстрелить куда угодно, заблокировать что угодно, и ничего ей за это не будет.
вы не представляете объем переписки и с МТС и с тех поддержкой сервера... у всех лапки. а по второму пункту - с тем, что у нас происходит с интернетом, выстрелить может вообще все, что угодно.
Нет доступа если интернет от МТС.
клиентов на МТС не было
собака-подозревака.jpg
Попадал на такую фигню с Яндекс Cloud, разворачивал ВМ через terraform, а они недоступны по ssh, долго не мог понять, что за фигня. А потом попробовал с другого провайдера все норм. Причем один день может работать, другой нет. Как же они надоели с этими блокировками(
Да, фильтрация ТСПУ. Из характерных признаков - мобильный трафик проходит, наземный нет.
Говорят, помогает включение HTTP/2 и выключение TLS 1.3.
Мобильный проверял, с телефона тоже не открывалось, поэтому на ТСПУ не похоже. Плюс дамп показал, что терялся SYN-ACK на обратном пути, до TLS дело не доходило, так что HTTP/2 и TLS 1.3 в моём случае лечили бы симптом.
ТСПУ обычно вмешивается уже на уровне разбора SNI или характерных сигнатур прикладного протокола. Дроп обратного SYN-ACK больше смахивает на тупую блокировку префикса по BGP
Было такое как раз из за ТСПУ и tls 1.3 - если уже установленный коннект попал под блок (по статистическим факторам например), то на протяжении нескольки минут после этого начинает работать блокировка на сетевом уровне. То есть работает - хоп, один коннект завис, и начинаются таймауты. Через 10-15-20 минут блок протухает и все вроде снова работает и бац, та же картина. Сайт был на клауд-ру, tls 1.3, проблему решил даунгрейд до 1.2
Да, фильтрация ТСПУ
Наблюдаемое поведение совершеннно не специфично для ТСПУ: так ведёт себя практически любой брандмауэр, если видит трафик, идущий только в одну сторону – не пропускает ошибочный, с его точки зрения, процесс соединения, подозревая спуфинг.
Я с таким намаялся на MS TMG в свое время (когда ещё TMG был актуален), симптомы те же: ping проходит, TCP - нет. Ну, а оборудование от RDP (которое ТСПУ) - это тоже брандмауэр по первичному предназначению ЕМНИП, и ведет себя соответственно.
И подозреваю, магистральные провайдеры тут тоже не совсем в стоороне, просто они нашли себе удобную позицию из “второго конверта” - валить всё на смежников из ГРЧЦ с их ТСПУ. А ведь если вдруг разбираться по-хорошему, то наверняка выяснится, что трафик в одну сторону, на ТСПУ заворачивает их, провадерское, оборудование с помощю policy routing- по префиксам BGP и портам, или ещё как. Но концов тут простому человеку не найти - что эти монополии, что государство - один чёрт, сплошная бюрократическая кафка. Так что выход тут один, который в статье описан - найти способ уклониться, благо это возможно: ни ГРЧЦ, ни магистралы в данном случае не злонамеренны, просто работать нормально не хотят.
И да, следует понимать, что всё это - гипотеза: она объясняет наблюдаемые явления, но возмодности ее верифицировать у меня нет.
Говорят, помогает включение HTTP/2 и выключение TLS 1.3
Ну, если говорят… ;-) . А в данном случае у автора тупо режется согласование соединения TCP (SYN - SYN-ACK - ACK), и до всяких там TLS (не говоря уж об HTTP) дело не доходит.
Ну, если говорят… ;-) . А в данном случае у автора тупо режется согласование соединения TCP (SYN - SYN-ACK - ACK), и до всяких там TLS (не говоря уж об HTTP) дело не доходит.
Это реально помогает, если это ТСПУ. Там не так работает. Блокируется не сам TLS, блокируется IP из-за того, что ТСПУ уже зафиксировало много запросов с TLS 1.3 по этому IP, посчитало его подозрительным и на какое-то время отправило в блок.
блокируется IP из-за того, что ТСПУ уже зафиксировало много запросов
Только вот такой способ блокировки выглядит нелогичичным. Логично блокировать первоначальный пакет, с SYN - если, конечно, брандмауэр (в т.ч. ТСПУ) его видит.
PS И да, “много запросов” тут - к нераскрученному сайту - явно нет.
ТТК-Иваново, СевероЗападный Интеркомтел.
Блокируется рандомно, то там, то тут. Особенно в играх-пострелушках заметно.
Примерно так и выглядело с месяц назад. У меня ТТРС был на бесплатном российском хостинге, там замаялся что блочили произвольно и обильно. Пару рефрешей сделаешь - и часа три можно отдыхать :/
На платном тарифе блоки в среднем минут на 10-15, за час-полтора.
В мобильном белом чебурнете вообще всё пичалька.
В моём случае это помогло, блокировок больше не случилось
А у вас точно был именно аналогичный случай, как и у автора? Или общего между ними - только то, что сначала не работало, а потом заработало? Вопрос тут чисто технический, связан с тем, что в случае автора ТСПУ (или какой-то другой брандмауэр - хотя откуда там быть другим брандмауэрам) не мог бы дальше проанализировать, что там работает поверх TCP, потому что соединение TCP не устанавливалось.
Вопрос тут чисто технический, связан с тем, что в случае автора ТСПУ (или какой-то другой брандмауэр - хотя откуда там быть другим брандмауэрам) не мог бы дальше проанализировать, что там работает поверх TCP, потому что соединение TCP не устанавливалось.
Я же вам выше объяснил - он уже перед этим проанализировал и начал рубить следующие соединения. Дальше через какое-то время он бан снимет, начнет пропускать, увидит несколько подозрительных для себя запросов и опять заблокирует.
Вы объясняли общие слова из другого сценария. А у автора весьма конкретная, и довльно странная, блокировка пакетов ответа на соединение была сразу, как я из статьи понял. То есть, если смотреть с технической стороны - нечто совсем другое, другой сценарий.
PS Вот то, что он вижел снаружи РФ - соединения то устанавливаются, то нет - может быть на ваш сценарий похоже. А то, что он видел изутри РФ - нет.
https://habr.com/ru/articles/1044396/
Повторяю теперь вам вопрос теперь вам: а это тут при чём? Ибо там написано:
Цензор оценивает ClientHello при TLS handshake для каждого TLS соединения.
А при блокировке установления TCP до TLS не доходит, ClientHello отправлен не будет.
Не то, чтобы это имело какое-то практичнеское значение, но меня интересуют чисто технические подробности.
Логично блокировать первоначальный пакет, с SYN - если, конечно, брандмауэр (в т.ч. ТСПУ) его видит.
Наоборот, проще и экономичнее блокировать всё при подозрениях. И с каким-то интервалом проверять, остались ли подозрения.
И да, “много запросов” тут - к нераскрученному сайту - явно нет.
Это уже догадки пошли. Мы не знаем, что такое много в понимании ТСПУ и сейчас нейронки даже на пустом сайте могут много запросов создать.
Да, очень похоже на симптом прохождения трафика с асиметричными маршрутами через statefull firewall, когда в одну сторону он идёт через этот самый файервол, а в другую - не идёт.
Однако я не понимаю как в России в таком случае работает хоть что-то. Для магистрального провайдера такой трафик должен быть самым обычным делом, магистральные ТСПУ не должны полагаться что на то, что они видят оба направления соединения.
Однако я не понимаю как в России в таком случае работает хоть что-то.
В целом - чисто божьим промыслом, не иначе ;-) Ибо ничем другим объяснить, что в России всё более-менее работает, невозможно ;-) А если серьезно, то вполне может быть, что это - обычное дело - никто ведь особо ничего не анализирует: как мы видим из дискуссии выше достаточно написать слово ТСПУ и можно дальше особо не думать. Впрочем, в данном случа мы имеем нечастое сочетание факторов: кроилово хостера, который закупает IP подешевле с других континентов, помноженное на (это мое предположение) старые костыли у магистралов, сделанные чтобы разгрузить ТСПУ, когда он начал захлёбываться
Ну, а добиваться, чтобы это всё было сделано по уму - это явно не моя задача, это пусть Шадаев работает, если хочет и может, бабло за это ему капает, не мне. Я же всего занимаюсь безнадежным (ибо мы все в конце концов умрём) делом существования в имеющихся условиях. Ну, и иногда позволяю себе небольшую гимнастику для ума, вроде той, которая в этой ветке комментариев, безо всякой практической пользы, чисто для себя. И, наверное, дальше я эту тему развивать не буду.
ТСПУ не должны полагаться что на то, что они видят оба направления соединения.
Однако как они тогда будут анализировать этот трафик? Не понимаю.
Да ну и чёрт с ними.
Я правильно понял, что у вас сервер московский на Timeweb был? Если да, пробовали их техподдержку спросить? Просто интересно. Я сам давно пользуюсь их услугами, но у меня нет серверов в РФ зоне.
Хостера намеренно не называю, дело не в компании, блок нестандартного регистратора может оказаться у любой.. Поддержку да, спрашивал, ответили что со своей стороны всё проверили и фильтрацию у магистральных не решают. Формально они правы, это не их зона.
Как не называете? Вы прямым текстом его указали в статье.
Не вижу в этом ничего плохого, если что. У TW такое бывает, но поддержка у них одна из лучших при этом.
Немного не так.
Они вполне могут сделать запрос магистралу на проблему блокировок адресов.
И магистрал должен или устранить проблему, в том числе через запрос в ГРЧЦ, или дать мотивированный отказ.
У моего коллеги был опыт связывания с этим хостингом, и ему просто рекомендовали найти сервер в пуле с белым айпи, заказывая сервер заново и проверяя руками. И, естественно, чуть позже он отказался от этого хостинга в пользу тех, где он с таким не сталкивался.
Меня конечно как сетевика поражает, что снять дамп это не самоочевидно при локализации любой сетевой проблемы
Я кстати сам с этой же хернёй столкнулся на связи между инстансом в рф и в каматере. Один к одному: tcp устанавливается, clinet hello прилетает на каматеру, он отправляет ответ, ответ в рф не приходит. Если запускать тестовые коннекты подряд , то проходит меньше половины. Проблема плавающая: то включат эту политику, то выключат.
У меня это вызывает только один вопрос: какая цель? собираются резать весь трафик до хостингов недружественных юрисдикций? или как?
Ну и плюс должен быть какой-то второй фактор для срабатывания фильтрации помимо зарубежного ASN, иначе будут страдать все сайты на зарубежных хостингах. Хотя может в этом и цель...
Дамп снимал, он в статье - SYN доходит, сервер отвечает SYN-ACK, обратно не приходит. У вас то же самое на шаг позже, на client hello. Про второй фактор в точку, соседние адреса того же ЦОД из RIPE работали нормально, значит одного зарубежного ASN мало.
какая цель? собираются резать весь трафик до хостингов недружественных юрисдикций?
Это "хитрый" план: если просто заблокировать, то начнут возникать и больше юзать средства, а так просто хостер плохо работает, сбоит почти в половине случаев.
собираются резать весь трафик до хостингов недружественных юрисдикций?
насколько память не подводит - согласно букве того прошлогоднего закона о защитах интернетов от людей прямым текстом было прописано недопущение до мессенджеров и хостеров, не входящих в реестры или не соблюдающих требования властей.
Так что пессиместично мнение - да, проверют/настраивают кусками/щупают возможность соблюсти полностью если(а то и "когда") зачем-то какой-нибудь из башен понадобится
какая цель? собираются резать весь трафик до хостингов недружественных юрисдикций?
IMHO тут цели нет, тут бритва Хэнлона работает. В бюрократической системе оно так устроено - что если цель явно не задавать, то ее части работают несогласованно, и внешне система ведёт себя как тупая - даже если отдельные люди, ее составляющие, очень умны по-своему. То есть, составляющие ее люди поставленные перед ними цели выполняют, с показателями эффективности у них всё норм (а если где не норм - там они обтекатели ставят), а результат выходит чисто по Черномырдину: получается как всегда. Такая вот, понимаете, загогулина с бюрсистемой случается раз за разом.
Скажу сразу: час я потратил впустую. Гадал вместо того, чтобы мерить.
Гадал видемо агент 🗿
Я обычно не замечаю иишность текста, но тут видимо прям перебор. Ну и недавно сам с помощью ИИ гадал похожую проблему. ИИ тут ужасно справляется.
В таких ситуациях спасает только дамп трафика на интерфейсе. Когда видишь что SYN-ACK улетает в сторону клиента и растворяется на узле аплинка, спорить с хостером становится намного проще. Без pcap-файла первая линия техподдержки будет до последнего гонять тебя по кругу стандартных скриптов
LACNIC это регистратор Латинской Америки. Адрес российского хостера, физически стоящий в Москве, формально принадлежит латиноамериканскому диапазону 201.0.0.0/8.
Почему это важно? Что это меняет? Диапазон Timeweb зарегистрирован в RIPE, вы же спрашиваете базу RIPE, а не LACNIC (она вас перенаправит в RIPE).
Диапазон зарегистрирован в российском РАНР, как российский: https://w.ranr.noc.gov.ru/?search=201.51.13.0&source=RANR
Попросил у хостера другой адрес. Выдали из семейства 200.x. Проверяю
Вы проверяете в сервисе, у которого используется коммерческая база geoip непонятной даты. Базы geoip не используются нигде ни для фильтрации, ни просто у магистральных провайдеров. Используйте хотя бы https://www.iplocation.net/ или https://iplocation.io/
Спрашивайте про диапазон до оплаты. Одна строчка в чат поддержки, «из какого блока выдаётся IPv4», экономит день переезда. Я узнал это на своих ошибках. Вы теперь знаете заранее.
Звоните в ГРЧЦ и спрашивайте, по какой причине происходит фильтрация.
Оперативный дежурный ЦМУ ССОП ФГУП “ГРЧЦ”: e-mail: support_asbi@noc.gov.ru, тел.: 8 800 600-19-62
Вторая линия технической поддержки АО «Данные и центр обработки и автоматизации»: Tel: 8-800-600-19-24, e-mail: techsupport@dcoa.ru
Тут вы правы, я смотрел через stat.ripe.net, там в block родительский /8 по IANA, оттуда LACNIC и вылез. В РАНР не заглянул, geoip взял зря, по вашей таблице почти все отдают Москву и Timeweb. Вывод про регистратор неверный, хотя резалось всё равно. Контакты ГРЧЦ пригодятся, спасибо.
Это фильтрация. Не потери, не перегрузка.
Это нейрослоп. Не знания, не опыт.
Это скоропалительное суждение. Не основанное на анализе, не результат рассуждения.
PS Интересно, много ли людей настолько не могут связать двух слов, что поручают нейронке написание комментария в пару строчек. А ещё интересно, много ли существует людей, которые верят, что таких много.
PPS Кажется, мы наблюдаем зарождение нового явления - нейронаци: это аналогично граммар-наци, но выискивают они не граматические ошибки, а признаки пользования нейронкой. А на содержание осуждаемого тектста ни те, ни другие не смотрят.
Мне кажется, здесь вывод про LACNIC-префикс сделан чуть раньше, чем позволяют измерения.
Если какой-то магистральный оператор действительно просто фильтрует весь этот префикс по происхождению, поведение должно быть достаточно детерминированным: маршрут либо проходит, либо нет. Ситуация «то работает, то не работает» скорее заставляет искать что-то path-dependent: разные аплинки/ECMP, асимметричный маршрут, stateful-фильтрацию или те же ТСПУ с не вполне очевидной логикой.
Сам по себе факт, что после смены адреса стало лучше, ещё не доказывает, что причиной был именно LACNIC. Вместе с адресом меняются префикс, маршрут до него, возможно аплинк и набор фильтрующего оборудования на пути.
И я бы всё-таки считал это в первую очередь проблемой хостера. Если хостер купил и анонсирует такой диапазон, обеспечение его нормальной связности — его задача. Клиент не должен разбираться, какой именно магистральный оператор или фильтр по дороге неправильно обращается с их префиксом.
ТСПУ как причина вполне правдоподобны, особенно если ошибка воспроизводится только с некоторых российских сетей, но из приведённых данных это пока именно гипотеза, а не установленная причина. Доказано, по-моему, более узкое утверждение: доступность зависит от маршрута до конкретного префикса, а где именно этот маршрут ломается и почему — ещё надо локализовать.
Деньги хостер вернул? )
А название этого магистрального провайдера, который вас злонамеренно блокировал, будет?
Пару лет назад было веселее: любой домен с окончанием ...messenger.com блокировался по HTTPS на всех мобильных операторах.
С жалобами пошли от оператора до Роскомнадзора, никто не признался и магическим образом конкретный домен стал работать через 2 недели. Остальные нет.
Хабре реально проиграл нейрослопу....
Во-первых, в принципе не должно быть "не таких диапазонов адресов" - это придумка сами знаете кого, за такое надо бы руки выкручивать на дыбе, но это не сейчас.
Особенно с учетом, что РКН как раз и создавался когда-то давно с целью выкручивания рук недобросовестным провайдерам/хостерам, которые будут подобным изяществом заниматься. А оно вон как получилось.
"Ты должен был бороться со злом, а не возглавить его!"
Во-вторых, буквально с первого описания симптомов понятно откуда тут ноги растут.
Нет, ну можно конечно предположить аварию серверов, баги в nginx, кривые настройки приложения или там еще что-то подобное - но где-то в 99-ю очередь, а так сразу ожидаемо, кто виноват.
Ну и в третьих, чисто непонимание: что мешало просто запустить tcpdump в фоне?
Пусть пишет свой файл, потом зайти почитать.
Для этого не нужен systemd...
я вот тоже не понял - сперва "ссш работал стабильно", а дальше - "запускал через системд, потому что ссш постоянно разрывался". Получается с ссш тоже проблемы были?
А это вот что может быть:
ssh работает стабильно, НО - если не тыкать по кнопкам постоянно, то через несколько минут отваливается.
При этом, если подключиться на этот же самый сервер по альтернативному каналу - тот же самый ssh никуда не отваливается.
То есть, вопрос тут не в настройках сервера, клиента или хостера, а в том, что кто-то по дороге на сервер решает, что нечего вам там висеть, раз от вас байты не идут.
Соответственно, если повесить там слушающий tcpdump и не тыкать регулярно хотя бы пробел - оно отваливается.
Если интерактивничать - работает стабильно.
А началось такое поведение не так уж давно, что вызывает смутные подозрения...
Как-то боролся с подобным кто-то по пути обрывал неактивные соединения, помогла опция ServerAliveInterval - регулярно в фоне опрашивает сервер - байтики шлются в обе стороны, канал на роутере держится открытым.
А началось такое поведение не так уж давно, что вызывает смутные подозрения…
А чо смутные-то: ясно как день, что сессию кто-то рвет по таймауту неактивности. Это может быть, к примеру шлюз с NAT: ему может быть жалко держать зазря ценную память. Про домашние и корпоративные NAT я такого не слышал - хотя, к примеру, у MS Forefront TMG честно был заявлен таймаут TCP соединения ЕМНИП в 1 сутки. А вот провйдерский (Carrier Grade) NAT был бы у меня под подозрением: у него и сессий много, и жабу все эти провайдеры держат породистую, которая душит сильно…
PS Вообще-то в TCP есть механизм Keep-Alive, но про него мало кто помнит, к тому же его надо отдельно включать на сокете из конкретной программы. Если поставит там разумный (а не как в прежних Windows - 2 часа, что целая вечность) таймаут для него, то он будет послать пакетики, не давая забыть про это соединение.
Но раньше-то работало, и на тех же самых провайдерах.
Значит, что-то изменилось - совпадая по времени с внедрением тотальных блокировок всего подряд
Могло произойти много всего. Например, владельцы могли сделать более агрессивные таймауты для сессий на шлюзе NAT. Почему, зачем - сие неведомо. Короче, погадать можно, но пользы от этого не будет. И да, я чисто технически не понимаю, как неактивные сессии могут быть связаны с блокировками. Никакой связи у меня в голове про это не складывается. По крайней мере - причинно-следственной.
PS У меня у самого длительных неактивных сессий не бывает, поэтому по существу наблюдения сказать ничего не могу. Меня, разве что, удивляет, что SSH такое вообще допускает: ЕМНИП там была настройка, которая отключает подключние по таймауту, и, кажется, она там стояла по дефолту.
PPS RDP же, с которым я знаком сильно лучше, в конфигурации по умолчанию рвет неактивные сессии только так, IMHO - даже чрезмерно агрессивно.
У меня тоже подобная ситуация была недавно. Мониторинг прислал алерт что сервер недоступен, начал разбираться: пинг работает, все остальное нет. Мучал техподдержку провайдера, он говорит все норм. В из сети норм, извне нет. У меня на сервере 2 контейнера - 3x-ui для впн и mtproxy для телеги. Появилось подозрение, что ркн сканирует ip адреса на некоторых портах и смотрит приветственные заголовки, видимо у mtproxy есть свой. Я поменял 2 IP из за блокировки, в итоге отключил порт и больше блокировок не было.
Весь этот код можно с уверенностью сказать, что написан нейросетью.
Пост подняли из песочницы. Больше meat proxy богу meat proxy.
Один в один ситуация была, тоже менял провайдера.
Обидно, что вместо разработки и крутых штук тратим время на подобную работу.
Была похожая по симптомам ситуация, но проявлялась почему-то только когда клиент отправляет запросы с iPhone (причем неважно - Safari или Chrome). А с Андроида и Windows - все работает.
Пока разбирался несколько дней - всё само заработало.
Направление поиска причины из-за упоминания LACNIC выбрано Вами совершенно верно. Судя по всему, ТСПУ отфильтровал адрес на хостинге в РФ, именно потому 201.0.0.0/16 - это иностранная подсеть (конечно, ТСПУ может фильтровать соединения и наоборот - потому что адрес именно российский :). Для начала whois (например, RU-CENTER https://www.nic.ru/whois/?searchWord=201.0.0.0) указывает сразу на Бразилию. Проверяем дальше, идем на https://bgp.he.net/net/201.0.0.0/16, смотрим самое главное, то, что написано в Matching Delegations - там именно Бразилия.
А теперь спросим Алису, например, про CC (country code) и она скажет:
"Важное уточнение: этот код отражает точку регистрации и юрисдикцию организации, а не обязательно то, где физически проложены все каналы или где находятся все серверы. Сеть может анонсировать префиксы из разных регионов, но «родная» страна в записи RIPE останется той, что указали при выделении ASN."
Итак, всё, что выдают сайты типа whois сервиса и пр., основываясь на БД пяти региональных регистраторов (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) обычно ограничено базовым набором сведений, которые напрямую не ответят на вопрос - Ваш IP в РФ с точки зрения адресного пространства на самом деле российский или нет? То, что вы сочтете ответом, увидев country: RU, netname: RU-блабла, source: RIPE, mnt-ref: IP-RIPE, mnt-by: IP-RIPE, organisation: (провайдер РФ), org-name: (провайдер РФ) address: (вот же, на соседней улице!) - всё это ничего не стоит и не является подтверждением, что Ваш адрес российский.
Нужно запросить у одного из RIR (раз РФ, то RIPE) список всех Интернет адресов подсетей РФ. Это официальная база данных, первоисточник. На него и ориентируется ТСПУ и сисадмины, фильтрующие доступ к портам публичных сервисов на своих Firewall. Если вашей подсети нет в этом списке - вы не в РФ (хотя маршрутизация сработает и пакет к Вам по факту в РФ дойдут).
Дополню еще фактурой:
Например, вот адрес 155.212.0.0 - всё чётко, куда ни кинь, везде RU и триколор… а глянешь в Matching Delegations на bgp.he.net, вот те раз… HK, флаг со звездой!
Теперь, как получить чёткий правильный от RIPE про эту вакханалию с адресами.
curl https://stat.ripe.net/data/country-resource-list/data.json?resource=ru- команда получила файл JSON на 282316 байт, добавляем jq, чтобы получить в текстовом виде
curl https://stat.ripe.net/data/country-resource-list/data.json?resource=ru | jq -r “.data.resources.ipv4| .[]”>ripe_ru.txt- получили текст 190235 байт, 11410 строк (с учетом того, что 30 подсетей указаны почему-то не в CIDR формате, wtf).
В общем всё преобразуем единообразно в CIDR (извините, будет bash):
#!/bin/sh
ripe=ripe_original.txt
ripe_no_cidr=ripe_no_cidr.txt
ripe_cidr1=ripe_cidr1.txt
ripe_cidr2=ripe_cidr2.txt
ripe_ru=ripe_ru.txt
curl https://stat.ripe.net/data/country-resource-list/data.json?resource=ru --insecure| jq -r '.data.resources.ipv4 | .[]' > $ripe
if !(( (stat -c %s $ripe) > 0 )); then
echo No data downloaded
exit
fi
grep '/' $ripe > $ripe_cidr1
grep '-' $ripe > $ripe_no_cidr
awk '{system("ipcalc -rn "$1 "| tail -n +2")}' $ripe_no_cidr > $ripe_cidr2
cat $ripe_cidr1 $ripe_cidr2 > $ripe_ru
if !(( (stat -c %s $ripe_ru) > 0 )); then
echo Empty data file
exit
fi
rm $ripe $ripe_no_cidr $ripe_cidr1 $ripe_cidr2- файл ripe_ru.txt теперь можно загрузить, например, в именованную таблицу адресов для сетевого фильтра обычного pfSense (FreeBSD), и теперь шлюз сможет отличить, кто из РФ стучится (его еще можно попробовать пустить), а где китайцы стучатся (чтобы просканить и хакнуть HTTP, FTP или, прости Господи, открытый наружу RDP).
Ну так вот, обсуждаемой подсети 201.0.0.0/16 там нет. Вот и ответ, почему отфильтровалось.
Кстати, зачем провы и хостеры в РФ занимаются такими серыми фишками с подсетями? По странному стечению обстоятельств, у клиентов таких провов телега и пр. вкусности лучше проталкиваются через Инет. Удивительное совпадение.
Спасибо за скрипт и разбор - это точнее моего вывода. Получается, направление было верным, а механизм я объяснил неправильно. Вписал в UPD со ссылкой на вас.
Спасибо и за статью и за коммент.
У нас довольно много серверов и проектов (для стартапа) и мы часто сталкивались с этой проблемой. И один раз даже меняли сервер (провайдер не мог поменять адрес).
Для будущих покупок серверов написал небольшую страничку с алгоритмом из статьи и коммента.
Там сразу видно распределение адреса и другая инфа, что поможет при покупке избежать лишних трат времени
https://tests.aizametki.ru/
Оставалось проверить очевидное, до чего я дошёл последним: как ведёт себя сервер с реального канала, мимо VPN
Ты же с самого начала в симптомах написал, что не работает.
Как надо было: мерить серией
Одиночная проверка бесполезна, когда отказ плавающий
Нафига? У тебя ни серией, ни эпизодом без ВПН не работает, а с ВПН через раз - снова в симптомах написано.
Ноль в
time_connectзначит, что соединение не установилось вообще. SYN ушёл, ответа нет. Не разрыв на середине передачи. Молчание.
Да ви шо?! А TCP-коннект на 443 порт у тебя как 20 раз из 20 прошел?
Это фильтрация. Не потери, не перегрузка. Избирательная блокировка TCP к конкретному адресу при живом ICMP.
Откуда такой смелый вывод? Почему не криво настроенный через ИИ фаервол?
Гипотеза, которая не объясняет все симптомы, неверна. Я трижды строил версию, объясняющую часть картины. Трижды она разваливалась о факт, который я решил считать неважным.
Дамп с сервера стоит часа гаданий. Полдня я перебирал версии снаружи, хотя SSH работал с самого начала. Одна команда tcpdump дала однозначный ответ там, где шесть гипотез дали шесть тупиков.
Ох, какая драма! Так трижды версию строил или шесть гипотез?
Как все-таки достал этот нейрослоп... Вода-вода-вода, какие-то истерические метания агента, гипотезы, скрипты. Выводы ни о чем (@ValdikSS выше написал, почему), польза нулевая.
Прочитал до конца (а я на свою беду имею привычку дочитывать и вчитываться) и сидишь, как в мозг изнасилованный...
IPv6 всех спасёт, говорили они.
Тем временем шёл 2026 год...
Я проходил ровно те же пути, поэтому эту боль понимаю. Я бился неделю, думал проблема во мне)))
В итоге сдался и переехал к другому хостеру - все проблемы как рукой сняло.
Я думаю дело не в ip, а в фильтрах таймвеба. Nextjs отправляет prefetch запросы, которые легко можно принять за ddos. По крайней мере симптомы у меня были такие: утром сайт открывается, все ок, обновляешь 3-5 раз - всё, дальше через раз.
Тоже есть ВМ на TW Москва. Заббикс на днях рапортовал что хост периодически не доступен.
"пинг есть => сеть есть" это сродни "напор есть, а струи нет"
Была очень похожая ситуация с ТВ, и самое забавное, что IP от хетзнера, который на 100% бьется везде как Германия, работает без проблем, в отличии от православного московского ДЦ айпи от таймвеба к которому даже по ssh без костылей не подключиться
что говорить про самодельные/самопальные или бизнес сервисы если я с мобильного МТС/БИЛАЙН не могу часто зайти нормально то на госуслуги, то не работает "Мой налог", то просто сервис для "любителей ZX spectrum" находящийся в британии. Режут как хотят, никаких законных механизмов нет, но режут. Но и опсосам это удобно, даже свои косяки легко можно спихнуть на блокировки "где-то там".
Поймал летом схожую ситуацию с новым сервером на Бегете. После непродолжительной переписки с ТП просто сменил IP и все заработало. Правда, в том случае сервер был в Казахстане, но не суть - "некачественные" ip существуют и их надо менять.
GeoIP сейчас реально перемешан и дальше будет только хуже. Порой проверяю IP по Whois приложению показывает одно, хотя я точно знаю что должен принадлежать другой стране. Тогда в онлайн иду, там тоже у всех по разному показывает. От сюда и блокировки, желание заблокировать одно, а рушат совсем другое.
Сейчас без VPN в Интернет выйти, это всё равно что босиком на улицу выйти.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сайт не открывается из России, хотя сервер в Москве