mDNS mbi WireGuard: tre porta para se të përgjigjet një peer

Vendosja e flamurit multicast në një pajisje WireGuard e bën ndërfaqen të përshtatshme për softuerin e zbulimit, dhe kaq bën flamuri. Ai nuk i thotë protokollit ku duhet të shkojë një paketë grupi, dhe në një pajisje me disa peer nuk ka një përgjigje të vetme të qartë. Tre porta të veçanta qëndrojnë midis një daemon që punon dhe një shërbimi të zbuluar.

Testojini me radhë, sepse kalimi i njërës nuk thotë asgjë për tjetrën.

Porta e parë: flamuri dhe politika e daemon-it

Një pajisje WireGuard në Linux krijohet si një lidhje pikë-për-pikë pa ARP dhe nuk e mban flamurin multicast si parazgjedhje. Shtimi i flamurit është një ndryshim lokal i ndërfaqes, i kryer nga çdo gjë që e administron pajisjen. Avahi ka pamjen e vet të botës mbi këtë, dhe politika e tij e parazgjedhur i anashkalon plotësisht ndërfaqet pikë-për-pikë. Prandaj zbatohen dy teste të pavarura përshtatshmërie para se të lëvizë edhe një paketë e vetme.

Pra daemon-i ka nevojë për një vendim të shprehur, jo thjesht një proces që punon. Kontrollet e tij të dokumentuara përfshijnë allow-interfaces, deny-interfaces dhe allow-point-to-point, dhe i fundit është cilësimi që njerëzit e anashkalojnë.

Kontrollet më poshtë raportojnë flamujt e lidhjes, rrugën multicast dhe nëse konfigurimi i daemon-it analizohet fare:

ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --check

Një daemon që u nis me sukses nuk ka hapur domosdoshmërisht soketa në ndërfaqen që ju intereson. Lexoni konfigurimin e tij efektiv në vend që të supozoni se statusi i shërbimit është i barabartë me mbulimin.

Porta e dytë: rruga drejt grupit

Porta e dytë është rrugëtimi i zakonshëm. Një paketë e adresuar drejt 224.0.0.251 ndjek tabelën e përcjelljes si çdo gjë tjetër, dhe nëse tabela e nxjerr përmes ndërfaqes fizike LAN, asnjë konfigurim WireGuard nuk do ta ndryshojë atë. Rregulloni së pari rrugën dhe pjesa tjetër e hetimit shkurtohet. Shikoni çfarë raporton kernel-i për adresën e grupit përpara se të prekni ndonjë çelës peer.

Pa një rrugë të caktuar, kernel-i kthehet te trajtimi i vet multicast i lidhjes, prandaj parazgjedhja duket e saktë në një LAN të sheshtë dhe e gabuar sapo i njëjti trafik grupi duhet të dalë përmes një tuneli. Dështimi është i heshtur nga ana e dërguesit: kërkesa shkon diku, dhe përgjigja nuk arrin kurrë.

Porta e tretë: WireGuard zgjedh një peer për paketë

WireGuard zgjedh një peer në dalje duke kërkuar destinacionin në grupet e adresave të lejuara, dhe rruga e transmetimit të Linux-it e kryen atë kërkim një herë për paketë. Rezultati është një, dhe paketa kriptohet për atë peer. I njëjti prefiks grupi që shfaqet në listat e lejuara të disa peer-ëve nuk krijon anëtarësi ose replikim; krijon një kërkim të paqartë që zgjidhet te njëri prej tyre.

Në një lidhje të dedikuar me dy skaje kjo është pikërisht ajo që dëshironi, sepse ka një marrës të vetëm të synuar për trafikun e grupit që transportohet me qëllim. Në një ndërfaqe me pesë peer është një kufizim, jo një veçori, dhe rregullimi i takon projektimit dhe jo konfigurimit të ndonjë peer-i të vetëm.

Një projekt me shpërndarje ka nevojë për një rele të shprehur, lidhje të veçanta ose një mekanizëm zbulimi krejt tjetër. Publikimi i një recete me dy skaje si zgjidhje për shumë klientë sepse çdo klient mund të pingojë portën është mënyra se si kjo vendoset gabimisht.

Drejtimi hyrës kontrollohet ndryshe: burimi i një pakete të marrë duhet të bjerë brenda listës së lejuar të peer-it të vërtetuar. Shtimi i një destinacioni multicast aty nuk zëvendëson pronësinë reale të burimit të dërguesit.

Reflektimi është një kufi, jo një urë

Reflektori i Avahi riprodhon mesazhet mDNS midis ndërfaqeve që zgjedh, në shtresën e aplikacionit. Është një kufi zbulimi midis rrjeteve, jo një urë Ethernet dhe jo një ruter multicast i përgjithshëm. Dy reflektorë të lidhur me të njëjtat rrjete krijojnë me kënaqësi një lak njoftimesh të përsëritura.

Reflektimi gjithashtu u dorëzon emrat e shërbimeve dhe metadat e tyre një rrjete tjetër, që është një vendim privatësie po aq sa një vendim rrugëtimi. Kufizoni ndërfaqet e zgjedhura dhe përdorni filtra shërbimesh aty ku versioni i instaluar i mbështet, në mënyrë që vetëm njoftimet që i nevojiten një përdoruesi të autorizuar të kalojnë kufirin.

Zbulimi dhe përdorimi mbeten rezultate të veçanta. Një klient mund të shohë njoftimin e një shërbimi adresa e shpallur e të cilit është e paarritshme nga vendi ku ndodhet klienti, ose porta e të cilit refuzohet nga politika e tij e aksesit. Konfirmoni lidhjen me shërbimin pasi njoftimi të shfaqet, dhe nëse aplikacioni mbështet një emër DNS të qëndrueshëm ose një adresë serveri të shprehur, preferojeni atë në vend të zgjerimit të zbulimit lokal të lidhjes. Përshkrimi i rrugëtimit me çelës kriptografik mbulon zgjedhjen e peer-it bazuar në destinacion nga e cila varet e gjithë kjo.