8 способов узнать, на каком хостинге находится сайт

Одна из важнейших подсистем, отвечающая за связь любого сервера с внешним миром — сетевая. Через сетевые интерфейсы поступают запросы от удаленных систем и через эти же интерфейсы направляются ответы, что позволяет налаживать коммуникацию и предоставлять/получать сервисы. В связи с этим особенно важно уметь производить диагностику и мониторинг сети хотя бы на базовом уровне, чтобы выявлять проблемы и вносить корректировки в конфигурацию в случае необходимости.

Облачные серверыIntel Xeon Gold 6254 3.1 GHz CPU, SLA 99,9%^от249 руб/месяц

Для операционных систем семейства Linux написано множество утилит, помогающих в диагностике и мониторинге. Познакомимся с наиболее часто используемыми из них.

Диагностика сетевой связности (ping, arp, traceroute)

В данной статье мы будем опираться на использование протокола IP версии 4. Согласно стандартам, определяющим работу этого протокола, каждое устройство, подключенное к сети, должно иметь как минимум IP-адрес и маску подсети — параметры, которые позволяют уникально идентифицировать устройство в пределах определенной сети. В такой конфигурации устройство может обмениваться сетевыми пакетами с другими устройствами в пределах той же самой логической сети. Если к этому набору параметров добавить адрес шлюза по умолчанию — наш сервер сможет связываться с хостами, находящимися за пределами локального адресного пространства.

В случае каких-либо сетевых проблем в первую очередь проверяем, не сбились ли настройки сетевого интерфейса. Например, команды ipaddr или ifconfig выведут IP-адрес и маску сети:

В выводе команды виден перечень сетевых интерфейсов, распознанных операционной системой. Интерфейс lo — это псевдоинтерфейс (loopback). Он не используется в реальных взаимодействиях с удаленными хостами, а вот интерфейс с именем ens192 — то, что нам нужно (именование сетевых интерфейсов различается в разных ветках и версиях ОС Linux). IP-адрес и маска сети, назначенные этому интерфейсу, указаны в поле inet — /24 после адреса обозначают 24-битную маску 255.255.255.0.

Теперь проверим, указан ли шлюз по умолчанию. Команды iproute или route покажут имеющиеся маршруты:

В таблице маршрутизации мы видим, что имеется маршрут по умолчанию (обозначается либо ключевым словом default, либо адресом 0.0.0.0). Все пакеты, предназначенные для внешних сетей, должны направляться на указанный в маршруте адрес через обозначенный сетевой интерфейс.

Если в настройках интерфейса есть ошибки, их необходимо исправить — помогут в этом другие статьи, для ОС Ubuntu 18.04 или CentOS. Если же все верно — приступаем к диагностике с помощью утилиты ping. Данная команда отправляет специальные сетевые пакеты на удаленный IP-адрес (ICMP Request) и ожидает ответные пакеты (ICMP Reply). Таким образом можно проверить сетевую связность — маршрутизируются ли сетевые пакеты между IP-адресами отправителя и получателя.

Синтаксис команды ping IP/имя опции:

В данном случае видим, что на оба сетевых пакета, отправленных на адрес нашего шлюза по умолчанию, получены ответы, потерь нет. Это значит, что на уровне локальной сети со связностью все в порядке. Помимо количества полученных/потерянных сетевых пакетов мы можем увидеть время, которое было затрачено на прохождение запроса и ответа – параметр RTT (Round Trip Time). Этот параметр может быть очень важен при диагностике проблем, связанных с нестабильностью связи и скоростью соединения.

Часто используемые параметры:

• ping –c количество — указать количество пакетов, которое будет отправлено адресату (по умолчанию пакеты отправляются до тех пор, пока пользователь не прервет выполнение команды. Этот режим можно использовать, чтобы проверить стабильность сетевого соединения. Если параметр RTT будет сильно изменяться в ходе проверки, значит где-то на протяжении маршрута есть проблема);
• ping –s количество — указать размер пакета в байтах. По умолчанию проверка производится малыми пакетами. Чтобы проверить работу сетевых устройств с пакетами большего размера, можно использовать этот параметр;
• ping –I интерфейс — указать сетевой интерфейс, с которого будет отправлен запрос (актуально при наличии нескольких сетевых интерфейсов и необходимости проверить прохождение пакетов по конкретному сетевому маршруту).

