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-ом, затим ping-ом пуне величине, и упоредите два партнера.

Корак 5: Промените једну ствар и сачувајте радног партнера нетакнутим

Направите једну једину промену на неуспелој путањи и поново тестирајте оба партнера. Замена AllowedIPs сваког партнера са 0.0.0.0/0 најбржи је начин да сломите партнера који је већ радио, јер мења одлуку о рутирању за сав саобраћај на том интерфејсу. Уредите тај један запис, поново учитајте и прочитајте живо стање.

Запишите која путања је успела, која није и тачан излаз команде за сваку. То поређење вреди више од општег извештаја да је VPN покварен, и то је прво што ће следећа особа затражити.