nmcli fortsätter fråga efter VPN-lösenordet: lagra hemligheten lokalt

Samma profil, två sessioner: den ansluter från skrivbordet och hänger över SSH på en uppmaning som ingenting kan svara på. Inget är trasigt och ingen inställning har gått förlorad. NetworkManager ber en hemlighetsagent om inloggningsuppgiften, och en hemlighetsagent är en skrivbordskomponent som inte finns i sessionen du använder.

Kör sekvensen nedan och tunneln kommer upp utan skärm, med förbehållet att lagring av en hemlighet ändrar vem som kan använda profilen.

Bekräfta diagnosen innan du ändrar något

Skillnaden mellan interaktiv och icke-interaktiv aktivering är hela diagnosen. Om nmcli --ask connection up lyckas medan en vanlig aktivering hänger sig, är profilen korrekt och hemlighetens källa saknas. Den enda jämförelsen sparar dig från att skriva om en fungerande konfiguration.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office IPsec" | grep -i flags

Läs flaggorna i stället för att gissa på dem. Värden som betyder "fråga en agent" är det du letar efter, och de exakta nyckelnamnen skiljer sig mellan VPN-insticksprogram eftersom de bor i insticksprogrammets egen dataordbok. En FortiSSL-profil och en IPsec-profil använder inte nödvändigtvis samma namn, så arbeta utifrån din egen profils utdata.

Bekräfta också att instickspaketet för det protokollet är installerat. Ett saknat insticksprogram visar sig som en okänd anslutningstyp eller som ett aktiveringsfel som inte säger något om lösenord, och att jaga hemligheten i det läget slösar bort samma timme två gånger. En paketfråga är billigare än en hel eftermiddag med att redigera nyckelfiler.

Flytta hemligheten till nyckelfilen

Anslutningsfilen ligger under /etc/NetworkManager/system-connections/. Hemligheter sparas inte där som standard, och det är poängen med flaggorna du just läste. Att sätta en flagga till noll talar om för NetworkManager att värdet lagras med profilen i stället för att efterfrågas vid aktivering.

[vpn]
password-flags=0

[vpn-secrets]
password=YOUR-VPN-PASSWORD

För en profil med två hemligheter upprepas mönstret: en flagga per hemlighet i [vpn]-avsnittet, och värdena i [vpn-secrets]. En IPsec-profil bär vanligtvis en fördelad nyckel vid sidan av användarens inloggningsuppgift, och insticksprogrammet namnger dem annorlunda än ett vanligt lösenordsfält, så kopiera nyckelnamnen från vpn.data-utdata i stället för från ett blogginlägg som använde ett annat insticksprogram. Ett felaktigt nyckelnamn ger en profil som läses in och sedan misslyckas vid autentisering, vilket läses exakt som ett felaktigt lösenord. Jämför din fil med en fungerande profil från samma insticksprogram innan du ansluter igen.

Sätt citattecken runt värden som innehåller blanksteg, citattecken eller ett dollartecken. Ett värde utan citattecken med ett $ i sig läses bokstavligt eller expanderas beroende på var det tolkas, och autentiseringsfelet som följer ser ut som ett felaktigt lösenord.

Rätta sedan filens ägarskap och läge. Dessa nyckelfiler läses av en privilegierad tjänst, och en fil som andra användare kan läsa behandlas som otillförlitlig, vilket är den vanliga anledningen till att en redigerad profil verkar ignoreras. Ägare root, läge 600, inga undantag.

Ladda om, aktivera sedan

Filen läses när anslutningen laddas, så det räcker inte att redigera den. Ladda om profilerna och lyft sedan anslutningen uttryckligen.

sudo nmcli connection reload
sudo nmcli connection up "Office IPsec"

Om omladdningen inte fångar ändringen gör en full omstart av tjänsten det, och det finns rapporter om just detta. Föredra omladdningen när andra länkar spelar roll, eftersom en omstart av tjänsten bryter varje hanterad anslutning, och på en fjärrvärd kan det avsluta din session innan tunneln du ville ha är uppe.

Använd UUID när namnen är tvetydiga. Maskiner med flera kundprofiler samlar nästan-dubbletter, och att aktivera fel ger ett fel som ser ut som ett problem med inloggningsuppgifterna.

När den lagrade hemligheten inte är problemet

En FortiSSL-profil kan misslyckas även med korrekt lagrad inloggningsuppgift eftersom klienten aldrig litar på gatewayens certifikat. Den inställningen finns inte i huvuddialogrutan; den ligger bakom de avancerade alternativen för VPN, där sammandraget av det betrodda certifikatet anges. Om loggen nämner certifikatet i stället för lösenordet är du i den här grenen, och ingen mängd redigering av [vpn-secrets] hjälper.

Hit hör ytterligare två kontroller. Bekräfta att profilen inte importerades från en fil som fortfarande pekar på en sökväg som insticksprogrammet inte kan läsa, och bekräfta att profilen är den aktiva och inte en inaktuell dubblett. Båda ger aktiveringsfel som läses som autentiseringsfel.

Bestäm om lagring är acceptabelt

En lagrad PSK och ett lösenord kan läsas av allt som körs som root på den maskinen. På en maskin du kontrollerar är det ett rimligt byte för en tjänst utan skärm. På en delad värd förtjänar det ett samtal, eftersom profilen nu innehåller en inloggningsuppgift som tidigare skyddades av skrivbordets nyckelring. Fråga vem mer som kan nå root på den värden innan du bestämmer dig, inte efter att ändringen är på plats.

Om policyn förbjuder lagrade VPN-hemligheter ska du inte försvaga profilen för att få ett cron-jobb att fungera. Kör anslutningen från en session som har en agent, eller använd en annan mekanism för automatiseringen.

Slutligen, notera vilka profiler som bär hemligheter så att ingen kopierar en till en bärbar dator utan att märka det. En kommentar ovanför hemlighetsavsnittet med datumet och skälet räcker, och den sparar någon en besvärlig granskning senare.