В случае, если при использовании команды ping пакеты от шлюза (или другого хоста, находящегося в одной локальной сети с сервером-отправителем) в ответ не приходят, стоит проверить сетевую связность на уровне Ethernet. Здесь для коммуникации между устройствами используются так называемые MAC-адреса сетевых интерфейсов. За разрешение Ethernet-адресов отвечает протокол ARP (Address Resolution Protocol) и с помощью одноименной утилиты мы можем проверить корректность работы на этом уровне. Запустим команду arp –n и проверим результат:

Команда выведет список IP-адресов (так как был использован аргумент –n), и соответствующие им MAC-адреса хостов, находящиеся в одной сети с нашим сервером. Если в этом списке есть IP, который мы пытаемся пинговать, и соответствующий ему MAC, значит сеть работает и, возможно, ICMP-пакеты, которые использует команда ping, просто блокируются файрволом (либо со стороны отправителя, либо со стороны получателя). Подробнее об управлении правилами файрвола рассказано здесь и здесь.

Часто используемые параметры:

• arp –n — вывод содержимого локального arp-кэша в числовом формате. Без этой опции будет предпринята попытка определить символические имена хостов;
• arp –d адрес — удаление указанного адреса из кэша. Это может быть полезно для проверки корректности разрешения адреса. Чтобы убедиться, что в настоящий момент времени адрес разрешается корректно, можно удалить его из кэша и снова запустить ping. Если все работает правильно, адрес снова появится в кэше.

Если все предыдущие шаги завершены корректно, проверяем работу маршрутизатора — запускаем ping до сервера за пределами нашей сети, например, 8.8.8.8 (DNS-сервис от Google). Если все работает корректно, получаем результат:

В случае проблем на этом шаге, нам может помочь утилита traceroute, которая используя ту же логику запросов и ответов помогает увидеть маршрут, по которому движутся сетевые пакеты. Запускаем traceroute 8.8.8.8 –n и изучаем вывод программы:

Первым маршрутизатором на пути пакета должен быть наш локальный шлюз по умолчанию. Если дальше него пакет не уходит, возможно проблема в конфигурации маршрутизатора и нужно разбираться с ним. Если пакеты теряются на дальнейших шагах, возможно, есть проблема в промежуточной сети. А, возможно, промежуточные маршрутизаторы не отсылают ответные пакеты. В этом случае можно переключиться на использование другого протокола в traceroute.

Часто используемые опции:

• traceroute –n — вывод результата в числовом формате вместо символических имен промежуточных узлов;
• traceroute –I — использование ICMP-протокола при отслеживании маршрута. По умолчанию используются UDP-датаграммы;
• traceroute –s адрес— указать адрес источника для исходящего сетевого пакета;
• traceroute –i интерфейс— указать сетевой интерфейс, с которого будут отправляться пакеты.

Диагностика разрешения имен (nslookup, dig)

Разобравшись с сетевой связностью и маршрутизацией приходим к следующему этапу — разрешение доменных имен. В большинстве случаев в работе с удаленными сервисами мы не используем IP-адреса, а указываем доменные имена удаленных ресурсов. За перевод символических имен в IP-адреса отвечает служба DNS — это сеть серверов, которые содержат актуальную информацию о соответствии имен и IP в пределах доверенных им доменных зон.

Самый простой способ проверить работает ли разрешение имен — запустить утилиту ping с указанием доменного имени вместо IP-адреса (например, ping ya.ru). Если ответные пакеты от удаленного сервера приходят, значит все работает как надо. В противном случае нужно проверить прописан ли DNS-сервер в сетевых настройках и удается ли получить от него ответ.

Способы выяснения какой DNS-сервер использует наш сервер различаются в зависимости от используемой версии и дистрибутива ОС Linux. Например, если ОС используется Network Manager для управления сетевыми интерфейсами (CentOS, RedHat и др.), может помочь вывод команды nmcli:

В настройках сетевого интерфейса, в разделе DNS configuration, мы увидим IP-адрес сервера. В Ubuntu 18.04 и выше, использующих Netplan, используем команду systemd-resolve —status:

