Устранение проблем с интернет-соединением в Linux

Введение

Интернет-соединение — фундамент для обмена данными в любой современной инфраструктуре. Сетевые администраторы и инженеры часто сталкиваются с ситуациями, когда ресурсы недоступны: сайт не открывается, сервисы не отвечают или пакеты теряются в пути. Чтобы эффективно устранять такие инциденты, полезно иметь упорядоченную методику и набор инструментов для Linux/Unix.

Кратко: основная цель — сузить зону поиска (хост → сеть → провайдер → DNS → приложение) и применять простые команды для проверки состояния.

Важно: термины

• Интерфейс — сетевой адаптер, представлен командой ip.
• Маршрут — путь, по которому пакеты следуют к целевому хосту.
• DNS — система преобразования имён в IP-адреса.

Приоритетная последовательность диагностики

1. Проверить локальную сетевую конфигурацию (интерфейсы, IP).
2. Проверить связь до шлюза/маршрутизатора.
3. Проверить связь до удалённого хоста по IP.
4. Проверить разрешение имён (DNS).
5. Проверить доступность сервисов и правила брандмауэра.

Эта последовательность помогает быстро понять, на каком уровне проблема — физическом, сетевом, системном или прикладном.

Определение исходящих и входящих проблем

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

Диагностика исходящих проблем (клиент)

1. Попробуйте пропинговать внешний IP (например, шлюз или публичный DNS):

ping -c 4 8.8.8.8

2. Если 100% потеря — проверьте сетевые интерфейсы:

ip addr show

Ищите интерфейсы в состоянии DOWN или отсутствие назначенного IP.

3. Поднять интерфейс (если используется ifup/ifdown):

sudo ifup 

4. Проверить маршрутизацию — есть ли маршрут по умолчанию:

ip route show

# пример: default via 192.0.2.1 dev eth0

5. Пингуйте шлюз:

ping -c 4 

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

6. Если шлюз доступен, но до внешних IP пакеты теряются — используйте traceroute, чтобы увидеть, где теряются пакеты:

traceroute 93.184.216.34

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

Диагностика входящих проблем (сервер)

1. С внешней машины попытайтесь пропинговать сервер по IP. Если пинг не проходит, проверьте локальные настройки сервера и сетевую доступность на уровне хоста.

2. С внешнего хоста просканируйте открытые порты с помощью nmap:

nmap 

Если порты 80/443 отображаются как open — служба слушает. Если они closed — служба не запущена. Если filtered — вероятно, брандмауэр блокирует трафик.

3. Проверьте конфигурацию веб-сервера (например, Apache):

sudo systemctl status httpd
sudo journalctl -u httpd --no-pager -n 200
sudo cat /etc/httpd/conf/httpd.conf

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

Решение проблем с DNS

Симптом: по IP сайт доступен (ping к IP проходит), но по имени — нет.

1. Проверьте локальные файлы и порядок поиска имён:

• /etc/hosts — локальные соответствия имён и адресов.
• /etc/resolv.conf — список DNS-серверов, используемых системой.

2. Проверить доступность DNS-сервера:

ping -c 3 X.X.X.X

3. Прямой запрос к конкретному DNS-серверу с использованием dig или host:

dig @X.X.X.X www.google.com
host www.google.com X.X.X.X

4. Если используется NetworkManager и он перезаписывает /etc/resolv.conf, проверьте конфигурации интерфейсов. На RHEL/CentOS/Oracle Linux добавьте в файл интерфейса:

PEERDNS=no
DNS1=X.X.X.X

На Debian/Ubuntu отредактируйте /etc/network/interfaces и укажите DNS-серверы для интерфейса.

5. Если DHCP постоянно переписывает DNS, можно настроить NetworkManager или systemd-resolved в соответствии с политикой организации.

Полезно: временно изменить DNS на 1.1.1.1 или 8.8.8.8 для проверки, нужно ли это как временное решение.

Брандмауэр и фильтрация трафика

Проблемы с доступом часто вызваны правилами iptables, nftables или firewalld. Типичные шаги:

1. Просмотрите текущие правила iptables:

sudo iptables -L -n -v

2. Если используется файл /etc/sysconfig/iptables, проверьте порядок правил — правило DROP выше правило ACCEPT перекроет доступ. Перемещайте или изменяйте правила так, чтобы исключения были выше общих запрещающих правил.

3. Для firewalld проверьте зоны и активные правила:

sudo firewall-cmd --state
sudo firewall-cmd --list-all-zones
sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --reload

4. Для диагностики конкретного хоста проверьте наличие DROP по источнику (-s) и действию (-j):

# в iptables-правиле ищите -s  и -j DROP/ACCEPT

5. Убедитесь, что на промежуточных устройствах (например, облачные security groups, сетевые ACL) также разрешены необходимые порты.

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

Пошаговый playbook (SOP) для устранения недоступности сайта

