Сайт не работает на linux сервере, что нужно проверить и сделать

Когда все сетевые интерфейсы будут включены, попробуйте снова использовать команду ping. Если проблема не устранена, убедитесь, что сетевым интерфейсам назначены IP-адреса, и они совпадают с информацией в разделе «Сеть» панели управления UpCloud.

Попробуйте перезапустить любой проблемный интерфейс с помощью следующих команд.

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

Если перезапуск сетевого интерфейса устранил проблему, отлично! Если нет, продолжайте устранение неполадок.

Проверьте файл конфигурации сети

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

В большинстве случаев файл interfaces должен содержать как минимум следующие интерфейсы.

В CentOS и других вариантах Red Hat эти конфигурации разделены на отдельные файлы для каждого сетевого интерфейса и хранятся в /etc/sysconfig/network-scripts/. Интерфейс по умолчанию для подключения к Интернету обычно называется eth0, откройте соответствующий файл конфигурации.

Файл конфигурации для eth0 должен выглядеть так.

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

Проверьте DNS-записи серверов

Если ping с IP-адресом работает, но обычное соединение по-прежнему не работает, попробуйте вместо этого проверить связь с доменным именем. Например, вы можете пропинговать домен UpCloud таким образом.

Если домен не отвечает, проблема, скорее всего, связана с тем, как ваш сервер преобразует доменные имена в IP-адреса. Проверьте записи DNS вашего сервера.

Список должен содержать как минимум 1 сервер имен. Все резолверы DNS по умолчанию в UpCloud имеют одинаковые IP-адреса независимо от зоны доступности. DNS-серверы предоставляются автоматически по протоколу DHCP, поэтому в операционной системе не требуется ручная настройка.

Если ваш сервер имеет общедоступный IPv6-адрес, вы также можете использовать IPv6 со следующими серверами:

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

На серверах Debian, на которых не установлен resolvconf, вы можете напрямую редактировать файл resolv.conf.

Добавьте строки, показанные ниже, в файл, сохраните и выйдите.

Те, у кого установлен resolvconf, в случае, если resolv.conf все еще пуст после команды обновления, вы можете добавить серверы имен в свой файл интерфейсов. Откройте его для редактирования.

Добавьте сервер имен в конец раздела eth0.

После этого сохраните файл и выйдите. Вам также потребуется перезапустить сетевую службу с помощью следующей команды.

В CentOS и других вариантах Red Hat файл resolv.conf заполняется немного по-другому. Если файл пуст, вы можете добавить до двух записей DNS в файл конфигурации сети для сети. интерфейс, отвечающий за публичный IP. Например, откройте ifcfg-eth0 с помощью следующей команды.

Отредактируйте файл, чтобы он выглядел следующим образом.

Выйдите из редактора и перезапустите интерфейс, файл конфигурации которого вы только что редактировали, с помощью команд ifdown и ifup.

Проверьте соединение в обоих направлениях

Попробуйте пропинговать свой сервер через Интернет. Откройте терминал или командную строку на своем компьютере и попробуйте пропинговать общедоступный IP-адрес вашего сервера, который вы можете найти в панели управления UpCloud в разделе «Сеть».

Проверьте подключение к Интернету, отправив эхо-запрос на другой сайт с вашего сервера. Например, используйте следующую команду, чтобы пропинговать общедоступный DNS Google.

Если у вас есть второй сервер, развернутый в вашей учетной записи, и проблема связана с интерфейсом, назначенным с частным IP-адресом, попробуйте выполнить эхо-запрос с другим сервером, используя частные IP-адреса, указанные в панели управления UpCloud.

Если проверка связи не дает ответа, попробуйте перезапустить все сетевые службы вашего сервера. В Debian и Ubuntu 12.04 или более ранней версии используйте приведенную ниже команду.

В CentOS и других системах на базе Red Hat вместо этого перезапустите сеть с помощью приведенной ниже команды.

В Ubuntu 14.04 и новее вам нужно будет запустить команду для каждого сетевого интерфейса отдельно, например, вы можете перезапустить eth0 просто следующим образом.

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

Узнайте, где происходит сбой соединения

Ваше основное подключение к Интернету сводится к знанию маршрута до пункта назначения. Иногда маршрутизация соединения может зайти в тупик, что приведет к сбою соединения. Запустите трассировку маршрута со своего сервера, чтобы увидеть, на каком сетевом узле теряется соединение.

Для этой цели на серверах Ubuntu есть сетевой инструмент mtr. Запустите его с помощью следующей команды.

Чтобы выйти, просто нажмите q на клавиатуре.

Чтобы сделать это в системах Debian, где mtr обычно не устанавливается по умолчанию, вместо этого можно использовать traceroute.

На серверах CentOS используйте команду tracepath.

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

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

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

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