Используемый сервер также будет указан в настройках интерфейса, в разделе DNS Servers. В более старых версиях Ubuntu потребуется проверить содержимое файлов /etc/resolve.conf и /etc/network/interfaces. Если сервер не указан, воспользуйтесь статьей для ОС Ubuntu 18.04 или CentOS, чтобы скорректировать настройки.

Проверить работу сервиса разрешения имен нам помогут утилиты nslookup или dig. Функционально они почти идентичны: G-вывод утилиты dig содержит больше диагностической информации и гибко регулируется, но это далеко не всегда нужно. Поэтому используйте ту утилиту, которая удобна в конкретной ситуации. Если эти команды недоступны, потребуется доставить пакеты на CentOS/RedHat:

yum install bind-utils

для Debian/Ubuntu:

sudo apt install dnsutils

После успешной установки сделаем тестовые запросы:

dig ya.ru

В разделе Answer Section видим ответ от DNS сервера — IP-адрес для A-записи с доменным именем ya.ru. Разрешение имени работает корректно:

nslookup ya.ru

Аналогичный запрос утилитой nslookup выдает более компактный вывод, но вся нужная сейчас информация в нем присутствует.

Что же делать, если в ответе отсутствует IP-адрес? Возможно, DNS-сервер недоступен. Для проверки можно отправить тестовый запрос на другой DNS-сервер. Обе утилиты позволяют эти сделать. Направим тестовый запрос на DNS-сервер Google:

dig @8.8.8.8 ya.ru

nslookup ya.ru 8.8.8.8

Если имена разрешаются публичным DNS-сервером корректно, а установленным по умолчанию в ОС нет, вероятно, есть проблема в работе этого DNS-сервера. Временным решением данной проблемы может быть использование публичного DNS-сервера в качестве сервера для разрешения имен в операционной системе. В том случае, если разрешение имен не работает ни через локальный, ни через публичный DNS сервер — стоит проверить не блокируют ли правила файрвола отправку на удаленный порт 53 TCP/UDP пакетов (именно на этом порту DNS-серверы принимают запросы).

Часто используемые параметры:

• nslookup имя сервер — разрешить доменное имя, используя альтернативый сервер;
• nslookup –type=тип имя — получить запись указанного типа для доменного имени (например, nslookup -type=mx ya.ru – получить MX-записи для домена ya.ru);
• dig @сервер имя — разрешить доменное имя, используя альтернативый сервер;
• dig имя тип — получить запись указанного типа для доменного имени (например, dig ya.ru mx — получить MX-записи для домена ya.ru).

Как обычно, полный набор опций и параметров для указанных утилит можно найти во встроенной справке операционной системы, используя команду man.

В компьютерной сети , имя хост (архаично имя_узел ) является этикеткой , которая назначается на устройство , подключенное к компьютерной сети и используются для идентификации устройства в различных формах электронной связи, такие как World Wide Web . Имена хостов могут быть простыми именами, состоящими из одного слова или фразы, или они могут быть структурированными. Каждое имя хоста обычно имеет, по крайней мере, один числовой сетевой адрес, связанный с ним для маршрутизации пакетов в целях производительности и по другим причинам.

К именам хостов в

Интернете

могло быть добавлено имя домена системы доменных имен (DNS), отделенное от метки хоста точкой («точкой»). В последней форме имя хоста также называется доменным именем . Если имя домена указано полностью, включая домен верхнего уровня в Интернете, то имя хоста считается полным доменным именем (FQDN). Имена хостов, которые включают домены DNS, часто хранятся в системе доменных имен вместе с IP-адресами хоста, который они представляют, с целью сопоставления имени хоста с адресом или в обратном порядке.

Имена хостов в Интернете

В Интернете имя хоста — это доменное имя, присвоенное хост-компьютеру. Обычно это комбинация локального имени хоста с именем его родительского домена. Например, en.wikipedia.org состоит из имени локального хоста ( en ) и имени домена wikipedia.org . Такое имя хоста преобразуется в IP-адрес через файл локальных

хостов

или преобразователь системы доменных имен (DNS). Один хост-компьютер может иметь несколько имен хостов; но обычно операционная система хоста предпочитает иметь одно имя хоста, которое хост использует для себя.

Любое доменное имя также может быть именем хоста, если соблюдаются указанные ниже ограничения. Так, например, и en.wikipedia.org, и wikipedia.org являются именами хостов, потому что им обоим назначены IP-адреса. Имя хоста может быть доменным именем, если оно правильно организовано в систему доменных имен. Доменное имя может быть именем хоста, если оно было назначено интернет-хосту и связано с IP-адресом хоста.

