WireGuard-vertsprefiks: kvifor éin adresse verkar og resten ikkje

Tunnelen er oppe, handtrykket skjer kvart andre minutt, og nøyaktig éi adresse på den andre sida svarar. Ping til tunneladressa til peeren verkar; ingenting bak ho gjer det. Nokon les grensesnittkonfigurasjonen, ser eit vertsprefiks og konkluderer med at maska er feil. Å utvide ho til eit /24 fiksar pinget ei stund og øydelegg deretter noko anna. Prefikset var aldri feilen, og den manglande ruta er ikkje den maska styrer.

Kva grensesnittprefikset faktisk opprettar

På Linux opprettar det å tildele ei adresse til eit grensesnitt ei tilkopla rute for det prefikset. Tildeler du eit vertsprefiks, dekkjer den tilkopla ruta éi adresse. Tildeler du eit /24, dekkjer ho 256, og kvar av dei blir no rekna som tilgjengeleg over den lenkja.

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

Eit vertsprefiks er eit heilt normalt val for ein punkt-til-punkt-tunnel, for det er nøyaktig éin peer i den andre enden. Den tredje kommandoen er den som svarar på spørsmålet til brukaren: han seier kva grensesnitt kjernen ville bruke for destinasjonen, og han viser ingenting nyttig viss ingen rute passar.

Det er heile forklaringa på symptomet. Éi adresse svarar fordi det finst ei tilkopla rute til ho, eller fordi den tillatne lista til peeren tilfeldigvis inneheld ho. Alt anna har inga rute og blir kasta før WireGuard i det heile er involvert. Tunnelen er sunn heile vegen, og difor held handtryksteljaren fram med å sjå betryggjande ut.

AllowedIPs er to reglar under eitt namn

Den tillatne lista per peer i WireGuard gjer to jobbar samstundes, og konfigurasjonssyntaksen får dei til å sjå ut som éin. Innkommande avgjer ho kva kjeldeadresser ein peer kan presentere. Utgåande vel ho kva peer ei pakke blir send til, ved å finne det mest spesifikke treffet.

Ingen av jobbane er ruting. Kjernen må framleis avgjere at ei pakke høyrer heime på tunnelgrensesnittet før WireGuard i det heile ser på ho, og den avgjerda kjem frå rutetabellen. Ei peer-oppføring med ei brei tillaten liste installerer ikkje ei rute av seg sjølv.

Difor kan ein konfigurasjon sjå komplett ut og oppføre seg asymmetrisk. Klienten sender til den andre enden fordi det finst ei rute, og svar kjem aldri fram fordi den tillatne lista til den andre enden ikkje tillèt kjelda til klienten, eller fordi den andre enden ikkje har nokon returveg. Begge retningane er separate avgjerder med separate feilmønster. Å skrive ned kva ein testar er halve diagnosen.

Kvar ruta kjem frå

Viss du brukar wg-quick, blir rutene genererte for deg frå den tillatne lista til kvar peer, med mindre du har sett Table = off og teke over styringa sjølv. Det er åtferda verktøyet dokumenterer, og det er grunnen til at ein konfigurasjon utan eksplisitte rutedirektiv likevel verkar.

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

Samanlikn den tillatne lista med rutene som faktisk finst. Ein peer som tillèt eit heilt subnett men berre laga ei vertsrute, betyr at hjelparen aldri køyrde, eller at du styrer grensesnittet direkte med wg og ip; då genererer ingenting ruter for deg.

Når du styrer det for hand, er ruta éi linje og forma er eksplisitt: destinasjonen gjennom grensesnittet, utan gateway fordi lenkja er punkt-til-punkt. Å leggje ho til er inga naudløysing for eit dårleg prefiks; det er den manglande halvdelen av eit design som medvite styrer ruting sjølv.

Eit breiare prefiks legg ikkje til peer-oppføringa

Den freistande løysinga er å endre adressa til eit /24 slik at den tilkopla ruta dekkjer LAN-et til tenaren. Det ser ut til å verke, og grunnen til at det ser ut til å verke er at den tilkopla ruta no passar, ikkje at WireGuard har lært noko nytt.

Det du òg gjorde, er å krevje heile området som direkte tilgjengeleg over den lenkja, inkludert adresser som høyrer til andre peers eller eit LAN som faktisk ligg bak tenaren. Trafikk til desse adressene går no inn i tunnelen, og om han kjem ut på den andre sida avheng av rutinga og dei tillatne listene til tenaren.

Kryptosida er upåverka uansett. WireGuard treng framleis ei oppføring i den tillatne lista som dekkjer destinasjonen for å velje ein peer, og den andre enden treng framleis ei oppføring som dekkjer kjelda di for å godta ho. Eit breiare grensesnittprefiks kan ikkje levere nokon av delane.

Stadfest begge retningane før du endrar noko

Arbeid med dei to endane kvar for seg og skriv ned kva kvar av dei seier. På klienten ruta og peer-oppføringa; på tenaren spegelbildet pluss sin eigen returveg:

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

Opptaket er det som avgjer tvist om retning. Viss utgåande pakkar dukkar opp på tunnelgrensesnittet og tenaren ikkje loggar noko, avviser den andre enden dei, vanlegvis fordi kjelda di ligg utanfor den tillatne lista hans. Viss ingenting dukkar opp i det heile, manglar ruta eller ho peikar ein annan stad.

Reparer så den smalaste enden. Ei oppføring i den tillatne lista på tenarsida for klientadressa di og ei oppføring på klientsida for destinasjonssubnettet er den normale forma, og ho lèt grensesnittprefikset vere. Utvid berre prefikset viss adresseplanen verkeleg vil ha eit delt subnett på den lenkja, og gjer det som ei planendring i staden for som eit feilsøkingstrinn.