1. Проверка с клиента: ping .
2. Проверка интерфейса: ip addr show.
3. Проверка маршрута: ip route show.
4. Проверка шлюза: ping .
5. Traceroute до целевого IP.
6. Проверка DNS: dig/host.
7. Проверка процесса сервера: systemctl status httpd/nginx.
8. Проверка портов: ss -tuln / nmap.
9. Проверка брандмауэра: iptables/nftables/firewalld.
10. Проверка логов приложения: /var/log/httpd/, /var/log/nginx/ и т.д.

Если проблема остаётся — переключитесь на escalated support или сетевого инженера и предоставьте результаты вышеуказанных команд.

Чеклисты по ролям

• Помощник службы поддержки (Helpdesk):

  • Подтвердить проблему у клиента.
  • Собрать вывод ping, traceroute и скриншоты ошибок браузера.
  • Проверить, может ли другой клиент открыть ресурс.

• Системный администратор:

  • Проверить сервисы и логи на целевом сервере.
  • Проверить локальные правила брандмауэра.
  • Проверить конфигурацию веб-сервера.

• Сетевой инженер:

  • Проверить магистральный трафик и маршруты.
  • Проверить маршрутизаторы/коммутаторы на ошибки интерфейсов.
  • Проверить ACL/NAT и связность между VLAN.

Командный шорткат / cheat-sheet

# Интерфейсы и адреса
ip addr show
ip link set dev eth0 up

# Маршруты
ip route show

# Проверка портов на локальной машине
ss -tuln | grep :80

# Traceroute
traceroute example.com

# DNS диагностика
dig @8.8.8.8 example.com
host example.com 8.8.8.8

# Сканирование снаружи
nmap -Pn -p 80,443 example.com

# Просмотр логов сервера (Apache/HTTPD)
journalctl -u httpd -n 200
sudo tail -n 200 /var/log/httpd/error_log

Когда перечисленные шаги могут не помочь — альтернативные подходы

• Проблема на уровне провайдера: свяжитесь с провайдером и проверьте фильтрацию/маршруты на их стороне.
• Проблемы BGP/маршрутизации в интернет: потребуется сетевой инженер, облачный провайдер или NOC.
• Сбой в CDN: проверьте панель CDN и статусы upstream-провайдеров.

Модель принятия решений (Mermaid)

flowchart TD
  A[Начало диагностики] --> B{Пинг по IP успешен?}
  B -- Да --> C{Пинг по имени успешен?}
  B -- Нет --> D[Проверить интерфейс и шлюз]
  C -- Да --> E[Проверить сервисы 'httpd/nginx']
  C -- Нет --> F[Проверить DNS '/etc/resolv.conf, dig']
  E --> G{Порт открыт и слушает?}
  G -- Нет --> H[Запустить сервис / проверить конфигурацию]
  G -- Да --> I[Проверить брандмауэр и сетевые ACL]
  I --> J[Исправление правил и ретест]
  H --> J
  D --> J
  F --> J
  J --> K[Проверка доступа извне]

Критерии приёмки

• Сайт доступен по имени и IP с нескольких точек.
• Nmap показывает порты 80/443 как open.
• Логи приложения не содержат критических ошибок при старте сервиса.
• Изменения в брандмауэре возвращаемы/задокументированы.

Безопасность и лучшие практики

• Не открывайте больше портов, чем необходимо.
• Документируйте изменения конфигурации и правила брандмауэра.
• Используйте журналирование и централизованный сбор логов для упрощения отладки.
• Осуществляйте минимальные права доступа и применяйте политики безопасности на границе сети (WAF, rate limiting).

Глоссарий (одной строкой)

• DNS — система преобразования доменных имён в IP-адреса.
• DHCP — протокол автоматической выдачи адресов.
• NAT — трансляция адресов между частной и публичной сетями.
• BGP — протокол обмена маршрутами между автономными системами.

Частые ошибки и варианты, когда методы не сработают

• Неполадки физического уровня: кабель повреждён, порт выключен — команды не покажут проблему на логическом уровне.
• Проблемы на стороне провайдера или CDN — локальная диагностика бессильна.
• Ошибки в облачных security groups: локальный брандмауэр может быть корректен, но cloud ACL блокирует доступ.

Пример инцидентного runbook для экстренного восстановления (коротко)

1. Собрать информацию: вывод ip addr, ip route, ss, journalctl, nmap.
2. Применить временное правило в брандмауэре для открытия порта 80/443 и проверить доступ.
3. Если решение сработало — найти и исправить корневую причину, затем откатить временное правило и задокументировать изменения.
4. Если не сработало — эскалировать с приложением логов и результатами команд.

Ресурсы и дальнейшее обучение

• man pages: man ip, man traceroute, man nmap, man dig.
• Документация дистрибутива: RHEL/CentOS, Debian/Ubuntu разделы по NetworkManager и systemd-resolved.

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