Ich nutze schon seit Jahren auf dem Laptop einen VPN-Tunnel zu meinem Heimserver, um darüber aus der Ferne zu surfen und auch mit Linphone über den heimischen VoIP-Anschluß zu telefonieren. Da der Tunnel nur für IPv4 ist, mußte ich die Möglichkeit in Betracht ziehen, daß mein Laptop an einem Dual-Stack-Anschluß (z.B. t-com) einfach den Tunnel umgeht und z.B. der Browser IPv6 bevorzugt.
Das habe ich schon lange ganz pragmatisch gelöst:
Einfach IPv6 systemweit abschalten, sobald und solange ein VPN-Tunnel besteht. Das geht mit folgendem Script
/etc/NetworkManager/dispatcher.d/02noipv6onvpn (ausführbar machen!)
Code: Alles auswählen
#!/bin/sh -e
# Script to disable IPv6 during VPN-connections
# Place in /etc/NetworkManager/dispatcher.d/
if [ "$2" = "vpn-up" ]; then
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
fi
if [ "$2" = "vpn-down" ]; then
echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6
fi
Das hat auch nie Probleme gemacht, klappte problemlos aus dem Urlaub, bei Verwandten, ...
bis die Verwandten einen Dual-Stack-Anschluß bekamen. Daran wurde der Tunnel auch problemlos aufgebaut, IPv6 vom Interface wlan0 entfernt und das Routing korrekt gesetzt. Einziges Problem:
Schon nach kurzer Zeit - mal nach 5 Min., mal nach ½ Std. brach der Tunnel zusammen. Neu aufbauen ging zwar problemlos mit dem NetworManager (eine andere praktikable Lösung für VPN kenne ich nicht), aber es war immer nur von kurzer Dauer. Jetzt habe ich mich zu Hause auf die Ursachenforschung begeben (habe hier auch einen Dual-Stack-Anschluß) und dabei im syslog gefuden:
Nach einiger Zeit dieser Eintrag:
Code: Alles auswählen
NetworkManager[1243]: <error> [1477756533.957392] [platform/nm-linux-platform.c:1714] add_object(): Netlink error adding 2003:87:4e51:be00:a11:96ff:fef2:dc2c/64 lft 3419sec pref 0sec lifetime 1986-1[4,5404] dev wlan0 flags mngtmpaddr,noprefixroute src kernel: No Access
Code: Alles auswählen
NetworkManager:ERROR:platform/nm-linux-latform.c:1144: _init_ip_address_lifetime:assertion failed: (a_preferred <= a_valid && a_valid > 0 && a_preferred > 0)
Code: Alles auswählen
NetworkManager[9382]: <error> [1477683027.957145] [rdisc/nm-lndp-rdisc.c:241] send_rs(): (wlan0): cannot send router solicitation: -99.
Es ist der brühmt berüchtigte NetworkManager, der den Ärger macht. Er hat offenbar nicht registriert, daß IPv6 systemweit abgeschaltet wurde und versucht krampfhaft neue IPv6-Adressen zu beziehen (Btw.: andere Services, z.B. avahi, bekommen das wohl mit und entfernen ihre IPv6-Aktivitäten wie mDNS vom Interface wlan0). Der NM verstößt mit diesem Verhalten auch gegen RFC, wonach solche Anfragen (router solicitations) nach mehreren erfolglosen Versuchen einzustellen sind. Und für meine SSD mit komprimierendem Sandforce-Controller ist so ein Logging auch Gift!
Danach hab' dann den radikalen Weg getestet und IPv6 schon beim Booten disabled mit dem Kernel-Parameter
Code: Alles auswählen
ipv6.disable=1
Tags darauf kam mir noch eine weitere Idee:
Im Kernel IPv6 wieder enabled und im graphischen Frontend des NM die dem Tunnel zu Gruinde liegende WLAN-Verbindung editiert (Verbindung Bearbeiten) und im Tab "IPv6-Einstellungen" die Methode => Ignorieren gesetzt.
Das sieht dann im Konfigurationsfile so aus:
Code: Alles auswählen
[ipv6]
method=ignore
ip6-privacy=2
Das war die Lösung! - aber noch nicht das Ende!
Noch erstaunlicher war, daß das Interface trotz "ingnore IPv6" im NM immer eine IPv6-Adresse bekam. Die wurde zwar brav vom System entfernt, wenn VPN aktiv war, nach Beenden des Tunnels erhielt wlan0 wieder eine IPv6-Adresse, Aber:
Die privacy-extensions waren nicht mehr aktiv, dafür hatte ja bisher der NM gesorgt.
Die Lösung dafür:
Eine systemweite Konfiguratiosdatei erstellt:
/etc/sysctl.d/10-ipv6-privacy.conf
Code: Alles auswählen
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
Fazit:
Der NM ist zwar praktisch, aber vom Status eines "Managers" noch weit entfernt - gerade bezüglich IPv6 muß er noch in die "Lehre" gehen. IPv6-VPN-Tunnel beherrscht er garnicht, dann sollte er es wenigstens automatisch bei Benutzung eines IPv4-Tunnels aus Sicherheitsgründen abschalten.
Grüße, Ingo
EDIT: Es gibt noch einen Nachtrag hier: viewtopic.php?f=30&t=162779&p=1109286#p1109286