WireGuard префикс на домаќин: зошто една адреса работи, а останатите не

Тунелот е активен, handshake-от се случува на секои две минути, и точно една адреса од другата страна одговара. Пинговите кон тунелската адреса на peer-от работат; ништо зад неа не работи. Некој ја чита конфигурацијата на интерфејсот, гледа префикс на домаќин и заклучува дека маската е погрешна. Проширувањето на /24 го поправа пингот за некое време и потоа крши нешто друго. Префиксот никогаш не бил виновен, а рутата што недостасувала не е онаа што ја контролира маската.

Што всушност создава префиксот на интерфејсот

На Linux, доделувањето адреса на интерфејс создава поврзана рута за тој префикс. Ако доделите префикс на домаќин, поврзаната рута покрива една адреса. Ако доделите /24, покрива 256, и секоја од нив сега се смета за достапна преку таа врска.

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

Префиксот на домаќин е сосема нормален избор за тунел од точка до точка, бидејќи на другиот крај има точно еден peer. Третата команда е онаа што одговара на прашањето на корисникот: кажува кој интерфејс јадрото би го користело за тоа одредиште, и нема да покаже ништо корисно ако не се совпаѓа ниту една рута.

То е целото објаснување на симптомот. Една адреса одговара затоа што постои поврзана рута за неа, или затоа што листата на дозволени на peer-от случајно ја вклучува. Сѐ друго нема рута и се отфрла пред WireGuard воопшто да биде вклучен. Тунелот е здрав цело време, затоа бројачот на handshake продолжува да изгледа смирувачки.

AllowedIPs се две правила под едно име

Листата на дозволени по peer во WireGuard врши две работи истовремено, а синтаксата на конфигурацијата ги прави да изгледаат како една. На влез дозволува кои изворни адреси peer-от смее да ги претстави. На излез избира на кој peer се праќа пакетот, пронаоѓајќи го најспецифичното совпаѓање.

Ниту една од тие работи не е routing. Јадрото уште мора да одлучи дека пакетот и припаѓа на тунелската интерфејс-страна пред WireGuard воопшто да го погледне, а таа одлука доаѓа од табелата за насочување. Запис за peer со широка листа на дозволени не инсталира сам рута.

Затоа конфигурацијата може да изгледа целосна, а да се однесува асиметрично. Клиентот праќа на другата страна затоа што постои рута, а одговорите никогаш не пристигнуваат затоа што листата на дозволени на другата страна не го дозволува изворот на клиентот, или затоа што другата страна нема повратна патека. Двете насоки се одделни одлуки со одделни начини на откажување. Да запишете која од нив ја тестирате е половина од дијагнозата.

Од каде доаѓа рутата

Ако користите wg-quick, рутите се генерираат за вас од листата на дозволени на секој peer, освен ако сте поставиле Table = off и самите сте ја презеле контролата. Тоа е однесувањето што алатката го документира, и тоа е причината зошто конфигурација без експлицитни директиви за рути сепак работи.

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

Споредете ја листата на дозволени со рутите што навистина постојат. Peer што дозволува цела подмрежа, но создал само рута на домаќин, значи дека помошникот никогаш не се извршил, или дека интерфејсот го управувате директно со wg и ip, и во тој случај ништо не ви генерира рути.

Кога го управувате рачно, рутата е еден ред и нејзината форма е експлицитна: одредиштето низ интерфејсот, без портал бидејќи врската е од точка до точка. Додавањето не е заобиколно решение за лош префикс; тоа е половината што недостасува од дизајн што свесно го презел насочувањето.

Поширок префикс не го додава записот за peer

Примамливата поправка е адресата да се смени на /24 за поврзаната рута да го покрие LAN-от на серверот. Изгледа дека работи, а причината зошто изгледа дека работи е тоа што поврзаната рута сега се совпаѓа, не тоа што WireGuard научил нешто ново.

Она што исто така го направивте е да го присвоите целиот опсег како директно достапен преку таа врска, вклучувајќи адреси што им припаѓаат на други peer-ови или на LAN што всушност е зад серверот. Сообраќајот кон тие адреси сега влегува во тунелот, а дали ќе излезе на другата страна зависи од насочувањето и листите на дозволени на самиот сервер.

Криптографската страна не е засегната во ниту еден случај. WireGuard уште бара запис во листата на дозволени што го покрива одредиштето за да избере peer, а другата страна уште бара запис што го покрива вашиот извор за да го прифати. Поширок префикс на интерфејс не може да обезбеди ниту едно од двете.

Потврдете ги двете насоки пред да промените нешто

Работете ги двата краја одделно и запишете што вели секој. На клиентот рутата и записот за peer; на серверот огледалната слика плус неговата сопствена повратна патека:

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

Снимката е она што ги решава споровите за насока. Ако излезните пакети се појават на тунелскиот интерфејс, а серверот не запишува ништо, далечниот крај ги одбива, обично затоа што вашиот извор е надвор од неговата листа на дозволени. Ако воопшто не се појави ништо, рутата недостасува или покажува на друго место.

Потоа поправете го потесниот крај. Запис во листата на дозволени на страната на серверот за адресата на вашиот клиент и запис на страната на клиентот за одредишната подмрежа е нормалната форма, и го остава префиксот на интерфејсот на мир. Проширете го префиксот само ако планот за адреси навистина сака заедничка подмрежа на таа врска, и направете го тоа како промена на план, а не како чекор за отстранување грешки.