NetworkManager aŭ wg-quick: kiu posedas viajn WireGuard-itinerojn?
Du administriloj povas ambaŭ pretendi unu WireGuard-ligon, kaj la agordo, kiun vi redaktis, eble ne estas la valida. Trovu la posedanton per itineroj, reguloj kaj stato de la interfaco.
Vi ŝanĝas AllowedIPs en la WireGuard-dosiero, restartigas la tunelon, kaj la vojiga tabelo aspektas ĝuste kiel antaŭe. La kutima reago estas forigi la ĝenan itineron kaj daŭrigi, kio funkcias ĝis la sekva rekonekto metas ĝin reen. La dosiero, kiun vi redaktis, ne nepre estas la objekto, kiu produktis la staton, kiun vi vidas. Du administriloj povas ruli la saman protokolon sur unu maŝino, kaj nur unu el ili posedas la interfacon samtempe.
Mito: ekzistas unu WireGuard-agordo en la maŝino
wg-quick legas dosieron sub /etc/wireguard/ kaj konstruas la interfacon, kiam vi suprenigas ĝin. NetworkManager konservas konektan profilon en sia propra keyfile-formato kaj bildigas ĝin ĉe aktivigo, kaj importi wg-quick-dosieron kopias la valorojn en tiun profilon anstataŭ ligi al ĝi. Redakti la originalon poste ŝanĝas nenion, ĉar la profilo ne plu legas ĝin. La sama listo de kunuloj kaj ŝlosiloj do povas ekzisti dufoje, kun la dua kopio en vigoro.
Signo inda memori: ŝanĝoj, kiuj postvivas restartigon sed ne reimporton, venis de unu konservejo, kaj ŝanĝoj, kiuj malaperas ĉe restartigo, venis de la alia.
Unu praktika ekzemplo klare montras la dividon. Komparu nmcli connection show kun systemctl status wg-quick@wg0, poste kontrolu, al kiu interfaco la itineroj efektive pendas. Se la servo estas morta kaj la interfaco funkcias, la profilo faras la laboron, kion ajn diras la dosiero.
Mito: la vojigaj reguloj estas parto de WireGuard
La WireGuard-aparato en la kerno konas kunulojn kaj ŝlosilojn, kaj ĝi scias nenion pri politika vojigado. Ĉiuj ip rule rikordoj kaj pliaj tabeloj, kiujn vi vidas, estis instalitaj de la ilo, kiu suprenigis la interfacon. wg-quick povas aldoni fwmark kaj dediĉitan tabelon plus regulojn direktantajn al ĝi, dum NetworkManager instalas itinerojn per siaj propraj ipv4-agordoj kaj lasas DNS al tiu solvila dorservilo, kiun la sistemo uzas. Sama tunelo, malsamaj kromefikoj.
Legi ip rule kaj ip route show table all antaŭ ol ŝanĝi ion ajn, kaj notu, en kiu tabelo loĝas ĉiu itinero. Tabelnumero, kiun vi ne agordis, estas forta aludo pri la ilo, kiu kreis ĝin.
Mito: forigi la itineron estas solvo
Itinero forigita dum agado estas itinero, kiun la posedanto reinstalos ĉe la sekva aktivigo, kaj la aktivigo povas okazi sen vi: reviviĝo de tekkomputilo, linko-klako, restartiĝo de servo aŭ aŭtomata konekto de NetworkManager. Tial la sama itinero revenas kaj tial la provizora solvo sentiĝas malfidinda anstataŭ malĝusta. Unue identigu la administrilon, poste ŝanĝu la enigon, kiun tiu administrilo efektive legas.
Rekonekti kaj restartigi la koncernan servon estas la testo, kiu apartigas veran solvon de sola ŝajniga solvo.
Elektu unu posedanton kaj forigu la alian
Elektu la administrilon, kiun via deplojo subtenas, poste malŝaltu la konkurenan aktivigon per ĝia dokumentita regilo anstataŭ esperi, ke ĝi restos senaga. Maskita wg-quick-servo aŭ forigita NetworkManager-profilo estas eksplicita; lasi ambaŭ ŝaltitaj kaj lasi ilin konkuri ne estas. Konservu funkciantan aliron antaŭ ol malŝalti ion ajn, ĉar la interfaco portanta vian malproksiman seancon povas esti tiu, kiun vi baldaŭ forigos.
Post la ŝanĝo kontrolu inkluzivitan kaj ekskluzivitan trafikon, poste DNS, poste restartigu unufoje. Se la stato postvivas restartigon kun unu administrilo, vi havas posedanton anstataŭ koincidon.
La ĝenerala regulo indas konservi ankaŭ ekster WireGuard: kiam agordo daŭre revenas, ĉesu forigi la rezulton kaj trovu la procezon, kiu daŭre produktas ĝin.