Партньор по WireGuard е недостъпен, докато друг работи: контролен списък

Един партньор по WireGuard пропуска трафик, а вторият завършва ръкостискането, но така и не достига до нищо зад тунела. Работещият партньор ви казва, че интерфейсът, UDP портът и ключът на сървъра вероятно са наред. Той не ви казва нищо за AllowedIPs на втория партньор, за вътрешния му адрес на източника или за правилата за препращане помежду им. Минавайте списъка по ред и спрете на първата стъпка, чието условие се проваля.

Стъпка 1: Запишете пътя, който пакетът трябва да измине

Два клиента на един и същ хъб не се достигат автоматично. При схема «хъб и лъчи» сървърът получава пакета на wg0 и трябва да го препрати обратно от wg0 към другия партньор, което изисква IP препращане и правило за препращане. При директна схема «партньор към партньор» всяка страна се нуждае от крайната точка на другата и от адреса на тунела ѝ в AllowedIPs. Решете коя схема отстранявате, преди да четете каквато и да е конфигурация.

Очакваният път ви казва и къде да гледате. Ако пакетът трябва да премине през хъба, неуспешното звено е или AllowedIPs на изпращача, или препращането на хъба, или AllowedIPs на получателя. Ако трябва да мине директно, хъбът е без значение и полетата за крайна точка на двамата партньори са важни.

Стъпка 2: Сравнете AllowedIPs от двете страни, а не само от една

WireGuard използва AllowedIPs едновременно като таблица за маршрутизиране и като списък за достъп. При изпращане адресът на местоназначението се търси в AllowedIPs на партньора, за да се избере тунелът; при получаване вътрешният адрес на източника трябва да попада в AllowedIPs на изпращащия партньор, иначе пакетът се отхвърля. Липсващ диапазон от която и да е страна дава същия симптом: транспортът работи, полезният товар изчезва.

Четете живото състояние, а не файла, защото презареждането може да се е провалило тихо: sudo wg show wg0 allowed-ips. На сървъра записът на неуспешния партньор трябва да включва адреса на тунела му, например 10.90.0.3/32. На клиента записът на партньора-сървър трябва да включва местоназначението, което тествате, било то адресът на тунела на хъба или отдалечената подмрежа. Припокриващите се диапазони правят търсенето двусмислено и могат да изберат партньор, който не сте имали предвид, затова ги дръжте разделени.

Стъпка 3: Проверете вътрешния адрес на източника

Клиент, който маршрутизира 10.90.0.3 през wg0, но изпраща пакети от Wi-Fi адреса си, ще бъде отхвърлен от получателя, защото източникът не съвпада с AllowedIPs на партньора. Потвърдете какво всъщност избира ядрото с ip route get 10.90.0.3 from 10.90.0.2 и потвърдете адреса, зададен на тунелния интерфейс, с ip -brief addr show wg0.

На приемащия Linux хост филтрирането по обратен път е втора бариера. Стриктно rp_filter на интерфейса, който притежава обратния маршрут, може да отхвърли тунелен трафик, чийто обратен път не съвпада с интерфейса, по който е пристигнал. Проверете ефективната стойност, преди да го изключите; в много топологии правилната поправка е маршрут, а не разхлабен филтър.

Стъпка 4: Прегледайте препращането на хъба и обратния път

Ако хъбът трябва да препраща между партньори, ядрото се нуждае от net.ipv4.ip_forward=1, а защитната стена трябва да приема препратения поток: вход на wg0, изход на wg0, от адреса на тунела на изпращача към този на получателя. Честият провал е правило за вход, което приема UDP 51820, но няма правило за препращане], така че ръкостискането успява, а полезният товар загива. Избройте действащите правила с sudo nft list ruleset или еквивалента за вашия мениджър на защитната стена.

След това проверете отговора. Хостът на местоназначението трябва да има маршрут обратно до изпращача, било през хъба, било през собствения си шлюз. Ако хъбът също прави NAT на тунелната подмрежа, потвърдете, че транслацията важи за препратения поток и че отговорът достига до хъба, преди състоянието да изтече. Еднопосочният провал, който изглежда като проблем с ключ, често е просто този обратен маршрут.

Накрая отделете ръкостискането от данните. Партньор, който завършва ръкостискане, но засича при големи трансфери, обикновено има MTU или MSS проблем на точно този път, а не проблем с AllowedIPs. Тествайте първо с малък ping, после с пълноразмерен и сравнете двата партньора.

Стъпка 5: Променете едно нещо и запазете работещия партньор непокътнат

Направете една единствена промяна по неуспешния път и тествайте отново двамата партньори. Замяната на AllowedIPs на всеки партньор с 0.0.0.0/0 е най-бързият начин да счупите партньора, който вече работеше, защото това променя решението за маршрут за целия трафик на този интерфейс. Редактирайте единия запис, презаредете и прочетете живото състояние обратно.

Запишете кой път е успял, кой се е провалил и точния изход от командата за всеки. Това сравнение струва повече от общ доклад, че VPN е счупен, и е първото, което следващият човек ще поиска.