Частный случай из практики
Прежде чем приступать к сути скажу, что постараюсь быть понятным для неспециалистов, поэтому опущу кое-какие технические детали, кое о чём умолчу, а кое-что опишу,как оно есть. Некоторое время назад в нашу техническую поддержку обратился абонент. Проблему изложил так:
“Здравствуйте, пишу к вам, как в последнюю инстанцию. Сайт: https://автоюрик.рф
Не открывается этот сайт, когда я захожу на него с IP МАРТа, любой другой провайдер его открывает. (обратите пожалуйста внимание, речь именно о HTTPS протоколе, по http он открывается)
Что уже делал:
1. С Вашим менеджером Викторией пробовали подключать компьютер напрямую, без роутера, что бы исключить проблемы с ним;
2. Отмели блокировки роскомнадзором, проверив сам домен и его IP адрес в их сервисах (у них несколько инструментов для проверки, я проверял во всех, а так же проверил в сторонних сервисах, которые пробивают по базе РКН);
3. Проверил правильность настройки ssl сертификата, ваш сотрудник технической поддержки так же убедился, что с мобильного интернета сайт HTTPS автоюрик.рф открывается, что свидетельствует о правильной настройке сертификата;
4. Этот сайт далеко не единственный, который не открывается с ваших IP адресов. В сети много сайтов с ssl сертификатом от cloudflaer, некоторые открываются нормально. Пример открывающегося сайта: https://balkon.ru В доказательство моих слов привожу пример с отзывами о вашем провайдере: http://joxi.ru/8An6KJ8szj1XLAЯ понимаю, что в большинстве своём, проблема связана с роутерами у этих клиентов, или их сетевой картой, так как сам долго мучился с этим, пока не нашёл хорошую. Но реальные проблемы похоже начались ближе к концу 2017 года, так как с этого времени я начал часто встречать сайты, к которым нет доступа с ваших IP.
Если можете, решите пожалуйста эту проблему, и личная просьба — дайте пожалуйста знать, взяли ли Вы её в работу, и когда примерно ожидать её решения. Дело в том, что в зависимости от вашего ответа, мне надо принять меры к сайту автоюрик.рф, так как ему будет грош цена, если часть посетителей не смогут на него попасть, значит придётся его переводить на http протокол, и перенастраивать в панели вебмастера главное зеркало сайта.”
Как вы понимаете, мы никогда не оставляем обращения абонентов без внимания и стараемся разобраться в проблеме. В этом конкретном случае и в наше “странное” время массовых блокировок, когда на самом деле не открываются из-за этого многие ресурсы, как вы думаете, что первое приходит в голову? Точно! Мы тоже, не смотря ни на что, решили, что надо перепроверить, не попал ли IP-адрес в черный список. Посмотрели какой “айпишник” возвращает сервер DNS. Поступили по-простому, выполнили команду nslookup с указанием доменного имени, вот вывод этой команды:
C:\>nslookup xn--80aesismm1h.xn--p1ai
mart-dc.martnetwork.mart.ru
Address: 172.22.222.250
Не заслуживающий доверия ответ:
xn--80aesismm1h.xn--p1ai
Addresses: 2a03:c980:dead:1004:91:218:228:13
91.218.228.13
Оказалось, что этот адрес 91.218.228.13. Посмотрели в чёрный список РКН, он находится здесь. Нет, действительно, такой адрес в списке не значится! (Да, для внимательных: “А что это такое xn--80aesismm1h.xn--p1ai в параметрах команды nslookup?” Это всего-навсего сконвертированное имя кирилического домена. Домен-то автоюрик.рф, Name Server (NS) этого не понимает. Браузеры сами конвертируют, а консольные команды не умеют, поэтому нужно вначале преобразовать, а потом подставить в параметры команды. Как сконвертировать? Вот, например, вариант конвертора.)
Что дальше? Следующая мысль: “Хостер забанил доступ к 443-му порту с наших IP-адресов из-за вредоносной активности наших абонентов!”, собственно и абонент на это прямо указывает. Но такое спроста не бывает, надо очень сильно навредить. Мы стараемся отлавливать раньше. Тем не менее, чем чёрт не шутит, смотрим чёрные списки интернета, по ним блокируют тех, кто пытается спамить/брутфорсить и т. п., то есть не очень ответственных участников сетевого сообщества. Для этого идем на сайт The Anti-Abuse Project, например, вводим собственный IP-адрес, тот, с которого осуществляется доступ в Интернет и…, нет! Нету нас в списках, всё ОК.
Прекрасно, но решать проблему-то надо! Вдруг получаем ещё одно письмо от абонента:
“Хотел написать, что не работает, но ещё раз проверил перед отправкой письма, и сайт открылся. Правда я с девушкой по телефону поговорил вашей, может она что-то сделала. Только почему-то со смартфона с вашими IP адресами попросил пройти рекаптчу гугла, а с компьютера открылся нормально. Такое ощущение, что кто-то им здорово насолил с ваших IP адресов.”
Ну мы-то знаем, что “девушка” ничего сделать не могла, это не ее компетенция. Проверяем сами! Нет, сайт не открывается. Обсуждаем, что бы ещё такое проверить, пробуем ещё раз, оба-на — открывается.
Ну-ка, ну-ка. А что нам вернет DNS теперь? И наш сервер имен возвращает нам:
C:\>nslookup xn--80aesismm1h.xn--p1ai
mart-dc.martnetwork.mart.ru
Address: 172.22.222.250
Не заслуживающий доверия ответ:
xn--80aesismm1h.xn--p1ai
Addresses: 2400:cb00:2048:1::6812:2c6c
2400:cb00:2048:1::6812:2d6c
104.18.44.108
104.18.45.108
А адресочек-то другой, точнее их тут даже два! Давайте-ка посмотрим чьи же это адреса. Заходим на сайт RIPE. Вводим 104.18.44.108 и видим, что он принадлежит CloudFlare. Вводим 91.218.228.13, а он принадлежит Интернет Хостинг Центру. Но мы-то знаем, что наш абонент хостится на CloudFlare, значит тот адресочек, который нам выдавал NS с самого начала некорректен. На всякий пожарный проверяем. Для этого вначале выясняем, какие именно NS являются “родными” для автоюрик.рф. Первый попавшийся под руку сервис Whois сообщает:
Информация реестра
Домен XN—80AESISMM1H.XN—P1AI
Сервер DNS ben.ns.cloudflare.com
Сервер DNS ben.ns.cloudflare.com
Состояние зарегистрирован, делегирован, не проверен
Администратор домена Частное лицо «Private Person»
Регистратор RUCENTER-RF
Связь с администратором Дата регистрации 2018-05-03T08:56:25Z
Дата окончания регистрации 2019-05-03T08:56:25Z
Дата окончания периода преимущественного продления 2019-06-03
Теперь спрашиваем той же утилитой nslookup прямо у одного из NS CloudFlare:
C:\>nslookup xn--80aesismm1h.xn--p1ai ben.ns.cloudflare.com
ben.ns.cloudflare.com
Address: 173.245.59.103
xn--80aesismm1h.xn--p1ai
Addresses: 2400:cb00:2048:1::6812:2d6c
2400:cb00:2048:1::6812:2c6c
104.18.44.108
104.18.45.108
Да! Правильные адреса — 104.18.44.108 и 104.18.45.108. Ну ОК, а что же тогда это могло быть?
Для начала, нужно понимать, что Интернет это, в принципе, сетевая структура. Поэтому любая информация, которой оперируете вы, должна быть произведена кем-то в сети и затем, по цепочке посредников, передана вам. Domain Name System тут не исключение. Сервер имен (NS), поддерживающий конкретную доменную зону, является первичным источником информации. Он определяет соответствие IP-адресов доменным именам, время жизни записи об этом и много чего ещё. В конкретной ситуации интересны два параметра, так называемая A-record (address record) и TTL (Time-to-Live). A-record определяет соответствие IP-адреса и доменного имени (тут могут быть вариации, к примеру одно имя и много адресов или наоборот много имён за одним адресом), а TTL — время жизни этой информации о домене в промежуточных NS. Надо помнить, что DNS является распределённой системой хранения информации. Поэтому, каждый NS постоянно хранит только то, за что ответственен сам, всё остальное получает от цепочки посредников и хранит временно. По умолчанию, TTL, т.е время хранения не родной А-record, равна 86400 секунд (24 часа). Т.о. если конкретная запись не была востребована у NS в течение суток, то она убивается и в следующий раз её нужно снова запрашивать у посредников. Кроме того, в сетях обычно существуют как минимум два NS, у нас это ns1.mart.ru (89.28.161.1) и ns2.mart.ru (89.28.160.1). Один из них считается первичным, а другой вторичным. Обмен информацией между ними происходит с учетом времени, указанном в параметрах Refresh, Retry и Expire. В штатных ситуациях смысл имеет параметр Refresh, он определяет время, через которое вторичный NS должен обновить данные, запросив их у первичного. Посмотрим, а что с этими параметрами у нас:
C:\>nslookup -type=cname xn--80aesismm1h.xn--p1ai 89.28.160.1
ns2.mart.ru
Address: 89.28.160.1
xn--80aesismm1h.xn--p1ai
primary name server = ben.ns.cloudflare.com
responsible mail addr = dns.cloudflare.com
serial = 2027728949
refresh = 10000 (2 hours 46 mins 40 secs)
retry = 2400 (40 mins)
expire = 604800 (7 days)
default TTL = 3600 (1 hour)
Ага! TTL=3600 (1 час), а Refresh=10000 (2 часа 46 минут 40 секунд). Что это означает? Что рассинхрон по времени между нашими NS, NS в других сетях и родными для домена NS может составлять и час и значительно больше. А рассинхрон между нашими двумя NS может достигать минимум часа. Надо понимать, что наши сервера не запрашивают данные непосредственно у NS CloudFlare, потому что, напомню, интернет сетевая структура, а NS в ней много и связать каждый с каждым невозможно. Поэтому в какие-то промежутки времени пользователь может видеть разные результаты выдачи со стороны серверов имен.
Если говорить о конкретном случае, то видимо, на каком-то этапе в цепочку посредников попала некорректная A-record. Определить, где и когда мы уже не сможем, владельцу домена виднее и может быть он вспомнит какие-то свои действия, которые привели к выдаче некорректной записи. Но наши NS подхватили ее и хранили у себя, пока не истекло время жизни, тот самый TTL. И если в начале цепочки оказывается вторичный сервер имён, поддерживающий домен, то максимально, исходя из параметра Expire, замена IP адреса может произойти на 7-й дней. После этого срока запись принудительно обновляется. В нормальной ситуации, если вам нужно обновить адрес домена, вы должны загодя уменьшить все времена в параметрах.
Небольшое отступление:
Поскольку владелец домена может прописать любое соответствие доменного имени IP-адресу, у него есть возможность перенаправить чужой трафик к себе или свой к кому-то еще. На этом свойстве DNS основаны так называемые DNS-атаки, это же использовали в прошлом году, чтобы показать уязвимость системы блокировок сайтов со стороны РКН. Сегодня в реестре ведомства заблокированы более 5000 “брошенных” доменов. Любой может их выкупить и прописать A-records с любыми IP-адресами, причем, одному доменному имени может соответствовать много IP-адресов. То есть можно сильно накуролесить…