Настройки брандмауэра

Убедитесь, что ваше соединение не блокируется брандмауэром. CentOS и некоторые другие дистрибутивы на основе Red Hat по умолчанию имеют строгие правила брандмауэра. Следующая команда выведет список всех правил брандмауэра на стороне сервера в вашей системе.

Iptables — это встроенный в Linux программный брандмауэр, и приведенная выше команда выводит следующее.

Ваша панель управления UpCloud также предоставляет легко настраиваемый брандмауэр в настройках сервера на вкладке Брандмауэр.

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

Информация о статусе хоста

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

Главный редактор и технический писатель в UpCloud с 2015 года. Энтузиаст облачных вычислений, пишущий о серверных технологиях и программном обеспечении.

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

Конечно, обвинения не решают проблемы. Потратив время на понимание основ чьей-то области, вы сможете улучшить отношения с другими командами и ускорить решение проблем. Этот факт особенно актуален для системных администраторов. Имея базовые знания об устранении неполадок в сети, мы можем предоставить более убедительные доказательства нашим коллегам по сетевым технологиям, когда мы подозреваем, что сеть может быть виновата. Точно так же мы часто можем сэкономить время, выполнив первоначальное устранение неполадок самостоятельно.

В этой статье мы рассмотрим основы устранения неполадок в сети с помощью командной строки Linux.

Краткий обзор модели TCP/IP

Для начала рассмотрим основы сетевой модели TCP/IP. Хотя большинство людей используют модель взаимодействия открытых систем (OSI) для обсуждения теории сети, модель TCP/IP более точно представляет набор протоколов, развернутых в современных сетях.

Уровни сетевой модели TCP/IP по порядку включают:

Я предполагаю, что вы знакомы с этой моделью, и перейдем к обсуждению способов устранения неполадок на уровнях стека с 1 по 4. С чего начать устранение неполадок, зависит от ситуации. Например, если вы можете подключиться к серверу по SSH, но сервер не может подключиться к базе данных MySQL, проблема вряд ли связана с физическим уровнем или уровнем канала передачи данных на локальном сервере. В общем, неплохо идти вниз по стеку. Начните с приложения, а затем постепенно устраняйте неполадки на каждом нижнем уровне, пока не изолируете проблему.

После этого перейдем к командной строке и приступим к устранению неполадок.

Уровень 1: физический уровень

Часто мы воспринимаем физический уровень как должное ("Вы убедились, что кабель подключен?"), но мы можем легко устранять неполадки физического уровня из командной строки Linux. Это если у вас есть консольное подключение к хосту, что может быть не так для некоторых удаленных систем.

Начнем с самого основного вопроса: работает ли наш физический интерфейс? Команда ip link show сообщает нам:

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

Прежде чем приступать к проверке кабелей, рекомендуется убедиться, что интерфейс не просто отключен. Выдача команды для включения интерфейса может исключить эту проблему:

Вывод ip link show может быть трудно проанализировать с первого взгляда. К счастью, параметр -br выводит этот вывод в гораздо более удобном для чтения формате таблицы:

Похоже, ip link set eth0 помог, и eth0 снова в деле.

Дополнительные ресурсы по Linux

Эти команды отлично подходят для устранения очевидных физических проблем, но как насчет более коварных проблем? Интерфейсы могут согласовываться с неправильной скоростью, а коллизии и проблемы на физическом уровне могут привести к потере или повреждению пакетов, что приведет к дорогостоящим повторным передачам. С чего начать устранение этих проблем?

Мы можем использовать флаг -s с командой ip для вывода дополнительной статистики об интерфейсе. Вывод ниже показывает в основном чистый интерфейс, всего несколько отброшенных пакетов приема и никаких других признаков проблем физического уровня:

Для более сложного устранения неполадок уровня 1 отлично подходит утилита ethtool. Особенно хорошим вариантом использования этой команды является проверка того, согласовал ли интерфейс правильную скорость. Интерфейс, который согласовал неправильную скорость (например, интерфейс 10 Гбит/с, который сообщает только о скорости 1 Гбит/с), может быть индикатором проблемы с оборудованием/кабелем или неправильной конфигурацией согласования на одной стороне канала (например, неправильно настроенный порт коммутатора).< /p>

Наши результаты могут выглядеть следующим образом:

Обратите внимание, что в выходных данных выше показан канал, который правильно согласовал скорость 1000 Мбит/с и полнодуплексный режим.

Уровень 2. Канальный уровень

