WireGuard не паказвае апошні рукапаціск: што праверыць перш за ўсё

Пустое поле апошняга рукапаціску звычайна значыць, што інтэрфейс не завяршыў рукапаціск з моманту ўздыму, і гэта кажа пра канфігурацыю менш, чым здаецца. WireGuard маўчыць, пакуль пакету не трэба выйсці праз інтэрфейс, таму прастойны peer без чаго адпраўляць паведамляе менавіта гэта. Устанавіце, ці было што-небудзь сапраўды прапанавана, перш чым правяраць ключы.

Тэст — гэта дазволены пакет да пункта прызначэння, які peer павінен несці. Усё астатняе на гэтым экране стану апісвае намер, а не актыўнасць.

Прастойны інтэрфейс не мае чаго паведаміць

WireGuard робіць рукапаціскі ляніва: першы пакет, якому патрэбны тунель, запускае абмен, а інтэрфейс да таго часу маўчыць. Peer, які наладзілі і ніколі не выкарыстоўвалі, паказвае пусты рукапаціск, нуль атрыманых байтаў і рост прамежку з апошняга. Такі стан здаровы для прастойнага кліента і трывожны толькі калі вы чакалі, што трафік ужо пайшоў. Праверце таксама лічыльнікі перадачы, бо яны аддзяляюць «нічога не адпраўлена» ад «паспрабавалі і не выйшла».

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

Выклічце трафік, які peer мае права несці

Выберыце адрас у межах дазволеных прэфіксаў peer на лакальнай машыне і пацвердзіце, што табліца маршрутызацыі адправіць яго праз інтэрфейс. Пункт прызначэння па-за гэтымі прэфіксамі стварае звычайны маршрутызаваны запыт без удзелу WireGuard. Выкарыстоўвайце службу, якая хутка адказвае, напрыклад ping або кароткае TCP-злучэнне, каб спроба мела бачны пачатак і канец. Затым прачытайце радок рукапаціску зноў, замест таго каб глядзець на экран і чакаць.

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

Запыт маршруту важнейшы за ping. Калі ён называе фізічны інтэрфейс, пакет ніколі не ўвайшоў у тунель, і пусты рукапаціск — гэта адказ маршрутызацыі, а не крыптаграфічны. Адрамантуйце маршрут, перш чым адладжваць peer.

Параўнайце пару ключоў і канчатковы пункт

Калі трафік сапраўды прапанаваны, наступная праверка — ідэнтычнасць. Лакальны прыватны ключ павінен адпавядаць публічнаму ключу, які дазваляе той бок, наладжаны аддалены публічны ключ павінен вызначаць патрэбны peer, а любы папярэдне агучаны ключ павінен супадаць з абодвух бакоў. Адрозненне ў адзін сімвал у ключы base64 стварае peer, які выглядае наладжаным і ніколі не завяршае абмен. Параўноўвайце з запісам забеспячэння, а не перагенерыруйце ключы, бо новы ключ робіць несапраўдным кожны peer, які давяраў старому.

Канчатковы пункт патрабуе такой жа ўвагі: імя хоста, адрас, порт UDP і сямейства, якое выкарыстоўваецца для доступу. Састарэлы адрас або няправільны порт дае цішыню, а не паведамленне.

Сачыце за знешнім шляхам UDP

Рукапаціск ідзе як UDP да канчатковага пункта, таму знешні шлях павінен яго несці. Каманды ніжэй правяраюць, ці ёсць слухач, ці лакальны стек адправіў датаграму і які канчатковы пункт наладжаны. Запусціце захоп падчас стымулявання трафіку, а не да яго.

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

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

Калі рукапаціск з’явіцца, праверце праграму праз тунель, бо завершаны абмен даказвае ідэнтычнасць і дасяжнасць, а не прыдатную прапускную здольнасць ці правільны DNS. Захавайце вывад стану да і пасля змены, і розніца стане вашым доказам.