Как да изградим тест на WireGuard с два възела, който доказва един път

Тест на WireGuard, който носи маршрут по подразбиране, LAN префикс, DNS и изключение във файлуола, не може да ви каже кое от тях се е счупило. Сведете го до два възела, една двойка адреси и една разрешена услуга и повредата няма къде да се скрие. Скучната основа е диагностиката. Изградете я първо; отнема петнадесет минути и спестява следобеда, който иначе бихте прекарали в гадаене.

Това, което основата доказва, е по-тясно, отколкото повечето хора очакват. Тя доказва, че две самоличности се разбират, че UDP достига до слушащия порт и че една разрешена дестинация носи заявка. Forwarding, 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, слушащата услуга или файлуола на хоста. Оправете това, преди да добавите forwarding, NAT или DNS, иначе ще прекарате следобеда в отстраняване на грешки във функция, която никога не е била виновна.

Запазване на основата като еталон

Запазете работещата топология и източника на профила на място, от което можете да възстановите, и ги дръжте извън всяка папка, която се синхронизира с публична услуга. После добавяйте по една функция, повтаряйки първоначалната заявка след всяка: forwarding, NAT, LAN маршрут и само след това DNS. Всяко допълнение, което чупи теста, вече е разпознаваемо, защото нищо друго не се е преместило.

Основа, която само прави икона зелена, не ви е казала нищо за това кое допълнение е причинило следващата повреда. Дръжте единствения разрешен път работещ като еталон и всяка следваща промяна се измерва спрямо него.