Server Support Forum
OpenWrt/OpenVPN: IPv6 Probleme wegen NDP

Zurück   Server Support Forum > >


Antwort
 
Themen-Optionen Thema bewerten
  #1  
Alt 07.03.2016, 19:42
Benutzerbild von killerbees19
killerbees19 killerbees19 ist offline
★ ①③ ④ⓑ ✛ ␀
 
Registriert seit: 10.2008
Ort: Wien (Österreich)
Beiträge: 511
OpenWrt/OpenVPN: IPv6 Probleme wegen NDP

Hallo,

ich verwende seit Jahren einen OpenVPN-Tunnel (tap!), um mehrere Netzwerke mit IPv6 zu versorgen. Das hat unter OpenWrt 12.09 (als Client) immer einwandfrei funktioniert. Jeder Standort bekommt dafür ein größeres Subnetz (mindestens /56) und verteilt einzelne /64 daraus an bestimmte VLANs weiter. Bei einer neuen Installation auf Basis von OpenWrt 15.05 habe ich das Problem, dass mir sporadisch die Verbindung wegbricht. IPv4 über den Tunnel funktioniert währenddessen weiterhin einwandfrei. Offensichtlich ist NDP die Problemursache, da die Neighbor Solicitations vom Server nicht beantwortet werden.

Code:
# ip -6 neigh show dev vpn (am Server)
2001:db8::10  router INCOMPLETE
fe80::1010:2020:3030:4040 lladdr 10:20:30:40:50:60 router REACHABLE

# ip -6 neigh show dev br-vpn (am Client)
2001:db8::1 lladdr 11:22:33:44:55:66 router REACHABLE
fe80::1111:2222:3333:4444 lladdr 11:22:33:44:55:66 router REACHABLE
Starte ich die Bridge am OpenWrt Router neu (br-vpn), die das tap-Device beinhaltet, funktioniert alles sofort wieder – dafür funktioniert IPv4 danach nicht mehr. Damit beides wieder läuft, muss ich die OpenVPN-Instanz (am Client) neu starten. Ich weiß im Moment aber nicht, warum es dazwischen plötzlich nicht mehr funktioniert. Die Firewall wirkt intakt und die Routing Tabelle ebenfalls. Was mir komisch vorkommt ist, dass die Link-Local Adresse vom Client in der Neighbor Tabelle als REACHABLE gelistet wird, das eigentliche Ziel fürs Routing aber weiterhin INCOMPLETE ist.

Was soll ich beim nächsten Ausfall (auf Server oder Clientseite) noch prüfen?
Habt ihr noch irgendwelche anderen Anhaltspunkte oder Tipps für mein Problem?


MfG Christian
__________________
» Real programmers don't comment. If it was hard to write, it should be hard to understand!
Mit Zitat antworten

  #2  
Alt 07.03.2016, 22:27
remote_mind remote_mind ist offline
Registered User
 
Registriert seit: 01.2012
Beiträge: 298
remote_mind eine Nachricht über ICQ schicken OpenWrt/OpenVPN: IPv6 Probleme wegen NDP
vielleicht könntest Du Dir mit proxy_ndp abhelfen (das IPv6-Äquivalent zu proxy arp).

http://www.geeklab.info/2013/05/ipv6-neighbour-proxy/

Dann müssen nicht mehr so viele NDP-Pakete über den Tunnel.
__________________
remote_minds IT - Nils Jürgens || Emsstraße 34 || 48431 Rheine
Email: nj@remoteminds.it || Tel: 05971 9600760 || Fax: 05971 9600759
USt-IdNr.: DE279523599
Mit Zitat antworten
  #3  
Alt 07.03.2016, 22:28
remote_mind remote_mind ist offline
Registered User
 
Registriert seit: 01.2012
Beiträge: 298
remote_mind eine Nachricht über ICQ schicken OpenWrt/OpenVPN: IPv6 Probleme wegen NDP
bzw. mit dem im Artikel erwähnten ndppd

https://github.com/DanielAdolfsson/ndppd
__________________
remote_minds IT - Nils Jürgens || Emsstraße 34 || 48431 Rheine
Email: nj@remoteminds.it || Tel: 05971 9600760 || Fax: 05971 9600759
USt-IdNr.: DE279523599
Mit Zitat antworten
  #4  
Alt 08.03.2016, 02:27
Benutzerbild von killerbees19
killerbees19 killerbees19 ist offline
★ ①③ ④ⓑ ✛ ␀
 
