nmcli VPN-lijst: opgeslagen profielen versus actieve tunnels

Je voert nmcli connection show uit en verwacht een lijst met VPN’s, maar krijgt elke verbinding die de machine ooit heeft opgeslagen, inclusief een bridge en een hotspot. De VPN die je zoekt, staat er misschien, is misschien als iets anders dan vpn getypeerd, of is helemaal geen NetworkManager-verbinding. Om te weten in welk van die drie gevallen je zit, zijn twee opdrachten nodig.

Twee lijsten, twee vragen

connection show antwoordt wat NetworkManager heeft opgeslagen, en connection show --active antwoordt wat er op dit moment aan een apparaat is gekoppeld. De eerste lijst bevat inactieve profielen, en dat is bewust: een opgeslagen VPN dat plat ligt, is nog steeds een profiel dat je misschien moet repareren. De twee verwarren geeft de indruk dat een tunnel draait terwijl alleen de configuratie bestaat.

Kies velden in plaats van de standaardtabel te lezen, want de standaarduitvoer verbergt het type op smalle terminals en breekt lange namen af.

NAME, UUID en TYPE zijn meestal alles wat je nodig hebt voor een eerste blik, en daarna bekijk je het ene item dat je interesseert via de UUID.

TYPE is waar de verrassingen zitten

OpenVPN verbindingen die via de plug-in worden beheerd, verschijnen als type vpn, omdat de plug-in een dienst binnen het algemene VPN-raamwerk is. Ingebouwde WireGuard-ondersteuning is een eigen volwaardig verbindingstype, dus filteren op vpn vindt het niet. Een zoekopdracht naar een WireGuard-tunnel die niets oplevert, is meestal een filterprobleem en geen ontbrekend profiel. Dat is een architectonisch verschil, geen naamkwestie.

Hetzelfde geldt voor andere tunneltypen die NetworkManager in de loop der tijd native leerde behandelen, dus lees de TYPE-kolom voordat je concludeert dat iets ontbreekt.

Lijst alles en filter daarna, en het profiel verschijnt.

Lees de UUID, niet alleen de naam

Namen zijn labels die mensen bewerken, en twee profielen kunnen er na een slordige import één delen. De UUID is de identiteit waarnaar opdrachten en bestanden verwijzen. Als een item er dubbel uitziet, vergelijk dan de UUID en de onderliggende instellingen voordat je iets verwijdert.

Activeringsopdrachten accepteren beide, en dat is precies waarom een op namen gebaseerde gewoonte uiteindelijk het verkeerde profiel wijzigt.

Kopieer de UUID in je notities wanneer je iets wijzigt dat je misschien moet terugdraaien.

Wat een opgeslagen profiel je niet vertelt

Een opgeslagen profiel zegt niets over of de tunnel omhoog is, en een actieve verbinding zegt niets over of het verkeer erbinnen werkt. Een tunnel die door wg-quick of door een service-unit wordt gestart, is helemaal geen NetworkManager-verbinding, dus hij ontbreekt op beide lijsten terwijl de interface duidelijk verkeer doorlaat. Controleer de interface en de routingtabel voordat je aanneemt dat het profiel ontbreekt. Een lege lijst bewijst alleen dat NetworkManager niet de eigenaar is.

Twee beheerders voor dezelfde interface is de andere versie van dit probleem, en het levert een lijst op die er goed uitziet terwijl de kernelstatus van iets anders is.

Eén eigenaar per interface houdt de lijst eerlijk, en de nmcli-referentie documenteert welke velden elke weergave werkelijk rapporteert.

Rapporteer zonder geheimen te lekken

connection show met een naam drukt instellingen af, en het toevoegen van --show-secrets drukt de privésleutels en wachtwoorden af samen met hen. Voor het plakken van een foutopsporing in een ticket zijn die niet nodig. Rapporteer in plaats daarvan het type, de UUID, de status en de relevante routes, en redigeer alles wat uit een geheimopslag kwam.

Interactieve activering met --ask is de ondersteunde manier om een ontbrekend inloggegeven te leveren, en onbeheerde automatisering heeft een andere goedgekeurde regeling nodig in plaats van een opgeslagen wachtwoord in platte tekst.

Een kort, geredigeerd rapport is makkelijker te beoordelen dan een volledige dump.