Кампаньён 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. Спачатку праверце невялікім пінгам, потым поўнапамерным, і параўнайце двух кампаньёнаў.

Крок 5: Змяніце адну рэч і захавайце працоўнага кампаньёна цэлым

Зрабіце адзіную змену на збойным шляху і паўторна праверце абодвух кампаньёнаў. Замена AllowedIPs кожнага кампаньёна на 0.0.0.0/0 — самы хуткі спосаб зламаць кампаньёна, які ўжо працаваў, бо гэта змяняе рашэнне аб маршруце для ўсяго трафіку на гэтым інтэрфейсе. Адрэдагуйце адзін запіс, перазагрузіце і прачытайце жывы стан назад.

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