Синтаксис

Имена хостов состоят из последовательности меток, соединенных точками. Например, «en.wikipedia.org» — это имя хоста. Каждая метка должна содержать от 1 до 63 символов. Полное имя хоста, включая разделительные точки, может содержать не более 253 символов ASCII .

Стандарты Интернета ( запросы на комментарии ) для протоколов определяют, что метки могут содержать только буквы ASCII от a до z (без учета регистра), цифры от до 9 и знак дефиса с минусом (‘-‘). Исходная спецификация имен хостов в RFC 952 запрещала меткам начинаться с цифры или символа дефиса и не могла заканчиваться дефисом. Однако последующая спецификация (RFC 1123) разрешила метки имени хоста начинаться с цифр. Никакие другие символы, знаки препинания или пробелы не допускаются. Интернационализированные доменные имена хранятся в системе доменных имен в виде строк ASCII с использованием транскрипции Punycode .

Хотя имя хоста не может содержать другие символы, такие как символ подчеркивания ( _ ), другие имена DNS могут содержать подчеркивание. Это ограничение было снято RFC 2181. Такие системы, как DomainKeys и служебные записи, используют подчеркивание как средство, гарантирующее, что их специальный символ не спутан с именами хостов. Например, _http._sctp.www.example.com указывает указатель службы для хоста веб-сервера с поддержкой SCTP (www) в домене example.com . Несмотря на стандарт, Chrome , Firefox , Internet Explorer , Edge и Safari допускают подчеркивание в именах хостов, хотя файлы cookie в IE не работают правильно, если какая-либо часть имени хоста содержит символ подчеркивания.

Однако допустимо попытаться разрешить имя хоста, состоящее из символа подчеркивания. Например, _.example.com . Это используется RFC 7816 для уменьшения объема информации, которая предоставляется промежуточным DNS-серверам во время итеративного запроса. Функция минимизации имени запроса включена по умолчанию в BIND 9.14.0.

Имя хоста en.wikipedia.org состоит из меток DNS en (имя хоста или конечный домен), wikipedia (домен второго уровня) и org (домен верхнего уровня). Метки, такие как 2600 и 3abc, могут использоваться в именах хостов, но

-hi-

, _hi_ и * hi * недействительны.

Имя хоста считается полным доменным именем (FQDN), если указаны все метки до имени домена верхнего уровня (TLD) включительно. Имя хоста en.wikipedia.org заканчивается доменом верхнего уровня org и, таким образом, является полностью определенным. В зависимости от программной реализации DNS операционной системы, неквалифицированное имя хоста может быть автоматически объединено с доменным именем по умолчанию, настроенным в системе, чтобы завершить полное доменное имя. Например, студент Массачусетского технологического института может отправить письмо на адрес «joe @ csail» и получить его автоматически от почтовой системы для отправки на

адрес

joe csail.mit.edu .

Общие рекомендации по выбору подходящего имени хоста изложены в RFC 1178.

Пример

Сатурн и Юпитер могут быть именами хостов двух устройств, подключенных к сети с именем ПК . Внутри ПК к устройствам обращаются по их именам хостов. Доменные имена устройств —

saturn.PC

и jupiter.PC соответственно. Если ПК зарегистрирован как доменное имя второго уровня в Интернете, например, как PC.net , к хостам могут обращаться полные доменные имена saturn.PC.net и jupiter.PC.net .

Смотрите также

Рекомендации

Каждый, кто работает с интернет-площадками, сталкивается с необходимостью выяснить хостинг ресурса. Для чего узнавать хостинг сайта? Чтобы:

• Определить данные о владельце площадки.
• Пожаловаться на хостера.
• Выбрать стабильный хостинг для сайта, что облегчит продвижение, поддержку.
• Удовлетворить любопытство.

</span>

Причины могут быть разными, но решить задачу нужно быстро. Как узнать, на каком хостинге находится сайт? Рассмотрим подробнее.

Содержание

Любой сервис выдаст полную информацию о ресурсе списком. Вас интересует пункт, написанный в строчке nserver, после сочетания ns.1.

Обратите внимание! Если вы ищете, кто предоставляет услуги хоста, чтобы подать жалобу, то скопируйте abuse-адрес.

