WireGuard Endpoint и порт 51820: как не перепутать с блокировкой

При настройке WireGuard пользователи часто сталкиваются с ситуацией, когда соединение не устанавливается. Первая мысль — «провайдер блокирует». Однако в большинстве случаев проблема кроется в неправильном указании endpoint или порта. В этой статье разберём, что такое endpoint, какую роль играет порт 51820, и как по шагам отличить ошибку конфигурации от реального блокирования протокола.

Что такое endpoint в WireGuard

Endpoint — это адрес удалённого сервера (пира), к которому клиент подключается. Он состоит из IP-адреса (или доменного имени) и порта, например 203.0.113.5:51820 или vpn.example.com:51820. Именно endpoint указывает WireGuard, куда отправлять зашифрованные пакеты и откуда ожидать ответ.

В конфигурации клиента endpoint задаётся в секции [Peer]:

[Peer]
PublicKey = ...
AllowedIPs = 0.0.0.0/0
Endpoint = 203.0.113.5:51820

На сервере endpoint обычно не указывают — он используется на клиенте для инициации соединения. Если вы настраиваете подключение вручную, важно точно понимать: endpoint — это «точка входа», а не локальный адрес вашего устройства. Ошибка здесь — одна из самых частых причин «не работает WireGuard».

Порт 51820: зачем он нужен и можно ли его изменить

Порт 51820 — это значение по умолчанию для WireGuard. Протокол работает поверх UDP, поэтому порт должен совпадать с ListenPort, указанным в конфигурации сервера. Если на сервере задан другой порт, например 51821, то в endpoint клиента нужно указать именно его.

Порт можно изменить на любой свободный UDP-порт в диапазоне 1–65535. Это иногда делают для маскировки трафика или обхода некоторых ограничений, но не забывайте: изменение порта не делает протокол «невидимым». Определители трафика всё равно могут обнаружить характерные паттерны WireGuard.

Важно: WireGuard использует UDP, а не TCP. Если вы пытаетесь проверить подключение через telnet или «ping» на TCP-порт, ничего не выйдет. Для проверки нужно использовать UDP-тесты (например, nc -u или nmap -sU).

Почему неправильный endpoint выглядит как блокировка

Симптомы неработающего WireGuard одинаковы и при ошибке конфигурации, и при реальной блокировке. Клиент «висит» на Connecting…, в логах появляются таймауты, handshake не завершается. Пользователь делает вывод о вмешательстве провайдера, хотя на самом деле достаточно поправить один символ в endpoint.

Типичные ошибки настройки:

• Неверный IP-адрес — например, указан локальный адрес сервера (192.168.x.x) вместо публичного, или допущена опечатка.
• Неправильный порт — используется 51820, а сервер слушает 5555, или наоборот.
• Доменное имя не резолвится — если в endpoint указан домен, но DNS не работает, соединение не установится.
• Проблемы с UDP — фаервол на сервере или клиенте блокирует входящие/исходящие UDP-пакеты. При этом TCP-соединения могут работать, поэтому кажется, что «заблокирован именно WireGuard».

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

Как проверить: endpoint или блокировка

Выполняйте проверки по порядку — от самого вероятного к редкому. Не перескакивайте, иначе потратите время впустую.

1. Проверьте конфигурацию на клиенте. Откройте файл конфигурации и убедитесь, что endpoint содержит корректный публичный IP или домен, а порт соответствует ListenPort сервера. Выполните wg show — если в строке endpoint пусто, соединение ещё не устанавливалось. Если указан неправильный адрес, команда покажет его.
2. Проверьте доступность сервера по IP и порту. С сервера, на котором работает WireGuard, выполните wg show и запомните порт. С клиента отправьте UDP-пакет: nc -u -vz IP порт или nmap -sU -p порт IP. Если порт закрыт или фильтруется, увидите ошибку. Учтите, что многие интернет-провайдеры не блокируют весь UDP, но могут «сбрасывать» трафик на нестандартных портах.
3. Проверьте, не блокирует ли файрвол на сервере. Убедитесь, что UDP-порт открыт для входящих подключений. На Linux это обычно ufw allow 51820/udp или правило iptables. Если фаервол настроен неправильно, снаружи это выглядит как «мёртвый» порт.
4. Протестируйте с другой сети. Подключитесь к мобильному интернету или другой точке доступа и попробуйте снова. Если соединение устанавливается — вероятно, ваш основной провайдер действительно мешает передаче, но это уже отдельная тема. Если не устанавливается и там — дело в конфигурации.
5. Сравните с известным рабочим сервером. Если у вас есть доступ к другому WireGuard-серверу (или вы можете временно поднять его на VPS), настройте клиент на него. Если работает — проблема в вашем основном сервере или его настройках.

Помните: WireGuard не использует TCP, поэтому обычный ping (ICMP) не покажет ничего о доступности порта. Для проверки используйте именно UDP-инструменты.

Пошаговая инструкция для исключения ошибок

Чтобы не гадать, следуйте простому алгоритму.

1. На сервере выполните wg show и запишите фактический listening port.
2. Выполните curl ifconfig.me на сервере, чтобы узнать его публичный IP (если за NAT — убедитесь, что проброс портов настроен).
3. В конфигурации клиента укажите Endpoint = публичный_IP:порт_с_шага_1.
4. Проверьте, что DNS-имя (если используете домен) резолвится: dig +short домен.
5. Проверьте фаервол на сервере: разрешите входящий UDP на нужный порт.
6. Запустите WireGuard на клиенте и в течение 5 секунд выполните wg show на клиенте — если в поле endpoint появился адрес сервера и transfer растёт, handshake прошёл.
7. Если handshake не проходит — проверьте сетевое соединение: traceroute -U -p порт IP (на Linux) или nmap -sU -p порт IP.

Эти шаги помогают локализовать проблему за 10–15 минут. Только если все они выполнены и UDP-пакеты не доходят до сервера, можно говорить о возможной блокировке со стороны провайдера. В таком случае попробуйте сменить порт (например, на 443 или 53) и повторить проверку — иногда это обходит наивные фильтры. Но не забывайте, что менять порт нужно и на сервере (ListenPort), и в конфигурации клиента.