Як пабудаваць тэст 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. Кожнае даданне, якое ламае тэст, цяпер можна вызначыць, бо больш нічога не рухалася.

База, якая толькі робіць значычок зялёным, нічога не сказала вам пра тое, якое даданне выклікала наступны збой. Трымайце адзіны дазволены шлях працоўным як эталон, і кожная наступная змена будзе вымярацца адносна яго.