nmcli VPN-lista: sparade profiler kontra aktiva tunnlar

Du kör nmcli connection show och förväntar dig en lista över VPN:er, men får varje anslutning maskinen någonsin har sparat, inklusive en brygga och en hotspot. Den VPN du letar efter finns kanske där, är kanske typad som något annat än vpn, eller är inte alls en NetworkManager-anslutning. Att veta vilket av de tre fallen du är i kräver två kommandon.

Två listor, två frågor

connection show svarar på vad NetworkManager har sparat, och connection show --active svarar på vad som för närvarande är anslutet till en enhet. Den första listan innehåller inaktiva profiler, och det är avsiktligt: en sparad VPN som ligger nere är fortfarande en profil du kanske måste reparera. Att blanda ihop de två ger intrycket att en tunnel körs medan bara konfigurationen finns.

Välj fält i stället för att läsa standardtabellen, eftersom standardutskriften döljer typen på smala terminaler och radbryter långa namn.

NAME, UUID och TYPE är oftast allt du behöver för en första genomgång, och sedan granskar du den enda post du bryr dig om via UUID.

TYPE är där överraskningarna finns

OpenVPN anslutningar som hanteras via insticksprogrammet visas som typen vpn, eftersom insticksprogrammet är en tjänst inne i det allmänna VPN-ramverket. Inbyggt WireGuard-stöd är en egen fullvärdig anslutningstyp, så filtrering på vpn hittar den inte. En sökning efter en WireGuard-tunnel som inte ger något är oftast ett filterproblem och inte en saknad profil. Det är en arkitektonisk skillnad, inte en namnunderlighet.

Samma sak gäller andra tunneltyper som NetworkManager med tiden lärde sig hantera inbyggt, så läs TYPE-kolumnen innan du drar slutsatsen att något saknas.

Lista allt och filtrera efteråt, och profilen dyker upp.

Läs UUID:t, inte bara namnet

Namn är etiketter som folk redigerar, och två profiler kan dela en efter en slarvig import. UUID:t är den identitet som kommandon och filer refererar till. När en post ser dubblerad ut, jämför UUID:t och de underliggande inställningarna innan du raderar något.

Aktiveringskommandon accepterar båda, och det är just därför en namnmässig vana till slut ändrar fel profil.

Kopiera UUID:t till dina anteckningar när du ändrar något du kanske måste ångra.

Vad en sparad profil inte berättar

En sparad profil säger ingenting om huruvida dess tunnel är uppe, och en aktiv anslutning säger ingenting om huruvida trafiken inuti fungerar. En tunnel som startas av wg-quick eller av en tjänsteenhet är inte alls en NetworkManager-anslutning, så den saknas på båda listorna medan gränssnittet tydligt skickar trafik. Kontrollera gränssnittet och routingtabellen innan du antar att profilen saknas. En tom lista bevisar bara att NetworkManager inte är ägaren.

Två hanterare för samma gränssnitt är den andra versionen av det här problemet, och det ger en lista som ser rätt ut medan kerneltillståndet ägs av något annat.

En ägare per gränssnitt håller listan ärlig, och nmcli-referensen dokumenterar vilka fält varje vy faktiskt rapporterar.

Rapportera utan att läcka hemligheter

connection show med ett namn skriver ut inställningar, och att lägga till --show-secrets skriver ut de privata nycklarna och lösenorden tillsammans med dem. För en felsökningsklistring i ett ärende behövs de inte. Rapportera i stället typen, UUID:t, tillståndet och de relevanta rutterna, och maska allt som kom från ett hemlighetslager.

Interaktiv aktivering med --ask är det stödda sättet att ange en saknad inloggningsuppgift, och obevakad automatisering behöver ett annat godkänt arrangemang i stället för ett sparat lösenord i klartext.

En kort, maskad rapport är lättare att granska än en full utskrift.