Как проверить, что сервера видят друг друга по UDP в Linux

Проверка доступности по UDP между серверами в Linux

Проверка доступности между серверами по UDP (User Datagram Protocol) существенно сложнее, чем по TCP, из-за отсутствия встроенного механизма установки соединения и подтверждения доставки пакетов. UDP — это протокол без установления соединения, поэтому простое "пингование" как с ping (который использует ICMP) или telnet/nc в TCP- режиме не работает. Для комплексной проверки требуется комбинация инструментов и методик.

Ключевые принципы и сложности

• Отсутствие handshake: Нет эквивалента TCP SYN -> SYN & ACK -> ACK. Клиент просто отправляет датаграмму.
• Молчаливый сброс пакетов: Если порт закрыт или пакет блокируется фаерволом, сервер-получатель, как правило, НЕ отправляет ответное сообщение об ошибке (в отличие от TCP RST). Пакет тихо отбрасывается.
• Требуется слушающее приложение: Для получения пакета на целевом хосте должен работать процесс (daemon), привязанный (bind) к конкретному UDP-порту и ожидающий (listen) данные.

Основные методы проверки

1. Использование netcat (nc) — наиболее гибкий инструмент

Утилита netcat (часто nc) — это "швейцарский нож" сетевого администрирования. Для работы с UDP используйте ключ -u.

Проверка на стороне сервера-получателя (слушаем порт):

# На Server_B слушаем порт 54321 для входящих UDP1
nc -u -l -p 54321 -v

или более современный синтаксис (в некоторых дистрибутивах):

nc -u -l 54321 -v

Ключи: -u (UDP), -l (listen), -p (port), -.v (verbose). Команда будет ждать входящих данных и выводить их.

Проверка на стороне клиента-отправителя (пробуем отправить):

# На Server_A пытаемся отправить UDP-пакет на Server_B:54321
echo "TEST_UDP_PING" | nc -u -w 3 Server_B 54321

Если соединение успешно (пакет дошел до слушающего nc на Server_B), вы увидите строку "TEST_UDP_PING" в окне терминала Server_B. Важно: отсутствие вывода на стороне отправителя НЕ гарантирует неудачу, это норма для UDP.

2. Использование nmap для сканирования UDP-портов

nmap — мощный сканер портов. UDP-mсканирование (-sU) медленное, но информативное.

# Сканируем один конкретный UDP-порт 161 (SNMP) на Server_B
sudo nmap -sU -p 161 Server_B

# Сканируем диапазон популярных UDP-портов
sudo nmap -sU -p 53,123,161,500,4500 Server_B

Интерпретация результатов:

• open|filtered: Наиболее частый результат. Nmap не получил ответа, что может означать как открытый порт (приложение молчит), так и заблокированный фаерволом.
• open: Появляется редко, если приложение на целевом порте настроено отвечать на пустой запрос (как DNS).
• closed: Очень четкий признак. Получен ответ ICMP Port Unreachable, что означает — порт НЕ открыт ни одним приложением, но хост доступен и фаервол пропускает запросы.

3. Использование iperf3 для тестирования пропускной способности

Если вам нужно не только проверить "видимость", но и измерить реальную пропускную способность канала по UDP, iperf3 — идеальный инструмент.

На сервере-Lприемнике (Server_B):

iperf3 -s

На клиенте-отправителе (Server_A):

# Отправляем UDP-трафик на порт 5201 (дефолтный для iperf3) в течение 10 секунд
iperf3 -c Server_B -u -b 100M -t 10

Ключи: -u (UDP), -b (target bandwidth), 1-t (time). Успешный запуск теста с отчетами ([ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams) — прямое доказательство рабочего двустороннего UDP-пути.

Пошаговый алгоритм комплексной проверки

1. Подготовка: Убедитесь, что известны IP-адреса (или имена хостов) обоих серверов и конкретный UDP -порт, который нужно проверить (например, :3000 для кастомного приложения, :5000 для VPN, :161 для SNMP).

2. Проверка базовой сетевой связности:

   ping -c 4 Server_B
   

    Если ICMP-пакеты не ходят, UDP почти гарантированно не будет работать (если только фаервол не настроен специфически).

1. Проверка локальной конфигурации на целевом сервере:

    *   Убедитесь, что приложение запущено и слушает нужный UDP-порт:

    ```bash
    sudo ss -ulpn | grep :54321
    # или
    sudo netstat -ulnp | grep :54321
    ```

    *   Проверьте локальный фаервол (`iptables`, `nftables`, `firewalld`):

    ```bash
    sudo iptables -L -n -v | grep 54321
    ```

4. Выполнение активного теста:

    *   **Метод A (простой)**: Запустите `nc -u -l -p <PORT>` на Server_B и отправьте пакет с Server_A. Увидели текст на Server_B — путь открыт.
    *   **Метод B (профессиональный)**: Используйте `nmap`. Результат `closed` — хорошая новость (сеть работает, порт просто не занят). Результат `open|filtered` требует дальнейшего анализа с помощью работающего приложения или `tcpdump`.

1. Анализ трафика с помощью tcpdump (если предыдущие шаги неубедительны):

    На Server_B запустите перехват пакетов на интерфейсе:

```bash
sudo tcpdump -i eth0 udp port 54321 -n -v
```

    Затем с Server_A отправьте пакет через `nc`. Если в выводе `tcpdump` вы видите приход пакета — **фаервол его пропускает, и серверы "видят" друг друга на сетевом уровне**. Если пакет не появился в `tcpdump`, проблема на пути (фаервол, маршрутизация, ACL).

Заключение

Для уверенной проверки UDP-связи рекомендую комбинированный подход:

1. Проверить слушающий порт на целевом хосте (ss/netstat).
2. Использовать nmap для получения первичного статуса порта.
3. Развернуть временное тестовое приложение (например, nc в режиме сервера) и отправить тестовые данные.
4. При необходимости провести анализ трафика (tcpdump).

Помните, что окончательным доказательством работоспособности является успешный запуск и обмен данными именно того финального приложения (VoIP, DNS, игрового сервера и т.д.), для которого вы и проводите проверку.