WireGuard ostalariaren aurrizkia: zergatik funtzionatzen du helbide batek eta gainerakoek ez

Tunela aktibo dago, handshake bi minuturo gertatzen da, eta beste aldean helbide bakarra erantzuten du zehazki. Peer-aren tunel-helbiderako ping-ek funtzionatzen dute; haren atzean ezerk ez. Norbaitek interfazearen konfigurazioa irakurtzen du, ostalari-aurrizki bat ikusten du eta maskara oker dagoela ondorioztatzen du. /24ra zabaltzeak ping-a konponduko du denbora batez eta gero beste zerbait apurtzen du. Aurrizkia ez zen inoiz errua, eta falta zen bidea ez da maskarak kontrolatzen duen bidea.

Zer sortzen du benetan interfazearen aurrizkiak

Linuxen, interfaze bati helbide bat esleitzeak aurrizki horretarako konektatutako bide bat sortzen du. Ostalari-aurrizki bat esleitzen baduzu, konektatutako bideak helbide bat hartzen du. /24 bat esleitzen baduzu, 256 hartzen ditu, eta horietako bakoitza esteka horretatik irisgarritzat jotzen da orain.

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

Ostalari-aurrizkia aukera guztiz normala da puntutik punturako tunel baterako, beste muturrean peer bat zehazki baitago. Hirugarren komandoa erabiltzailearen galderari erantzuten diona da: kernelak zer interfaze erabiliko lukeen esaten du helmuga horretarako, eta ez du ezer erabilgarririk erakutsiko bideren bat bat ez badator.

Hori da sintomaren azalpen osoa. Helbide batek erantzuten du harekin konektatutako bide bat dagoelako, edo peer-aren baimendutako zerrendak kasualitatez barne hartzen duelako. Gainerako guztiak ez du biderik eta WireGuard inplikatu aurretik botatzen da. Tunela osasuntsu dago denbora osoan, horregatik handshake kontagailuak lasaigarri dirudien.

AllowedIPs izen beraren pean dauden bi arau dira

WireGuard-en peer bakoitzeko baimendutako zerrendak bi lan egiten ditu aldi berean, eta konfigurazio-sintaxiak bat balira bezala erakusten ditu. Sarreran, peer batek aurkez ditzakeen iturri-helbideak baimetzen ditu. Irteeran, pakete bat zein peer-era bidaltzen den hautatzen du, bat-etortze zehatzena aurkituta.

Bi lan horietako bat ere ez da bideratzea. Kernelak oraindik erabaki behar du pakete bat tunel-interfazeari dagokiola WireGuardek hura ikusi aurretik, eta erabaki hori bideratze-taulatik dator. Baimendutako zerrenda zabala duen peer-sarrera batek ez du biderik instalatzen bere kasa.

Horregatik konfigurazio bat osoa izan daiteke eta asimetrikoki jokatu. Bezeroak beste aldera bidaltzen du bidea dagoelako, eta erantzunak ez dira inoiz iristen beste aldearen baimendutako zerrendak bezeroaren iturria baimetzen ez duelako, edo beste aldeak itzulera-biderik ez duelako. Bi norabideak erabaki bereiziak dira, hutsegite-modu bereiziekin. Zein probatzen ari zaren idaztea diagnosiaren erdia da.

Nondik dator bidea

wg-quick erabiltzen baduzu, bideak zuretzat sortzen dira peer bakoitzaren baimendutako zerrendatik, Table = off ezarri eta kontrola zeuk hartu ez baduzu. Hori da tresnak dokumentatzen duen portaera, eta hori da bide-instrukzio espliziturik gabeko konfigurazio batek hala ere funtzionatzen duen arrazoia.

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

Alderatu baimendutako zerrenda benetan dauden bideekin. Subnet oso bat baimendu baina ostalari-bide bat bakarrik sortu zuen peer batek esan nahi du laguntzailea ez zela inoiz exekutatu, edo interfazea zuzenean wg eta ip erabiliz kudeatzen duzula, eta kasu horretan ezerk ez du biderik sortzen zuretzat.

Eskuz kudeatzen duzunean, bidea lerro bakarra da eta haren forma esplizitua: helmuga interfazearen bidez, atebiderik gabe esteka puntutik punturakoa delako. Hura gehitzea ez da aurrizki txar baterako irtenbide bat; bideratzea bere gain hartzea erabaki zuen diseinuaren falta den erdia da.

Aurrizki zabalagoak ez du peer-sarrera gehitzen

Konponbide tentagarria helbidea /24ra aldatzea da, konektatutako bideak zerbitzariaren LANa har dezan. Badirudi funtzionatzen duela, eta funtzionatzen duela dirudien arrazoia konektatutako bidea orain bat datorrela da, ez WireGuardek zerbait berria ikasi duela.

Egin zenuena ere bai: sorta osoa esteka horretatik zuzenean irisgarri gisa aldarrikatzea, beste peer batzuei edo zerbitzariaren atzean benetan dagoen LAN bati dagozkien helbideak barne. Helbide horietarako trafikoa tunelera sartzen da orain, eta beste aldetik irteten den zerbitzariaren beraren bideratzearen eta baimendutako zerrenden araberakoa da.

Kriptografia-aldea ez da inola ere kaltetua. WireGuardek oraindik baimendutako zerrendan helmuga hartzen duen sarrera bat behar du peer bat aukeratzeko, eta beste aldeak zure iturria hartzen duen sarrera bat behar du hura onartzeko. Interfaze-aurrizki zabalago batek ezin du bietako bat ere eman.

Berretsi bi norabideak ezer aldatu aurretik

Landu bi muturrak bereizita eta idatzi bakoitzak zer dioen. Bezeroan bidea eta peer-sarrera; zerbitzarian ispilu-irudia gehi bere itzulera-bidea:

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

Harrapaketak argitzen ditu norabideari buruzko eztabaidak. Irteerako paketeak tunel-interfazean agertzen badira eta zerbitzariak ezer erregistratzen ez badu, urruneko muturrak baztertzen ditu, normalean zure iturria haren baimendutako zerrendatik kanpo dagoelako. Ezer agertzen ez bada, bidea falta da edo beste norabait seinalatzen du.

Ondoren konpondu mutur estuena. Zerbitzariaren aldean zure bezeroaren helbiderako baimendutako zerrendako sarrera bat eta bezeroaren aldean helmugako subnetarentzako sarrera bat forma normala da, eta interfaze-aurrizkia bakean uzten du. Aurrizkia zabaldu bakarrik helbide-plarak esteka horretan subnet partekatua benetan nahi badu, eta egin plan-aldaketa gisa, arazketa-urrats gisa beharrean.