Уровень канала передачи данных отвечает за подключение к локальной сети; по сути, это передача кадров между хостами в одном и том же домене уровня 2 (обычно называемом локальной сетью). Наиболее подходящим протоколом уровня 2 для большинства системных администраторов является протокол разрешения адресов (ARP), который сопоставляет IP-адреса уровня 3 с MAC-адресами Ethernet уровня 2. Когда хост пытается связаться с другим хостом в своей локальной сети (например, со шлюзом по умолчанию), он, скорее всего, имеет IP-адрес другого хоста, но не знает MAC-адреса другого хоста. ARP решает эту проблему и вычисляет MAC-адрес для нас.

Распространенной проблемой, с которой вы можете столкнуться, является запись ARP, которая не заполняется, особенно для шлюза вашего хоста по умолчанию. Если ваш локальный хост не может успешно разрешить MAC-адрес своего шлюза уровня 2, он не сможет отправлять трафик в удаленные сети. Эта проблема может быть вызвана неверным IP-адресом, настроенным для шлюза, или другой проблемой, например неправильно настроенным портом коммутатора.

Мы можем проверить записи в нашей таблице ARP с помощью команды ip Neighbor:

Еще одно распространенное использование команды ip Neighbor связано с управлением таблицей ARP. Представьте, что ваша сетевая команда только что заменила вышестоящий маршрутизатор (который является шлюзом вашего сервера по умолчанию). MAC-адрес также мог быть изменен, поскольку MAC-адреса — это аппаратные адреса, которые назначаются на заводе.

Примечание. Хотя уникальные MAC-адреса назначаются устройствам на заводе, их можно изменить или подделать. Многие современные сети также часто используют такие протоколы, как протокол избыточности виртуального маршрутизатора (VRRP), в котором используется сгенерированный MAC-адрес.

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

В приведенном выше примере мы видим заполненную запись ARP для 192.168.122.70 на eth0. Затем мы удаляем запись ARP и видим, что она была удалена из таблицы.

Уровень 3: сетевой/интернет-уровень

Уровень 3 включает работу с IP-адресами, которые должны быть знакомы любому системному администратору. IP-адресация предоставляет хостам способ связаться с другими хостами, находящимися за пределами их локальной сети (хотя мы часто используем их и в локальных сетях). Одним из первых шагов устранения неполадок является проверка локального IP-адреса машины, которую можно выполнить с помощью команды ip address, снова используя флаг -br для упрощения вывода:

Мы видим, что наш интерфейс eth0 имеет IPv4-адрес 192.168.122.135. Если бы у нас не было IP-адреса, мы бы хотели устранить эту проблему. Отсутствие IP-адреса может быть вызвано локальной неправильной настройкой, например неверным файлом конфигурации сетевого интерфейса, или проблемами с DHCP.

Наиболее распространенным передовым инструментом, который большинство системных администраторов используют для устранения неполадок уровня 3, является утилита ping.Ping отправляет пакет эхо-запроса ICMP на удаленный хост и ожидает в ответ эхо-ответ ICMP. Если у вас возникли проблемы с подключением к удаленному хосту, ping — это обычная утилита для начала устранения неполадок. Выполнение простого эхо-запроса из командной строки бесконечно отправляет эхо-сигналы ICMP на удаленный хост; вам нужно будет нажать CTRL+C, чтобы завершить проверку связи, или передать флаг -c, например:

Обратите внимание, что каждый пинг включает время, которое потребовалось для получения ответа. Хотя ping может быть простым способом узнать, жив ли хост и отвечает ли он, он ни в коем случае не является окончательным. Многие сетевые операторы блокируют пакеты ICMP из соображений безопасности, хотя многие другие не согласны с этой практикой. Еще одна распространенная ошибка заключается в использовании поля времени как точного индикатора задержки в сети. Скорость пакетов ICMP может быть ограничена промежуточным сетевым оборудованием, и не следует полагаться на то, что они обеспечивают достоверное представление о задержке приложения.

Следующим инструментом в наборе инструментов для устранения неполадок уровня 3 является команда traceroute. Traceroute использует поле Time to Live (TTL) в IP-пакетах, чтобы определить путь, по которому трафик идет к месту назначения. Traceroute будет отправлять по одному пакету за раз, начиная с TTL, равного единице. Поскольку срок действия пакета истекает в пути, вышестоящий маршрутизатор отправляет обратно пакет ICMP Time-to-Live Exceeded. Затем traceroute увеличивает TTL, чтобы определить следующий переход. В результате получается список промежуточных маршрутизаторов, через которые проходил пакет на пути к месту назначения:

Traceroute кажется отличным инструментом, но важно понимать его ограничения. Как и в случае ICMP, промежуточные маршрутизаторы могут фильтровать пакеты, на которые опирается traceroute, например сообщение ICMP Time-to-Live Exceeded. Но что еще более важно, путь, по которому идет трафик к месту назначения и обратно, не обязательно симметричен и не всегда одинаков. Traceroute может ввести вас в заблуждение, заставив думать, что ваш трафик идет по прямолинейному пути к месту назначения и обратно. Однако такая ситуация бывает редко. Трафик может следовать по другому обратному пути, и пути могут динамически меняться по многим причинам. Хотя traceroute может обеспечить точное представление пути в небольших корпоративных сетях, он часто не точен при попытке отследить большие сети или Интернет.

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

