WireGuard-prefiks: waarom een adres werk en die res nie

Die tonnel is op, die handdruk gebeur elke twee minute, en presies een adres aan die ander kant antwoord. Pings na die port se tonneladres werk; niks agter dit nie. Iemand lees die koppelvlakkonfigurasie, sien 'n gasheerprefiks en maak die gevolgtrekking dat die masker verkeerd is. Om dit na 'n /24 te verbreed maak die ping 'n rukkie reg en breek dan iets anders. Die prefiks was nooit die skuld nie, en die roete wat ontbreek het, is nie die een wat die masker beheer nie.

Wat die koppelvlakprefiks werklik skep

Op Linux skep die toeken van 'n adres aan 'n koppelvlak 'n verbonde roete vir daardie prefiks. Ken jy 'n gasheerprefiks toe, dan dek die verbonde roete een adres. Ken jy 'n /24 toe, dan dek dit 256, en elkeen daarvan word nou as bereikbaar oor daardie skakel beskou.

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

'n Gasheerprefiks is 'n heeltemal normale keuse vir 'n punt-tot-punt-tonnel, want daar is presies een port aan die ander kant. Die derde opdrag is die een wat die gebruiker se vraag beantwoord: dit se watter koppelvlak die kern vir daardie bestemming sou gebruik, en dit wys niks nuttigs as geen roete pas nie.

Dit is die hele verklaring vir die simptoom. Een adres antwoord omdat daar 'n verbonde roete daarvoor bestaan, of omdat die port se toegelate lys dit toevallig insluit. Vir alles anders is daar geen roete nie en dit word weggegooi voordat WireGuard betrokke raak. Die tonnel is heeltyd gesond, en daarom bly die handdrukteller gerusstellend lyk.

AllowedIPs is twee reels onder een naam

WireGuard se toegelate lys per port doen twee take gelyk, en die konfigurasiesintaksis laat hulle soos een lyk. Inkomend magtig dit watter bronadresse 'n port mag aanbied. Uitgaand kies dit na watter port 'n pakket gestuur word, deur die mees spesifieke passing te vind.

Nie een van die twee take is roetebepaling nie. Die kern moet steeds besluit dat 'n pakket op die tonnelkoppelvlak hoort voordat WireGuard daarna kyk, en daardie besluit kom uit die roetebepalingstabel. 'n Port-inskrywing met 'n bree toegelate lys installeer nie vanself 'n roete nie.

Daarom kan 'n konfigurasie volledig lyk en asimmetries optree. Die klieent stuur na die oorkant omdat daar 'n roete bestaan, en antwoorde kom nooit aan nie omdat die oorkant se toegelate lys nie die klieent se bron magtig nie, of omdat die oorkant geen terugpad het nie. Beide rigtings is afsonderlike besluite met afsonderlike foutwyses. Om neer te skryf watter een jy toets, is die helfte van die diagnose.

Waar die roete vandaan kom

As jy wg-quick gebruik, word die roetes vir jou uit elke port se toegelate lys gegenereer, tensy jy Table = off gestel het en die beheer self oorgeneem het. Dit is die gedrag wat die gereedskap dokumenteer, en dit is die rede waarom 'n konfigurasie sonder uitdruklike roeteopdragte steeds werk.

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

Vergelyk die toegelate lys met die roetes wat werklik daar is. 'n Port wat 'n hele subnet toelaat maar net 'n gasheerroete opgelewer het, beteken dat die helper nooit geloop het nie, of dat jy die koppelvlak regstreeks met wg en ip bestuur; dan genereer niks roetes vir jou nie.

Wanneer jy dit met die hand bestuur, is die roete een reel en sy vorm uitdruklik: die bestemming deur die koppelvlak, sonder 'n poort want die skakel is punt-tot-punt. Om dit by te voeg is nie 'n tydelike oplossing vir 'n slegte prefiks nie; dit is die ontbrekende helfte van 'n ontwerp wat roetebepaling doelbewus self bestuur.

'n Wyere prefiks voeg nie die port-inskrywing by nie

Die verleidelike oplossing is om die adres na 'n /24 te verander sodat die verbonde roete die bediener se LAN dek. Dit lyk of dit werk, en die rede waarom dit lyk of dit werk, is dat die verbonde roete nou pas, nie dat WireGuard iets nuuts geleer het nie.

Wat jy ook gedoen het, is om die hele reeks as direk bereikbaar oor daardie skakel op te eis, insluitend adresse wat aan ander ports of aan 'n LAN agter die bediener behoort. Verkeer na daardie adresse kom nou die tonnel binne, en of dit aan die ander kant uitkom, hang af van die bediener se eie roetebepaling en toegelate lyste.

Die kriptokant bly in beide gevalle onaangeraak. WireGuard het steeds 'n inskrywing in die toegelate lys nodig wat die bestemming dek om 'n port te kies, en die oorkant het steeds 'n inskrywing nodig wat jou bron dek om dit te aanvaar. 'n Wyere koppelvlakprefiks kan nie een van die twee lewer nie.

Bevestig beide rigtings voordat jy iets verander

Werk die twee punte afsonderlik af en skryf neer wat elkeen se. Op die klieent die roete en die port-inskrywing; op die bediener die spieelbeeld plus sy eie terugpad:

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

Die vaslegging is wat geskille oor rigting besleg. As uitgaande pakkette op die tonnelkoppelvlak verskyn en die bediener log niks, verwerp die oorkant hulle, gewoonlik omdat jou bron buite sy toegelate lys val. As daar glad niks verskyn nie, ontbreek die roete of wys dit elders heen.

Maak dan die smalste punt reg. 'n Inskrywing in die toegelate lys aan bedienerkant vir jou klieentadres en 'n inskrywing aan klieentkant vir die bestemmingsubnet is die normale vorm, en dit laat die koppelvlakprefiks ongemoeid. Verbreed die prefiks net as die adresplan werklik 'n gedeelde subnet op daardie skakel wil he, en doen dit as 'n planverandering eerder as 'n ontfoutstap.