NM OpenVPN: den sparade profilen är inte din .ovpn-fil

Samma .ovpn fil ansluter från ett skal och tar timeout efter import till NetworkManager. Den naturliga slutsatsen är att VPN:en är trasig. Den mer sannolika förklaringen är mindre: NetworkManager behöll inte filen, den importerade en del av den till en sparad anslutning, och den körande tunneln använder i stället dessa sparade data. Vad filen säger nu är irrelevant för vad profilen innehåller.

Filen är inte profilen

Import är en översättning, inte en montering. Alternativ som insticksmodulen förstår blir nycklar i anslutningens vpn.data ordbok; alternativ som den inte förstår kastas eller registreras någon annanstans, och den ursprungliga sökvägen är bara en referens. Att redigera källfilen efteråt ändrar ingenting i anslutningen som redan är sparad.

Denna lucka förklarar en hel familj av rapporter: den delade nyckeln roterades, filen uppdaterades och tunneln misslyckas fortfarande. Den sparade profilen pekar fortfarande på den gamla sökvägen eller det gamla värdet, och kommandoraden fortsätter att fungera eftersom den läser filen du redigerade. Två klienter, två sanningar, och bara en av dem uppdaterades.

Läs den sparade profilen, inte dialogen

nmcli -f connection.id,connection.uuid,vpn.service-type,vpn.data connection show office-vpn

Använd UUID när två profiler delar ett namn, och bekräfta att tjänstetypen är det OpenVPN insticksprogram du förväntar dig, och inte en annan VPN-typ som råkar vara installerad. Jämför sedan slutpunkten, transporten och certifikatreferenserna med det fungerande anropet.

Ett värde som syns i en grafisk redigerare är inte bevis för att det sparades. Spara, öppna igen och läs tillbaka det via kommandoraden; historiska sparfel är en anledning att kontrollera de sparade uppgifterna, inte ett bevis för att varje nuvarande version har samma bugg. Kontrollen kostar ett kommando.

Två nycklar, och en riktning som spelar roll

För en anslutning som använder TLS-autentisering lagrar insticksmodulen sökvägen till den delade nyckeln i ta och riktningen i ta-dir, när driftsättningen använder en. Båda bor i profilens dataordbok, och båda måste matcha det servern förväntar sig.

Riktning är ett beslut på serversidan som uttrycks på klienten. Att välja en för att en närliggande profil har den är hur en fungerande nyckel börjar misslyckas med en handskakning. Om serverkonfigurationen är utan riktning bör klienten inte hitta på en riktning.

Själva nyckelfilen måste vara läsbar för insticksmodulen i det sammanhang där den faktiskt körs. Ett begränsat paket har en annan vy av filsystemet än en vanlig skrivbordsinstallation, så en sökväg som finns i ditt skal kan vara osynlig för tjänsten.

Uppdatera en post, inte ordboken

nmcli connection modify office-vpn +vpn.data 'ta=/etc/NetworkManager/certs/office-ta.key'
nmcli connection modify office-vpn +vpn.data 'ta-dir=1'

Det inledande plustecknet uppdaterar enskilda ordboksposter. Att tilldela vpn.data utan det ersätter hela ordboken, och det är så en saknad nyckel blir fem trasiga inställningar. Läs tillbaka profilen efter ändringen och bekräfta att de andra posterna överlevde. En ordbok som förlorade sin fjärrslutpunkt och sina certifikat är en mycket längre eftermiddag än den du började med.

Återanslut via de vanliga kontrollerna och observera steget som misslyckas. Om porten för delad nyckel nu passerar och klienten rapporterar ett certifikat- eller användarautentiseringsfel, har du kommit vidare och nästa undersökning är en annan.

Blanda inte ihop kontrollkanalens lägen

tls-auth, tls-crypt, och tls-crypt-v2 är olika arrangemang. En nyckelfil som ser likadan ut gör dem inte utbytbara, och att fylla i TLS-Auth-fälten eftersom en annan profil innehåller en formaterad nyckel ger en profil som misslyckas på ett sätt som liknar en felaktig nyckel.

Använd insticksmodulens mappning som matchar läget i serverns konfiguration. När läget är oklart, fråga serverägaren i stället för att gissa från filens första rad.

Behåll en återställningsväg när tunneln bär din administrationssession. En sparad ändring är inte nödvändigtvis en tillämpad ändring, och en lyckad import är inte bevis för att varje källalternativ stöddes. Båda luckorna är värda att känna till innan du återansluter länken du arbetar genom.