Как построить тест WireGuard с двумя пирами, доказывающий один путь

Тест WireGuard, несущий маршрут по умолчанию, префикс LAN, DNS и исключение в межсетевом экране, не может сказать, что из этого сломалось. Сведите его к двум пирам, одной паре адресов и одной разрешённой службе, и сбою негде будет спрятаться. Скучная база и есть диагностика. Постройте её первой; это занимает пятнадцать минут и экономит вторую половину дня, которую иначе вы провели бы в догадках.

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

Ключи, адреса и единственный endpoint

Создайте пару ключей в каждой системе и переносите между ними только открытые половины. wg genkey | tee privatekey | wg pubkey > publickey — это документированная однострочная команда, и она оставляет закрытый ключ в файле, который затем можно защитить. Выберите адреса туннеля из диапазона, который не встречается ни в какой другой вашей конфигурации, например 10.99.0.1/24 и 10.99.0.2/24. Запишите, какой адрес принадлежит какой машине, потому что каждая последующая проверка зависит от этого соответствия.

Закрытые ключи никогда не путешествуют. Если тесту нужно скопировать один на другую сторону, тест уже пошёл не так. Когда две системы находятся за NAT, хотя бы одной нужен доступный порт UDP, а другая несёт Endpoint, указывающий на него, и публичный адрес с портом должны быть в ваших заметках, а не в предположениях о 51820.

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

Поля, которые принадлежат wg, и те, которые нет

Основной набор полей мал: PrivateKey и ListenPort в Interface, PublicKey, AllowedIPs и Endpoint в Peer. Address и DNS принадлежат wg-quick, а не самому wg, и это различие кусает в тот момент, когда та же конфигурация переходит в другой инструмент.

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs выполняет две задачи одновременно. Он выбирает, какие назначения идут в туннель, и разрешает пиру использовать эти адреса источника при прибытии. Поэтому зеркальная запись на другой стороне должна точно назвать адрес вашего туннеля; /32 не для того пира читается как проблема маршрутизации и ведёт себя как проблема авторизации. Быстрый старт WireGuard показывает ту же форму с двумя пирами с канонической формулировкой, если вы хотите сравнить имена полей.

Читать рукопожатие, а не значок

Поднимите интерфейс через то, что им владеет, затем читайте состояние, а не лампочку. wg show печатает последнее рукопожатие по каждому пиру вместе со счётчиками байтов, а рукопожатие за последние несколько минут означает, что ключи, endpoint и путь UDP работают. Счётчик, который растёт только в одну сторону, сам себе ответ, и это не тот же сбой, что рукопожатие, которое не происходит никогда.

Два сбоя подразумевают разные расследования. Полное отсутствие рукопожатия указывает на несовпадение ключей, неверный Endpoint, заблокированный UDP или межсетевой экран, который отбрасывает само рукопожатие. Рукопожатие, которое проходит, но данные никуда не идут, указывает на AllowedIPs, службу, не слушающую адрес туннеля, или межсетевой экран хоста, который принимает порт для LAN, но не для интерфейса туннеля. Это разные половины системы, и база разделяет их, прежде чем вы начнёте менять правила.

Доказать одну разрешённую службу, затем обратное

Отправьте запрос на адрес туннеля другого пира к службе, которая должна отвечать, и выберите что-то лучшее, чем ping. Отсутствующий ответ ICMP может быть фильтрацией хоста, а не сбоем туннеля, поэтому тихий ping не доказывает ни одного направления. TCP-соединение с портом, который, как вы знаете, открыт, или запрос, возвращающий данные, даёт ответ, который можно истолковать.

Запустите обратное направление как отдельный тест с собственным результатом, потому что у двух направлений отдельные записи межсетевого экрана и AllowedIPs, и они могут отказывать независимо. Если рукопожатие работает, а запрос нет, проблема в пути данных, а не в туннеле: AllowedIPs, слушающая служба или межсетевой экран хоста. Исправьте это, прежде чем добавлять переадресацию, NAT или DNS, иначе проведёте вторую половину дня, отлаживая функцию, которая никогда не была виновата.

Сохранение базы как эталона

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

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