Registriert seit: 10.2008
Ort: Wien (Österreich)
Beiträge: 511
Ich hatte noch ein wichtiges Detail vergessen: Ich nutze dort nur deswegen tap anstatt tun, weil damals von Haus aus ältere OpenVPN Versionen (2.1/2.2) genutzt werden mussten und somit IPv6 nur so möglich war.

Bei OpenWrt gibt es die Bridge "br-vpn", die aber als eigenständiges Interface agiert. Kein VLAN oder sonst irgendeine Schnittstelle ist damit verbunden! Es wird alles hinüber geroutet. Am Server ist es genau das gleiche Verhalten. Mein /48 Netz wird vom Provider auf die primäre IP des Servers geroutet. Danach werden die kleineren Subnetze wieder weiter geroutet an die VPN-Clients.

Alle NDP Pakete im Tunnel bleiben also im Tunnel und werden nur von den jeweiligen Clients und dem Server verschickt sowie empfangen. Weder das Netz vom Provider (hinter eth0) oder die VLANS hinter den Clients bekommen davon etwas mit. Die Menge an NDP-Paketen ist somit überschaubar, da es nur eine handvoll Adressen der VPN-Clients aus einem /64 betrifft.

Die Jackpotfrage ist im Moment nur, was sich zwischen den beiden OpenWrt Versionen geändert hat, dass es plötzlich Probleme gibt. OpenVPN wurde von 2.2.2 auf 2.3.6 aktualisiert und der Linux Kernel ist deutlich neuer. Beides sollte aber nicht ausschlaggebend sein. Die alten Setups laufen unterdessen problemlos weiter…


MfG Christian
__________________
» Real programmers don't comment. If it was hard to write, it should be hard to understand!
Mit Zitat antworten
  #5  
Alt 09.03.2016, 11:45
Benutzerbild von killerbees19
killerbees19 killerbees19 ist offline
★ ①③ ④ⓑ ✛ ␀
 
Registriert seit: 10.2008
Ort: Wien (Österreich)
Beiträge: 511
Seit einem kurzen Internetausfall ist das Problem wieder aufgetaucht, davor war 20-30 Stunden Ruhe.
Was kann/soll ich noch testen? IPv4 über den Tunnel läuft gerade, IPv6 ist wieder gestört.

EDIT: Und plötzlich läuft es wieder von selbst, obwohl es stundenlang gestört war…


MfG Christian
__________________
» Real programmers don't comment. If it was hard to write, it should be hard to understand!

Geändert von killerbees19 (09.03.2016 um 11:51 Uhr)
Mit Zitat antworten
  #6  
Alt 09.03.2016, 13:05
Benutzerbild von killerbees19
killerbees19 killerbees19 ist offline
★ ①③ ④ⓑ ✛ ␀
 
Registriert seit: 10.2008
Ort: Wien (Österreich)
Beiträge: 511
Zitat:
Zitat von killerbees19 Beitrag anzeigen
Und plötzlich läuft es wieder von selbst, obwohl es stundenlang gestört war…
Offenbar läuft es plötzlich wieder, wenn ich tcpdump am OpenWrt-Router starte. Der Promiscuous Mode dürfte dafür sorgen, dass die Pakete wieder richtig beantwortet werden. Der nachfolgende Mitschnitt ist von der Serverseite aus gemacht. Um 11:46:58 wurde es dann auf der Clientseite ebenfalls gestartet. Danach funktionierte sofort wieder alles. Dieses Verhalten konnte ich jetzt mehrfach reproduzieren.

Code:
11:46:47.654209 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::0000:0000:0000:0002 > fe80::0000:0000:0000:0001: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::0000:0000:0000:0001
11:46:47.673633 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::0000:0000:0000:0001 > fe80::0000:0000:0000:0002: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::0000:0000:0000:0001, Flags [router, solicited]

11:46:52.499529 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::0000:0000:0000:0002 > ff02::1:ff00:10: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8::10

11:46:52.678939 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::0000:0000:0000:0001 > fe80::0000:0000:0000:0002: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::0000:0000:0000:0002
11:46:52.678991 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::0000:0000:0000:0002 > fe80::0000:0000:0000:0001: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::0000:0000:0000:0002, Flags [router, solicited]