Способ No4. Когда ошибки могут помочь

Под ошибками подразумеваются 404/403. С этого метода стоит начать в первую очередь, потому что он проще остальных, обладает высокой точностью, поскольку в большинстве случаев позволяет определить даже реселлера, если он установил по умолчанию свою страницу ошибки.

Обратите внимание! CMS может перехватить запрос и дать собственную ошибку 404. В этом случае следует попробовать вызвать 403 ошибку, обратившись к каталогу без индексного файла: системной папке или кэшу движка.

Лайф-хак: часто на странице ошибки высвечивается e-mail вебмастера, из которого и можно узнать домен хостера.

Минусов у метода немного. Он может не сработать, если не установлена собственная страница ошибки (это часто бывает у небольших хостеров), или если страница спрятана CMS сайта, который перехватил запрос к несуществующим файлам.

Способ No5. Хостинг и трассировка

Еще одним способом, как узнать, на каком хостинг провайдере размещен сайт, можно назвать трассировку. Для этого:

• Нажмите на клавиатуре команду Win+R.

• В появившемся окошке наберите команду cmd.exe.

• В высветившейся командной строке наберите tracert «название сайта» (кавычки сохраняются).

</span>

После анализа пройдет трассировка до ресурса со всеми роутерами. Хост сервера указан в предпоследней или последней строчке.

Способ No6. Узнаем хост сервера при помощи плагинов для браузера

Данный метод имеет смысл, если вы собираетесь постоянно определять местоположение сервера для ресурса, поскольку делать это другими способами неудобно. Расширение упростит задачу до одного клика, хотя будет работать не на всех сайтах.

Примеры расширений:

• WIPmania для Firefox.

• Who Is Hosting? и BuiltWith для Chrome.

</span>

Есть комплексные расширения, которые предоставляют информацию о сайте, но перечисленные выше наиболее просты в обращении.

Обратите внимание! Скачивайте расширение только с официальных страниц и ресурсов: часто мошенники используют их для передачи вирусных программ.

Способ No7. Виртуальный хост

Простота данного метода аналогична ошибкам 403 и 404. Часто хостеры ставят заглушки для виртуалхоста, а вот мелкие ленятся или забывают, потому им становится либо самый первый сайт, либо заглушка с панели управления (этот результат замечен с cpanel).

Проще всего сделать запрос-команду к серверу по ай пи.

Плюс этого метода в результативности: часто он срабатывает там, где отказали другие способы, особенно если хостер крупный. Точность высока, например, выделенный сервер позволяет определить не только владельца, но и реселлера.

Не срабатывает виртуалхост только у мелких хостеров (не всегда) и на серверах, работающих на cPanel, поскольку здесь выдается стандартная заглушка.

Способ No8. Reverse DNS Lookup

Этот способ основан, скорее, на человеческом факторе: для любого айпи сайта можно задать своеобразный домен по умолчанию, используя PTR. Большая часть хостеров дают домены, в которых имеется имя домена хостера.

Самый простой метод вычленить такое имя домена – «пропинговать» сайт, использовав команду ping. Для тех, кто пользуется системой Линукс имеются альтернативные команды: host, dig и nslookup.

Плюс Reverse DNS Lookup в результативности: работает команда безотказно практически везде. Если в результате вы получили домен, который не несет информации о хостере, то велика вероятность, что это VPS или выделенный сервер.

Обратите внимание! Данным методом можно пользоваться с планшета и смартфона, достаточно скачать приложение для запросов Reverse DNS Lookup.

Подводя черту

Если определение хоста для вас разовая задача, то сначала попробуйте самые простые методы: через NS-сервер или домен при помощи сторонних ресурсов. Крупные сайты часто скрывают информацию для собственной безопасности, поэтому будьте готовы потратить на решение вопроса много времени.

Если же вы периодически ищете информацию о хостерах и сайтах, то лучше сразу поставить расширение для браузера, что сэкономит не только время, но и силы.

Используемые источники:

• https://serverspace.ru/support/help/diagnostika-setevogo-podklyucheniya-ping-arp-traceroute-dig-nslookup/
• https://ru.xcv.wiki/wiki/hostname
• https://richhost.biz/sposoby-uznat-na-kakom-hostinge-sajt.html