Введение
Диагностировать сеть проще, если проверять её уровни по очереди. Сначала проверьте идентификатор узла, затем его интерфейсы и адреса, выбор маршрута, базовую доступность, разрешение имён, прослушиваемые сокеты, ответ приложения и, наконец, локальную политику межсетевого экрана.
В этой лабораторной работе вы пройдёте такую последовательность на узле Ubuntu. Подготовленная служба HTTP прослушивает только loopback-порт 8088, поэтому вы сможете безопасно попрактиковаться с ss, curl и правилами UFW. Вы не будете изменять конфигурацию интерфейсов узла, маршрут по умолчанию, настройки DNS или службу SSH. Перед включением UFW вы явно сохраните доступ по SSH.
Определите имя узла
На этом шаге вы проверите имя узла и локальные записи имён, которые помогают программам идентифицировать эту машину.
Перейдите в рабочий каталог лабораторной работы:
cd /home/labex/project/network-lab
Выведите текущее имя узла:
hostname
Отобразите статическую, временную и операционную идентификацию, известную systemd:
hostnamectl
Static hostname — это настроенное имя узла. На учебных облачных машинах временное имя может назначаться во время загрузки.
Проверьте локальные сопоставления имён:
cat /etc/hosts
Имена loopback localhost, 127.0.0.1 и ::1 обозначают этот же узел без использования внешней сети. Выведите назначенные узлу IP-адреса в компактном формате:
hostname -I
Сохраните имя узла и список адресов:
printf 'hostname=%s\naddresses=%s\n' "$(hostname)" "$(hostname -I | xargs)" > host-identity.txt
cat host-identity.txt
Проверьте интерфейсы и IP-адреса
На этом шаге вы определите сетевые интерфейсы, состояние соединения, IPv4-адреса, префиксы и область действия адресов.
Используйте краткое представление интерфейсов:
ip -brief link
lo — это loopback-интерфейс. Другой интерфейс, обычно с именем eth0 или ens..., подключает виртуальную машину к сети. Состояние UP означает, что интерфейс включён административно.
Выведите адреса в компактном формате:
ip -brief address
Адрес, например 192.0.2.10/24, объединяет IPv4-адрес и длину префикса. Префикс определяет, какие старшие биты обозначают локальную сеть.
Подробно проверьте loopback-интерфейс:
ip address show dev lo
IPv4-адрес 127.0.0.1/8 имеет scope host, поэтому он действителен только внутри этого узла. Найдите интерфейс, используемый маршрутом по умолчанию:
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Primary interface: $primary_if"
ip address show dev "$primary_if"
Команда ifconfig — это устаревший инструмент для работы с интерфейсами, который по-прежнему встречается в существующих инструкциях и руководствах по устранению неполадок. Сравните её вывод с современным выводом ip, который вы только что просмотрели:
ifconfig
Сохраните также представление в формате устаревшего инструмента:
ifconfig > ifconfig-addresses.txt
Сохраните краткий снимок интерфейсов:
ip -brief address > interface-addresses.txt
cat interface-addresses.txt
Изучите таблицу маршрутизации
На этом шаге вы определите шлюз по умолчанию и спросите Linux, какой маршрут будет использован для указанного назначения.
Выведите основную таблицу маршрутизации:
ip route
Подключённые маршруты описывают сети, непосредственно подключённые к узлу. Строка, начинающаяся с default via, используется, когда не найден более конкретный подходящий маршрут.
Спросите ядро, как оно будет обращаться к общедоступному адресу назначения. Эта команда выводит выбранный шлюз, интерфейс и исходный адрес, не отправляя пакет:
ip route get 1.1.1.1
Извлеките шлюз и интерфейс по умолчанию:
gateway=$(ip route show default | awk 'NR==1 {print $3}')
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Default gateway: $gateway via $primary_if"
Сохраните сводку о маршруте:
printf 'gateway=%s\ninterface=%s\n' "$gateway" "$primary_if" > route-summary.txt
cat route-summary.txt
Проверьте доступность сети
На этом шаге вы будете использовать ping для проверки всё более удалённых границ сети и учтёте, что некоторые сети блокируют диагностические пакеты.
Начните с loopback. Параметр -c 2 отправляет два запроса, а -W 2 ждёт каждый ответ не более двух секунд:
ping -c 2 -W 2 127.0.0.1
Успешная проверка loopback подтверждает, что локальный стек IP отвечает. Затем получите и проверьте шлюз по умолчанию:
gateway=$(ip route show default | awk 'NR==1 {print $3}')
ping -c 2 -W 2 "$gateway" || echo "The gateway does not answer ICMP echo requests"
Резервное сообщение важно: маршрутизатор может пересылать трафик, но не отвечать на эхо-запросы ping. Проверьте общедоступный IP-адрес, не используя DNS:
ping -c 2 -W 2 1.1.1.1 || echo "Public ICMP is blocked or unavailable"
Сохраните стабильный результат локальной проверки доступности, не зависящий от внешней политики:
ping -c 1 -W 2 127.0.0.1 > loopback-ping.txt
tail -n 2 loopback-ping.txt
Проверьте разрешение имён узлов
На этом шаге вы изучите конфигурацию средства разрешения имён и преобразуете имена узлов в адреса.
Просмотрите файл средства разрешения имён, который используют стандартные приложения Linux:
cat /etc/resolv.conf
Обычно в нём содержится одна или несколько строк nameserver. На узлах с systemd-resolved этот адрес может обозначать локальный stub-resolver, а не внешний DNS-сервер напрямую.
Разрешите локальное имя через полную конфигурацию службы имён системы:
getent hosts localhost
getent следует настройкам /etc/nsswitch.conf, поэтому он может объединять данные из /etc/hosts, DNS и других настроенных источников. Разрешите внешнее имя и запросите адреса сокетов IPv4:
getent ahostsv4 example.com
Если проверка IP с помощью ping проходит, а этот запрос завершается ошибкой, сосредоточьтесь на конфигурации средства разрешения имён или доступности DNS. Сохраните первую найденную запись IPv4:
getent ahostsv4 example.com | head -n 1 > dns-result.txt
cat dns-result.txt
Проверьте прослушиваемый порт и ответ HTTP
На этом шаге вы свяжете прослушиваемый TCP-сокет с процессом, которому он принадлежит, и проверите протокол приложения.
Подготовленная демонстрационная служба прослушивает loopback-порт 8088. Используйте ss, чтобы проверить прослушиваемые TCP-сокеты. Параметры -l, -t, -n и -p означают прослушивание, TCP, числовые адреса и сведения о процессе соответственно:
sudo ss -ltnp | grep ':8088'
Найдите строку 127.0.0.1:8088. Привязка к loopback означает, что служба доступна только с этого узла.
Проверьте процесс службы, которому принадлежит этот сокет:
systemctl status labex-network-demo.service --no-pager
Используйте curl -i, чтобы вывести заголовки и тело HTTP-ответа:
curl -i http://127.0.0.1:8088/
Статус HTTP 200 OK подтверждает больше, чем просто открытый порт: приложение приняло HTTP-запрос и вернуло содержимое. Сохраните только тело ответа, используя тихий режим -s:
cd /home/labex/project/network-lab
curl -s http://127.0.0.1:8088/ > http-response.html
grep 'network demo ready' http-response.html
Сохраните доступ и включите UFW
На этом шаге вы проверите состояние UFW, сохраните удалённый административный доступ, разрешите порт демонстрационной службы и включите межсетевой экран.
UFW — это интерфейс для правил фильтрации пакетов Linux. Проверьте его текущее состояние:
sudo ufw status verbose
После настройки UFW остаётся неактивным, а набор правил — пустым. Перед включением межсетевого экрана на удалённом узле разрешите используемый вами канал управления. Эта виртуальная машина использует TCP-порт 22 для SSH:
sudo ufw allow 22/tcp
Теперь разрешите входящий TCP-трафик к порту демонстрационной службы:
sudo ufw allow 8088/tcp
Проверьте подготовленные изменения перед активацией:
sudo ufw show added
Включите UFW без запроса интерактивного подтверждения:
sudo ufw --force enable
Убедитесь, что межсетевой экран активен и оба разрешения присутствуют:
sudo ufw status verbose
Служба привязана к loopback, поэтому после изменения правил проверьте её локально:
curl -fsS http://127.0.0.1:8088/
Сохраните активное состояние как наблюдаемый результат:
cd /home/labex/project/network-lab
sudo ufw status verbose > firewall-status.txt
cat firewall-status.txt
Порядок действий важен: сохраните канал администрирования, добавьте необходимые правила для службы, включите межсетевой экран и сразу проверьте как политику, так и доступность приложения. На рабочих узлах может использоваться другой порт SSH, поэтому сначала определите фактический канал управления, а не предполагайте, что это порт 22.
Итоги
Вы прошли структурированную цепочку диагностики сети Linux: идентификация узла, интерфейсы и IP-адреса, выбор маршрута, доступность, разрешение имён, прослушиваемые сокеты и HTTP-ответ. Вы узнали, что каждый уровень отвечает на отдельный вопрос, а сбой на одной границе сужает область следующего исследования.
Кроме того, вы сохранили доступ по SSH, разрешили порт демонстрационной службы, включили UFW и проверили как активную политику, так и ответ приложения. Эти навыки помогут диагностировать и защищать сетевую службу без широких и потенциально disruptive-изменений.
