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-от е расипан, и тоа е првото нешто што ќе го праша следниот човек.