11:46:53.498228 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::0000:0000:0000:0002 > ff02::1:ff00:10: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8::10
11:46:54.498281 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::0000:0000:0000:0002 > ff02::1:ff00:10: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8::10

11:46:58.091201 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::0000:0000:0000:0002 > ff02::1:ff00:10: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8::10
11:46:58.110626 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8::10 > fe80::0000:0000:0000:0002: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2001:db8::10, Flags [router, solicited, override]
Was läuft da vorher falsch? Kernel Bug? Firewall Problem? Routing Fehler? Konfigurationsfehler meinerseits?


MfG Christian
__________________
» Real programmers don't comment. If it was hard to write, it should be hard to understand!
Mit Zitat antworten
  #7  
Alt 11.03.2016, 01:37
Benutzerbild von killerbees19
killerbees19 killerbees19 ist offline
★ ①③ ④ⓑ ✛ ␀
 
Registriert seit: 10.2008
Ort: Wien (Österreich)
Beiträge: 511
Ich habe einmal meinen Testrouter (TL-MR3220) angeworfen und einen neuen User am VPN-Server angelegt. Minimalinstallation von OpenWrt 15.05 nur mit OpenVPN und sofort auf das gleiche Problem gestoßen. Upgrade auf die aktuellste Trunk Version und exakt das gleiche Verhalten.

Die Firewall blockt sicher nichts, soviel weiß ich mittlerweile. Ich habe ip6tables mit so vielen Debug-Regeln gefüttert, da bleibt nichts hängen, was nicht hängen bleiben soll. Das Routing sieht korrekt aus und der Kernel wurde von 3.18 auf 4.1 aktualisiert.

Ich bin mit meinem Latein am Ende! Hat noch irgendjemand Tipps, wie ich feststellen kann, warum die Neighbor Solicitation Pakete vom Client sporadisch nicht korrekt beantwortet werden? Oder muss ich den Fehler doch am VPN-Server suchen? Aktuellere Paketmitschnitte von beiden Seiten liefere ich gerne nach, sofern benötigt.


MfG Christian
__________________
» Real programmers don't comment. If it was hard to write, it should be hard to understand!
Mit Zitat antworten
  #8  
Alt 04.05.2016, 00:58
Benutzerbild von killerbees19
killerbees19 killerbees19 ist offline
★ ①③ ④ⓑ ✛ ␀
 
Registriert seit: 10.2008
Ort: Wien (Österreich)
Beiträge: 511
Die vermutliche Ursache: Die Bridge in OpenWrt hatte IPv4/IPv6 Adressen, der tap-Adapter nur eine für IPv4. Offenbar hat das den Kernel in der aktuellen Version durcheinander gebracht, weil die Bridge nicht immer zum VPN-Device passte. Die aktuelle Empfehlung ist, den Adapter innerhalb von OpenWrt mit dem Protkoll "none" abzubilden. Das wäre damals aber nicht möglich gewesen.

Diesen Mischmaschmurks versuche ich gerade mit einem neuen Setup zu korrigieren, wo nur noch tun verwendet wird und auf die eingebaute IPv6-Funktionalität von OpenVPN gesetzt werden soll. tap ist somit nicht mehr notwendig, da alle Clients mittlerweile bei Version 2.3 angekommen sind.


MfG Christian
__________________
» Real programmers don't comment. If it was hard to write, it should be hard to understand!
Mit Zitat antworten
Antwort

Lesezeichen


Themen-Optionen
Thema bewerten
Thema bewerten:

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist aus.
HTML-Code ist aus.

Gehe zu

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Rootserver Restposten - für jeden etwas dabei! IP-Projects.de Biete 0 02.05.2015 09:26
Root-Server Restposten ab 23,90 € / M - 92,00 € / M IP-Projects.de Biete 0 02.12.2012 09:42
Going to sleep 2bit-gehirn Virtuelle Server 7 02.04.2009 18:53
Apache2 CPU Last 100% huppsi Webserver 12 01.08.2008 11:41
gehackt? koepie Dedizierte Server 9 14.11.2007 20:09


OpenWrt/OpenVPN: IPv6 Probleme wegen NDP
OpenWrt/OpenVPN: IPv6 Probleme wegen NDP
OpenWrt/OpenVPN: IPv6 Probleme wegen NDP OpenWrt/OpenVPN: IPv6 Probleme wegen NDP
Powered by vBulletin® Version 3.8.11 (Deutsch)
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2018 DragonByte Technologies Ltd.