[solved, aber?] Stretch->Buster: VPN- und NetworkManager-Probleme

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
Benutzeravatar
ingo2
Beiträge: 1125
Registriert: 06.12.2007 18:25:36
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Wo der gute Riesling wächst

[solved, aber?] Stretch->Buster: VPN- und NetworkManager-Probleme

Beitrag von ingo2 » 29.11.2019 21:58:04

Habe vorgestern meinen Laptop (T520) vopn Stretch auf Buster upgegradet. Danach gab's 2 dicke Netzwerkprobleme:

1. Der Rechner hat gleich nach Reboot alle paar Minuten einen "Beep" von sich gegeben. Das war nicht so ein interner Piezo, sondern das kam über PulseAudio. Dachte erst an Überhitzung, SSD defekt - aber nichts dergleichen. Im SysLog bin ich dann fündig geworden:
Es wurde jeweils nach einem "username" oder "password" für OpenVPN gefragt. Das Log wurde regelrecht vollgespammt. Mein OpenVPN-Client braucht das aber garnicht, benutze ein Zertifikat das mit einem PW geschützt ist. OpenVPN mit dem NetworkManager funktionierte aber problemlos und beim Aufbau des Tunnels kam ein Pop-Up zur PW-Abfrage fürs Zertifikat. Das regelmäßige Piepen blieb dennoch.

Die Lösung habe ich inzwischen mühsam gefunden, deshalb hier in Kurzform:
Frühere OpenVPN-Versionen haben automatisch erkannt, wenn ein Zertifikat zum Autrhentifizieren benutzt wird. Dann wurde die Abfrage von user/PW nicht ausgeführt. Die Version in Buster tut das offensichtlich nicht mehr, sondern versucht per default direkt nach dem Booten die konfigurierte VPN-Verbindung herzustellen - was natürlich fehlschlägt. Das muß man jetzt manuell konfigurieren in der

Code: Alles auswählen

/etc/default/openvpn

AUTOSTART="none"
aktivieren (# entfernen) und fertig. Jetzt wird nicht mehr versucht, automatisch einen VPN-Tunnel aufzubauen, sondern nach Bedarf durch den NetworkManager.

2. Das nächste Problem:
Der NetworkManager kann zwar alle vorhandenen Profile in
/etc/NetworkManager/system-connections/ problemlos verwenden und eine Verbindung herstellen, aber die übersteht keinen Reboot oder Suspend (s2ram) - er verbindet nicht automatisch wieder. Auch langes Warten bringt nichts, manuell kann man jederzeit wieder über das NM-Applet verbinden.
Er scannt auch dauernd auf vorhandene WLAN's und aktualisiert seine Liste - nur verbinten tut er nicht.

Habe alles Mögliche probiert, auch exotische Optionen über "nmcli" und keine Lösung gefunden.
Der letzte Versuch war:
ganz einfach über das NM-Applet eine neue Verbindung zu konfigurieren - das geht dann, aber natürlich alles mit Default-Einstellungen und natürlich DHCP.

Das Profil geht dann einwandfrei. Die nachträgliche Konfiguration ist dann wirklkich mühsam, er akzeptiert nur ein paar Enstellungen, dann muß man sichern und die Konfiguration neu starten - ganz schön mühsam, wenn man fixe IP's haben will und einen eigenen DNS-Server und das Ganze für IPv4 und IPv6.
Der einzige Unterschied zum "alten" Profil ist der Dateiname, der bekommt dann ein Suffix ".nmconnection" und natürlich eine neue UUID. Manuell das Suffix an einen Profilamen anhängen bringt auch nichts.

Das kann's doch nicht sein, so ein "altes" Profil muß man (oder der Installer) migrieren können. Mir scheint, da fehlt nur eine Registrierung damit der NM nach Hochbringen des Interfaces im Bootvorgang nahtlos übernimmt und die Konfiguration fertigstellt?

Meine alten Profildateien kann ich also dann alle nach /dev/null schickem :hail:

Gruß, Ingo

Antworten