WireGuard-vertsprefiks: hvorfor én adresse virker og resten ikke

Tunnelen er oppe, håndtrykket skjer hvert annet minutt, og nøyaktig én adresse på den andre siden svarer. Ping til peerens tunneladresse virker; ingenting bak den gjør det. Noen leser grensesnittkonfigurasjonen, ser et vertsprefiks og konkluderer med at masken er feil. Å utvide den til et /24 fikser pinget en stund og ødelegger deretter noe annet. Prefikset var aldri feilen, og den manglende ruten er ikke den masken styrer.

Hva grensesnittprefikset faktisk oppretter

På Linux oppretter det å tildele en adresse til et grensesnitt en tilkoblet rute for det prefikset. Tildeler du et vertsprefiks, dekker den tilkoblede ruten én adresse. Tildeler du et /24, dekker den 256, og hver av dem regnes nå som tilgjengelig over den lenken.

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

Et vertsprefiks er et helt normalt valg for en punkt-til-punkt-tunnel, for det er nøyaktig én peer i den andre enden. Den tredje kommandoen er den som svarer på brukerens spørsmål: den sier hvilket grensesnitt kjernen ville bruke for destinasjonen, og den viser ingenting nyttig hvis ingen rute passer.

Det er hele forklaringen på symptomet. Én adresse svarer fordi det finnes en tilkoblet rute til den, eller fordi peerens tillatte liste tilfeldigvis inneholder den. Alt annet har ingen rute og forkastes før WireGuard i det hele tatt er involvert. Tunnelen er sunn hele veien, og derfor fortsetter håndtrykkstelleren å se betryggende ut.

AllowedIPs er to regler under ett navn

WireGuards tillatte liste per peer gjør to jobber samtidig, og konfigurasjonssyntaksen får dem til å se ut som én. Innkommende avgjør den hvilke kildeadresser en peer kan presentere. Utgående velger den hvilken peer en pakke sendes til, ved å finne den mest spesifikke treffet.

Ingen av jobbene er ruting. Kjernen må fortsatt avgjøre at en pakke hører hjemme på tunnelgrensesnittet før WireGuard i det hele tatt ser på den, og den avgjørelsen kommer fra rutetabellen. En peer-oppføring med en bred tillatt liste installerer ikke en rute av seg selv.

Derfor kan en konfigurasjon se komplett ut og oppføre seg asymmetrisk. Klienten sender til den andre enden fordi det finnes en rute, og svar kommer aldri fram fordi den andre endens tillatte liste ikke tillater klientens kilde, eller fordi den andre enden ikke har noen returvei. Begge retningene er separate beslutninger med separate feilmønstre. Å skrive ned hvilken man tester er halve diagnosen.

Hvor ruten kommer fra

Hvis du bruker wg-quick, genereres rutene for deg fra hver peers tillatte liste, med mindre du har satt Table = off og overtatt styringen selv. Det er oppførselen verktøyet dokumenterer, og det er grunnen til at en konfigurasjon uten eksplisitte rutedirektiver likevel virker.

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

Sammenlign den tillatte listen med rutene som faktisk finnes. En peer som tillater et helt subnett men bare laget en vertsrute, betyr at hjelperen aldri kjørte, eller at du styrer grensesnittet direkte med wg og ip; da genererer ingenting ruter for deg.

Når du styrer det for hånd, er ruten én linje og formen er eksplisitt: destinasjonen gjennom grensesnittet, uten gateway fordi lenken er punkt-til-punkt. Å legge den til er ingen nødløsning for et dårlig prefiks; det er den manglende halvdelen av et design som bevisst styrer ruting selv.

Et bredere prefiks legger ikke til peer-oppføringen

Den fristende løsningen er å endre adressen til et /24 slik at den tilkoblede ruten dekker serverens LAN. Det ser ut til å virke, og grunnen til at det ser ut til å virke er at den tilkoblede ruten nå passer, ikke at WireGuard har lært noe nytt.

Det du også gjorde, er å kreve hele området som direkte tilgjengelig over den lenken, inkludert adresser som tilhører andre peers eller et LAN som faktisk ligger bak serveren. Trafikk til disse adressene går nå inn i tunnelen, og om den kommer ut på den andre siden avhenger av serverens egen ruting og tillatte lister.

Kryptosiden er upåvirket uansett. WireGuard trenger fortsatt en oppføring i den tillatte listen som dekker destinasjonen for å velge en peer, og den andre enden trenger fortsatt en oppføring som dekker din kilde for å godta den. Et bredere grensesnittprefiks kan ikke levere noen av delene.

Bekreft begge retninger før du endrer noe

Arbeid med de to endene hver for seg og skriv ned hva hver av dem sier. På klienten ruten og peer-oppføringen; på serveren speilbildet pluss dens egen returvei:

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 avgjør tvist om retning. Hvis utgående pakker dukker opp på tunnelgrensesnittet og serveren ikke logger noe, avviser den andre enden dem, vanligvis fordi kilden din ligger utenfor dens tillatte liste. Hvis ingenting dukker opp i det hele tatt, mangler ruten eller den peker et annet sted.

Reparer så den smaleste enden. En oppføring i den tillatte listen på serversiden for klientadressen din og en oppføring på klientsiden for destinasjonssubnettet er den normale formen, og den lar grensesnittprefikset være. Utvid bare prefikset hvis adresseplanen virkelig vil ha et delt subnett på den lenken, og gjør det som en planendring i stedet for som et feilsøkingstrinn.