Мы можем распечатать таблицу маршрутизации с помощью команды ip route show:

В простых топологиях часто настроен только шлюз по умолчанию, представленный записью "по умолчанию" в верхней части таблицы. Распространенной проблемой является отсутствующий или неправильный шлюз по умолчанию.

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

В приведенном выше примере мы отправляем весь трафик, предназначенный для сети 10.0.0.0/8, на другой шлюз (192.168.122.200).

Ярким признаком проблемы с DNS является возможность подключения к удаленному хосту по IP-адресу, но не по имени хоста. Выполнение быстрого nslookup по имени хоста может многое нам рассказать ( nslookup является частью пакета bind-utils в системах на базе Red Hat Enterprise Linux):

Вышеприведенные выходные данные показывают серверу, что поиск был выполнен по адресу 192.168.122.1, и в результате был получен IP-адрес 172.217.3.100.

Если вы выполняете nslookup для хоста, но ping или traceroute пытаются использовать другой IP-адрес, вы, вероятно, столкнулись с проблемой записи файла хоста. Поэтому проверьте хост-файл на наличие проблем:

Уровень 4. Транспортный уровень

Транспортный уровень состоит из протоколов TCP и UDP, причем TCP является протоколом, ориентированным на установление соединения, а UDP — без установления соединения. Приложения прослушивают сокеты, которые состоят из IP-адреса и порта. Трафик, направленный на IP-адрес определенного порта, будет направляться ядром прослушивающему приложению. Полное обсуждение этих протоколов выходит за рамки этой статьи, поэтому мы сосредоточимся на устранении проблем с подключением на этих уровнях.

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

Давайте разберем эти флаги:

• -t — показать порты TCP.
• -u — показать порты UDP.
• -n — не пытаться разрешать имена хостов.
• -l — показать только прослушиваемые порты.
• -p — показать процессы, использующие определенный сокет.
• -4 — показывать только сокеты IPv4.

Глядя на результат, мы видим несколько сервисов прослушивания. Приложение sshd прослушивает порт 22 на всех IP-адресах, обозначенных выводом *:22.

Команда ss — это мощный инструмент, и обзор ее краткой справочной страницы может помочь вам найти флаги и параметры, чтобы найти то, что вы ищете.

Еще один распространенный сценарий устранения неполадок связан с удаленным подключением. Представьте, что ваш локальный компьютер не может подключиться к удаленному порту, например к MySQL через порт 3306. Маловероятно, но часто устанавливаемый инструмент может помочь вам при устранении проблем такого типа: telnet. Команда telnet пытается установить TCP-соединение с любым хостом и портом, который вы ей предоставляете. Эта функция идеально подходит для тестирования удаленного TCP-подключения:

В приведенном выше выводе telnet зависает, пока мы его не завершим. Этот результат говорит нам о том, что мы не можем получить доступ к порту 3306 на удаленной машине. Возможно, приложение не слушает, и нам нужно применить предыдущие шаги по устранению неполадок, используя ss на удаленном хосте — если у нас есть доступ. Другой возможностью является хост или промежуточный брандмауэр, фильтрующий трафик. Возможно, нам придется работать с сетевой командой, чтобы проверить подключение уровня 4 по пути.

Telnet отлично работает для TCP, но как насчет UDP? Инструмент netcat предоставляет простой способ проверки удаленного порта UDP:

Утилиту netcat можно использовать для многих других целей, включая проверку соединения TCP. Обратите внимание, что netcat может быть не установлен в вашей системе, и часто считается угрозой безопасности, если вы оставите его без присмотра. Возможно, вы захотите удалить его, когда закончите устранение неполадок.

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

• Сканирование портов TCP и UDP на удаленных компьютерах.
• Отпечатки ОС.
• Определение того, закрыты ли удаленные порты или просто отфильтрованы.

Подведение итогов

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

По мере вашего продвижения по устранению неполадок в сети вы, несомненно, столкнетесь с ранее неизвестными флагами команд, причудливыми однострочниками и новыми мощными инструментами (tcpdump и Wireshark — мои любимые), чтобы разобраться в причинах проблем с сетью. Получайте удовольствие и помните: посылки не врут!

Читайте также:

  
• Как переустановить Windows 10 через биос
  
• Ошибка выполнения списка задач Windows 10
  
• Какой вариант запуска Windows лучше: обычный или выборочный?
  
• Установка Linux mint oem что это такое
  
• Операция Vipnet csp в операционной системе Windows 10 не поддерживается 1 с