Prefiksi i hostit në WireGuard: pse funksionon një adresë dhe të tjerat jo

Gryka është aktive, handshake ndodh çdo dy minuta dhe saktësisht një adresë në anën tjetër përgjigjet. Ping-et drejt adresës së grykës së peer-it funksionojnë; asgjë prapa saj nuk funksionon. Dikush lexon konfigurimin e interface-it, sheh një prefiks hosti dhe përfundon se maska është gabim. Zgjerimi i saj në /24 rregullon ping-un për një kohë dhe më pas prish diçka tjetër. Prefiksi nuk ishte kurrë faji, dhe rruga që mungonte nuk është ajo që kontrollon maska.

Çfarë krijon në të vërtetë prefiksi i interface-it

Në Linux, caktimi i një adrese një interface-i krijon një rrugë të lidhur për atë prefiks. Nëse cakton një prefiks hosti, rruga e lidhur mbulon një adresë. Nëse cakton /24, mbulon 256, dhe secila prej tyre tani konsiderohet e arritshme përmes atij lidhjeje.

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

Një prefiks hosti është zgjedhje krejt e normale për një grykë pikë-për-pikë, sepse ka saktësisht një peer në skajin tjetër. Komanda e tretë është ajo që i përgjigjet pyetjes së përdoruesit: thotë cilin interface do të përdorte kerneli për atë destinacion, dhe nuk do të tregojë asgjë të dobishme nëse asnjë rrugë nuk përputhet.

Kjo është e gjithë shpjegimi i simptomës. Një adresë përgjigjet sepse ekziston një rrugë e lidhur për të, ose sepse lista e lejuar e peer-it rastësisht e përfshin. Për gjithçka tjetër nuk ka rrugë dhe hidhet para se WireGuard të jetë i përfshirë. Gryka është e shëndetshme gjatë gjithë kohës, dhe për këtë arsye numëruesi i handshake vazhdon të duket qetësues.

AllowedIPs janë dy rregulla nën një emër

Lista e lejuar për peer e WireGuard bën dy punë njëkohësisht, dhe sintaksa e konfigurimit i bën të duken si një. Në hyrje, ajo autorizon cilat adresa burimore mund të paraqesë një peer. Në dalje, zgjedh se cilit peer i dërgohet një paketë, duke gjetur përputhjen më specifike.

Asnjëra nga të dyja punët nuk është routing. Kerneli ende duhet të vendosë se një paketë i përket interface-it të grykës përpara se WireGuard ta shohë, dhe ai vendim vjen nga tabela e routing-ut. Një zë peer me listë të lejuar të gjerë nuk instalon vetë një rrugë.

Për këtë arsye një konfigurim mund të duket i plotë dhe të sillet në mënyrë asimetrike. Klienti dërgon drejt skajit tjetër sepse ekziston një rrugë, dhe përgjigjet nuk arrijnë kurrë sepse lista e lejuar e skajit tjetër nuk e autorizon burimin e klientit, ose sepse skaji tjetër nuk ka rrugë kthimi. Të dyja drejtimet janë vendime të ndara me mënyra dështimi të ndara. Të shkruash cilin po teston është gjysma e diagnozës.

Nga vjen rruga

Nëse përdor wg-quick, rrugët gjenerohen për ty nga lista e lejuar e çdo peer, përveç nëse ke vendosur Table = off dhe e ke marrë kontrollin vetë. Ky është sjellja e dokumentuar e mjetit, dhe është arsyeja pse një konfigurim pa direktiva eksplicite rrugësh funksionon gjithsesi.

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

Krahaso listën e lejuar me rrugët që ekzistojnë në të vërtetë. Një peer që lejon një subnet të tërë por prodhoi vetëm një rrugë hosti do të thotë që ndihmësi nuk u ekzekutua kurrë, ose që ti e menaxhon interface-in drejtpërdrejt me wg dhe ip, dhe në atë rast asgjë nuk gjeneron rrugë për ty.

Kur e menaxhon me dorë, rruga është një rresht dhe forma e saj është eksplicite: destinacioni përmes interface-it, pa gateway sepse lidhja është pikë-për-pikë. Shtimi i saj nuk është zgjidhje e përkohshme për një prefiks të keq; është gjysma që mungon e një dizajni që zgjodhi të kujdeset vetë për routing-un.

Zgjerimi i prefiksit nuk shton zërin e peer-it

Rregullimi joshës është ndryshimi i adresës në /24 që rruga e lidhur të mbulojë LAN-in e serverit. Duket se funksionon, dhe arsyeja pse duket se funksionon është se rruga e lidhur tani përputhet, jo se WireGuard mësoi diçka të re.

Çfarë ke bërë gjithashtu është të kërkosh të gjithë gamën si të arritshme drejtpërdrejt përmes atij lidhjeje, duke përfshirë adresa që i përkasin peer-ëve të tjerë ose një LAN-i që në fakt ndodhet pas serverit. Trafiku drejt atyre adresave tani hyn në grykë, dhe nëse del në anën tjetër varet nga routing-u dhe listat e lejuara të vetë serverit.

Ana kriptografike nuk preket në asnjë rast. WireGuard ende ka nevojë për një zë në listën e lejuar që mbulon destinacionin për të zgjedhur një peer, dhe skaji tjetër ende ka nevojë për një zë që mbulon burimin tënd për ta pranuar. Një prefiks më i gjerë i interface-it nuk mund të sigurojë asnjërën.

Konfirmo të dyja drejtimet përpara se të ndryshosh diçka

Puno të dy skajet veçmas dhe shkruaj çfarë thotë secili. Në klient, rruga dhe zëri i peer-it; në server, imazhi pasqyrë plus rruga e tij e kthimit:

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

Kapja është ajo që zgjidh mosmarrëveshjet për drejtimin. Nëse paketat dalëse shfaqen në interface-in e grykës dhe serveri nuk regjistron asgjë, skaji i largët po i refuzon ato, zakonisht sepse burimi yt është jashtë listës së tij të lejuar. Nëse nuk shfaqet asgjë fare, rruga mungon ose tregon diku tjetër.

Më pas rregullo skajin më të ngushtë. Një zë në listën e lejuar në anën e serverit për adresën e klientit tënd dhe një zë në anën e klientit për subnet-in e destinacionit është forma normale, dhe ajo e lë prefiksin e interface-it në qetësi. Zgjero prefiksin vetëm nëse plani i adresave vërtet kërkon një subnet të përbashkët në atë lidhje, dhe bëje si ndryshim plani në vend të një hapi korrigjimi.