Прэфікс хоста ў WireGuard: чаму працуе адзін адрас, а астатнія не

Тунэль падняты, handshake адбываецца кожныя дзве хвіліны, і роўна адзін адрас на іншым баку адказвае. Пінгі да тунэльнага адраса піра праходзяць; нічога за ім — не. Нехта чытае канфігурацыю інтэрфейса, бачыць прэфікс хоста і робіць выснову, што маска няправільная. Пашырэнне да /24 папраўляе пінг на нейкі час, а потым ламае нешта іншае. Прэфікс ніколі не быў прычынай, і адсутны маршрут — не той, якім кіруе маска.

Што насамрэч стварае прэфікс інтэрфейса

У Linux прызначэнне адраса інтэрфейсу ствара далучаны маршрут для гэтага прэфікса. Прызначце прэфікс хоста — далучаны маршрут пакрые адзін адрас. Прызначце /24 — ён пакрые 256, і кожны з іх цяпер лічыцца дасягальным праз гэтую сувязь.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

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

Вось і ўсё тлумачэнне сімптому. Адзін адрас адказвае таму, што для яго ёсць далучаны маршрут, або таму, што спіс дазволеных піра выпадкова яго змяшчае. Усё астатняе не мае маршруту і адкідваецца яшчэ да таго, як WireGuard увогуле ўдзельнічае. Тунэль пры гэтым увесь час здаровы, таму лічыльнік handshake і далей выглядае супакойліва.

AllowedIPs — гэта два правілы пад адной назвай

Спіс дазволеных на кожнага піра ў WireGuard робіць дзве работы адначасова, і сінтаксіс канфігурацыі прымушае іх выглядаць як адна. На ўваходзе ён дазваляе, якія адрасы крыніцы пір можа прад'явіць. На выхадзе ён выбірае, якому піру адправіць пакет, знаходзячы самае дакладнае супадзенне.

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

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

Адкуль бярэцца маршрут

Калі вы выкарыстоўваеце wg-quick, маршруты ствараюцца за вас са спіса дазволеных кожнага піра, калі вы не задалі Table = off і не ўзялі кіраванне на сябе. Гэта дакументаваныя паводзіны інструмента, і менавіта таму канфігурацыя без яўных дырэктыў маршрутызацыі ўсё роўна працуе.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Параўнайце спіс дазволеных з маршрутамі, якія рэальна ёсць. Пір, што дазваляе цэлую падсетку, але стварыў толькі маршрут хоста, азначае, што памочнік ні разу не запускаўся, або што інтэрфейсам вы кіруеце напрамкі праз wg і ip, і тады маршруты для вас ніхто не стварае.

Калі вы кіруеце ім уручную, маршрут — гэта адзін радок, і яго форма яўная: прызначэнне праз інтэрфейс, без шлюза, бо сувязь «пункт-пункт». Дадаць яго — не абыходны шлях для дрэннага прэфікса; гэта адсутная палова рашэння, якое свядома ўзяло маршрутызацыю на сябе.

Шырэйшы прэфікс не дадае запіс піра

Спакуслівае выпраўленне — змяніць адрас на /24, каб далучаны маршрут пакрыў лакальную сетку сервера. Здаецца, што гэта працуе, і прычына ў тым, што далучаны маршрут цяпер супадае, а не ў тым, што WireGuard даведаўся нешта новае.

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

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

Пацвердзіце абодва напрамкі, перш чым нешта змяняць

Разбярыце абодва канцы асобна і запішыце, што кажа кожны. На кліенце маршрут і запіс піра; на серверы люстраная карціна плюс уласны зваротны шлях:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

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

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