NetworkManager apo wg-quick: kush zotëron rrugët e tua WireGuard?
Dy menaxherë mund të pretendojnë të njëjtin lidhje WireGuard, dhe konfigurimi që redaktove mund të mos jetë ai në fuqi. Gjej pronarin nga rrugët, rregullat dhe gjendja e ndërfaqes.
Ndryshon AllowedIPs në skedarin WireGuard, rinis tunelin dhe tabela e rrugëtimit duket saktësisht si më parë. Reagimi i zakonshëm është të fshish rrugën shqetësuese dhe të vazhdosh, gjë që funksionon derisa rilidhja tjetër ta kthejë atë. Skedari që redaktove nuk është domosdoshmërisht objekti që prodhoi gjendjen që po shikon. Dy menaxherë mund të ekzekutojnë të njëjtin protokoll në një makinë, dhe vetëm njëri prej tyre zotëron ndërfaqen në çdo moment.
Miti: ka një konfigurim të vetëm WireGuard në makinë
wg-quick lexon një skedar nën /etc/wireguard/ dhe ndërton ndërfaqen kur e ngre. NetworkManager ruan një profil lidhjeje në formatin e vet keyfile dhe e paraqet në aktivizim, dhe importimi i një skedari wg-quick i kopjon vlerat në atë profil në vend që të lidhet me të. Redaktimi i origjinalit më pas nuk ndryshon asgjë, sepse profili nuk e lexon më. Prandaj e njëjta listë e partnerëve dhe çelësave mund të ekzistojë dy herë, me kopjen e dytë në fuqi.
Një shenjë që vlen të mbahet mend: ndryshimet që i mbijetojnë rinisjes por jo një riimportimi vijnë nga një depo, dhe ndryshimet që zhduken në rinisje vijnë nga tjetra.
Një shembull praktik e bën ndarjen të qartë. Krahaso nmcli connection show me systemctl status wg-quick@wg0, më pas kontrollo se nga cila ndërfaqe varen në të vërtetë rrugët. Nëse shërbimi është i vdekur dhe ndërfaqja është lart, profili po bën punën, çfarëdo që thotë skedari.
Miti: rregullat e rrugëtimit janë pjesë e WireGuard
Pajisja WireGuard në kernel njeh partnerët dhe çelësat, dhe nuk di asgjë për rrugëtimin me politikë. Çfarëdo ip rule hyrjesh dhe tabelash shtesë që sheh, i instaloi mjeti që ngriti ndërfaqen. wg-quick mund të shtojë një fwmark dhe një tabelë të dedikuar plus rregulla që tregojnë drejt saj, ndërsa NetworkManager instalon rrugë përmes cilësimeve të veta ipv4 dhe e lë DNS-në te backend-i i zgjidhësit që përdor sistemi. I njëjti tunel, efekte anësore të ndryshme.
Lexo ip rule dhe ip route show table all përpara se të ndryshosh gjithçka, dhe shëno në cilën tabelë jeton secila rrugë. Një numër tabele që nuk e konfigurove është një tregues i fortë për mjetin që e krijoi.
Miti: fshirja e rrugës është rregullim
Një rrugë e fshirë gjatë punës është një rrugë që pronari do ta instalojë përsëri në aktivizimin tjetër, dhe aktivizimi mund të ndodhë pa ty: zgjimi i një laptopi, dridhje e lidhjes, rinisje e shërbimit ose lidhje automatike e NetworkManager. Kjo është arsyeja pse e njëjta rrugë kthehet dhe pse zgjidhja e përkohshme duket jo e besueshme dhe jo e gabuar. Identifiko fillimisht menaxherin, pastaj ndrysho hyrjen që ai menaxher lexon vërtet.
Rilidhja dhe rinisja e shërbimit përkatës është testi që ndan një rregullim të vërtetë nga një që thjesht duket i rregullt.
Zgjidh një pronar dhe hiq tjetrin
Zgjidh menaxherin që mbështet vendosja e tua, më pas çaktivizo aktivizimin konkurrues përmes kontrollit të tij të dokumentuar, në vend që të shpresosh se do të mbetet joaktiv. Një shërbim wg-quick i maskuar ose një profil NetworkManager i fshirë është eksplicit; t'i lëshë të dyja të aktivizuara dhe t'i bësh të garojnë nuk është. Ruaj aksesin funksional përpara se të çaktivizosh gjithçka, sepse ndërfaqja që mban sesionin tënd në distancë mund të jetë pikërisht ajo që je gati të heqësh.
Pas ndryshimit, verifiko trafikun e përfshirë dhe të përjashtuar, pastaj DNS, pastaj rinis një herë. Nëse gjendja i mbijeton një rinisjeje me një menaxher të vetëm, ke një pronar dhe jo një rastësi.
Rregulli i përgjithshëm vlen të mbahet mend edhe jashtë WireGuard: kur një cilësim vazhdon të kthehet, ndalo fshirjen e rezultatit dhe gjej procesin që vazhdon ta prodhojë.