NetworkManager of wg-quick: wie besit jou WireGuard-roetes?

Jy verander AllowedIPs in die WireGuard-lêer, herbegin die tonnel, en die roetelys lyk presies soos voorheen. Die gewone reaksie is om die lastige roete te skrap en aan te beweeg, wat werk totdat die volgende herverbinding dit terugbring. Die lêer wat jy geredigeer het, is nie noodwendig die objek wat die toestand voortbring wat jy sien nie. Twee bestuurders kan dieselfde protokol op een masjien laat loop, en net een van hulle besit die koppelvlak op ’n slag.

Mite: daar is een WireGuard-konfigurasie op die masjien

wg-quick lees ’n lêer onder /etc/wireguard/ en bou die koppelvlak wanneer jy dit opbring. NetworkManager stoor ’n verbindingsprofiel in sy eie sleutellêerformaat en lewer dit by aktivering, en die invoer van ’n wg-quick-lêer kopieer die waardes in daardie profiel eerder as om daarna te skakel. Om die oorspronklike daarna te wysig, verander niks, want die profiel lees dit nie meer nie. Dieselfde lys eweknieë en sleutels kan dus twee keer bestaan, met die tweede kopie aan die werk.

’n Merk wat die moeite werd is om te onthou: wysigings wat ’n herbegin oorleef maar nie ’n herinvoer nie, kom uit een stoor, en wysigings wat by herbegin verdwyn, kom uit die ander.

Een praktiese voorbeeld maak die skeiding duidelik. Vergelyk nmcli connection show met systemctl status wg-quick@wg0, kyk dan watter koppelvlak die roetes werklik aanhang. As die diens dood is en die koppelvlak op is, doen die profiel die werk, wat die lêer ook al sê.

Mite: die roetereëls is deel van WireGuard

Die kern-WireGuard-toestel ken eweknieë en sleutels, en dit weet niks van beleidsroetering nie. Watter ip rule -inskrywings en ekstra tabelle jy ook al sien, is deur die gereedskap geïnstalleer wat die koppelvlak opgebring het. wg-quick kan ’n fwmark en ’n toegewyde tabel plus reëls wat daarheen wys, byvoeg, terwyl NetworkManager roetes deur sy eie ipv4-instellings installeer en DNS aan watter resolver-agtergrond die stelsel ook al gebruik, oorlaat. Dieselfde tonnel, verskillende newe-effekte.

Lees ip rule en ip route show table all voordat jy enigiets verander, en let op in watter tabel elke roete woon. ’n Tabelnommer wat jy nie gekonfigureer het nie, is ’n sterk wenk oor die gereedskap wat dit geskep het.

Mite: die skrap van die roete is ’n oplossing

’n Roete wat tydens looptyd geskrap word, is ’n roete wat die eienaar by die volgende aktivering sal herinstalleer, en die aktivering kan sonder jou gebeur: ’n skootrekenaar wat hervat, ’n skakelfladder, ’n diensherbegin of ’n NetworkManager-outokonneksie. Dis hoekom dieselfde roete terugkom en hoekom die noodoplossing onbetroubaar eerder as verkeerd voel. Identifiseer eers die bestuurder, verander dan die inset wat daardie bestuurder werklik lees.

Herverbinding en herbegin van die betrokke diens is die toets wat ’n regte oplossing van ’n netjies lykende een skei.

Kies een eienaar en verwyder die ander

Kies die bestuurder wat jou ontplooiing ondersteun, en deaktiveer dan die mededingende aktivering deur sy gedokumenteerde beheer eerder as om te hoop dit bly ledig. ’n Gemaskeerde wg-quick-diens of ’n geskrapte NetworkManager-profiel is eksplisiet; om albei geaktiveer te laat en hulle te laat resies jaag, is nie. Bewaar werkende toegang voordat jy enigiets deaktiveer, want die koppelvlak wat jou remote sessie dra, is dalk die een wat jy op die punt is om te verwyder.

Ná die verandering, verifieer ingeslote en uitgeslote verkeer, dan DNS, en herbegin dan een keer. As die toestand ’n herbegin met ’n enkele bestuurder oorleef, het jy ’n eienaar in plaas van ’n toevalligheid.

Die algemene reël is die moeite werd om buite WireGuard te behou: wanneer ’n instelling bly terugkom, hou op om die resultaat te skrap en vind die proses wat dit bly voortbring.