IPv6 Problem auf VPS System

  • Hallo Zusammen,


    ich habe aktuell ein Problem mit dem IPv6 routing auf meiner Shell und leider gibt mir der Support keine weitere Hilfestellung sondern verweist auf dieses Forum, ich hoffe jemand hier kann mir weiterhelfen.


    Ich nutze eine Standard Shell auf einem VPS Server (Ubuntu 18.04.3 LTS) und versuche derzeit mit meinem IPv6 /64er Netz etwas anzufangen, es sollen per Wireguard öffentliche V6 IPs an meine mobilen Clients rausgehen, Wireguard habe ich soweit problemlos am laufen.


    Das einzige was mir aktuell mega Kopfzerbrechen macht ist die Tatsache das alle IPv6 Adressen die ich nicht an eth0 binde aus dem Internet nicht erreichbar sind, die Ursache ist mir unklar.


    Hier konkret die Interfaces:


    Die an eth0 gebundene 2a03:xxxx:xx:566::1 ist einwandfrei erreichbar, die an wg0 gebundende 2a03:xxxx:xx:566:100::1 leider nicht, binde ich diese ebenfalls an eth0 läuft der Ping einwandfrei...


    Hier noch die aktuellen Routen:

    Code
    2a03:xxxx:2b:566:100::/72 dev wg0 proto kernel metric 256 pref medium
    2a03:xxxx:2b:566::/64 dev eth0 proto kernel metric 256 pref medium
    fe80::/64 dev eth0 proto kernel metric 256 pref medium default via fe80::1 dev eth0 proto static metric 1024 pref medium

    IPv6 Forwarding ist definitiv aktiv:

    Code
    cat /proc/sys/net/ipv6/conf/all/forwarding
    1


    Beziehe ich meine IPv6 Adressen via HE.NET Tunnel funktioniert das ganze übrigens einwandfrei, mir gehen also langsam die Ideen aus, auf folgende Nachfragen beim Support habe ich leider keine Antwort erhalten:


    - Müssen die Routen per RADVD oder DHCP6 announced werden?

    - Sperrt u.U. der VPS Traffic an IPs die er nicht direkt selber sieht?


    Hier die Route des funktionierenden Traffics:


    Code
      [...]
      5     7 ms     7 ms     6 ms  2a00:6020::d
      6    10 ms    10 ms    10 ms  2001:7f8::3:3a4:0:1
      7    10 ms    10 ms    10 ms  2a03:xxxx:xx:566::1


    Und hier der vor die Wand fahrende Traffic an die wg0 Adresse:


    Code
      [...]
      5     6 ms     6 ms     6 ms  2a00:6020::d
      6     *        *     2011 ms  2001:7f8::3:3a4:0:1
      7     *     Zielhost nicht erreichbar.


    IPTables kann ich übrigens ausschließen, eine Firewall sollte also nicht dazwischen funken...


    Hat jemand zufällig eine Idee was das sein sein kann und wie ich hier weiter komme?


    Dan

  • So, nach einiger Lektüre ähnlicher Threads, allerdings mit Docker Problematik habe ich die Lösung wohl gefunden:


    Code
    ndppd/bionic,now 0.2.5-3 amd64 [installed]
      daemon that proxies IPv6 NDP messages


    Folgende Config nutze ich:


    Code
    route-ttl 30000
    proxy eth0 {
    router yes
    timeout 500
    ttl 30000
    rule 2a03:xxxx:xx:566::/64 {
    static
    }
    }


    Und voila! Auch meine IP auf wg0 reagiert nun problemlos! Yipeeh... ;)

  • Also bezüglich Wireguard bin ich noch unerfahren. Zum IPv6-Problem kann ich nur allgemeine Ratschläge geben.

    Zunächst sollte über sysctl der Empfang von RA - router advertisements via eth0 unterbunden werden. In der Folge ist die Defaultroute fe80::1 statisch auf eth0 zu setzen. Damit wäre einmal gewährleistet, dass von dieser Seite nichts dazwischenfunkt. Ein Reboot könnte hilfreich sein, wenn das erledigt ist. Ausgehend davon würde ich dann debuggen wie folgt:


    Exkurs:

    Für den Wireguard-Prefix von /72 gilt im Grunde dass selbe wie für Subnetting bei IPv4. /72 ist spezifischer als /64, daher müsste der VPS als „Inhaber“ des /64 jedenfalls wissen, wie zu routen ist, auch, wenn man keine zusätzlichen Routen setzt.

    Voraussetzung, dass IPv6 im linklokalen Kontext seine IPs und Nachbarn richtig detektiert, ist, dass ICMPv6 durchgelassen wird - das ist nach Deiner Aussage ja der Fall.


    Debugging:

    Meine Vermutung wäre, dass beim Setup des wg0-Interfaces falsche Routen oder eine zweite Default-Route oder dergleichen injiziert werden - oder eben aufgrund von RA schon vorhanden waren.

    Ich würde daher an diesem Punkt daher erst einmal die Ausgaben von ip -6 r s vor und nach dem Tunnelaufbau vergleichen.


    In weiterer Folge wäre die Erreichbarkeit der lokal anliegenden IPs per Ping zu prüfen. Weiters reduziert sich durch Wg die MTU. Auch hier würde ich erst einmal von außen testen, ob die Reduktion entweder durch Path MTU oder durch PMTUd erkennbar ist. (ping -6 -Mdo -s 1472 [wg-if-ip]). Es müsste der reduzierte Wert von 1420 rückgemeldet werden, respektive bei -s-Parameter 1392 der Traffic unbeanstandet durchgehen.


    Für die Clients müsste wg dann, wenn der Tunnel up ist, eine spezifische Route setzen. Die Clients wiederum müssten entweder die öffentliche IP des wg-Partners im /72 oder dessen linklokale Adresse auf wg0 als (default-, wenn aller v6-Traffic darüber laufen soll) Route gesetzt haben.


    Wieso das Problem mit einem He-Tunnel nicht auftreten soll, kann ich mir nicht erklären. Ich vermute aber, dass die Route über den He-Tunnel nachrangig (höhere Metrik) behandelt wird, hier also Ursache und Wirkung verwechselt werden.

  • Hi eripek,


    danke für dein Feedback, soweit ich verstanden habe sind aber Routing etc. nicht das Thema sondern die Tatsache das wohl per NDP alle IPs announced werden müssen. Es sind immer wieder die kleinen Unterschiede die bei IPv6 zum stolpern bringen, das ARP hinfällig ist war mir gar nicht bewusst... ;)


    Scheinbar ist das auch nur relevant weil mit einem /64er Netz gearbeitet wird, über den Tunnel habe ich ein üppiges /48er Netz zur Verfügung, scheinbar funktioniert das Routing damit besser, bisher dachte ich immer das ist nur bei SLAAC interessant.


    Dieser NDP Proxy ist jedenfalls die aktuelle Lösung, ich bin momentan geneigt es so zu akzeptieren... :)


    Danke nochmal für deine Hilfe!

  • Hi eripek,


    danke für dein Feedback, soweit ich verstanden habe sind aber Routing etc. nicht das Thema sondern die Tatsache das wohl per NDP alle IPs announced werden müssen. Es sind immer wieder die kleinen Unterschiede die bei IPv6 zum stolpern bringen, das ARP hinfällig ist war mir gar nicht bewusst... ;)

    Voraussetzung, dass IPv6 im linklokalen Kontext seine IPs und Nachbarn richtig detektiert, ist, dass ICMPv6 durchgelassen wird - das ist nach Deiner Aussage ja der Fall.

    https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol


    Router Solicitation (Type 133)

    Router Advertisement (Type 134)

    Neighbor Solicitation (Type 135)

    Neighbor Advertisement (Type 136)

    Redirect (Type 137)


    (alles ICMPv6)


    Dass Du gepostet hast, während ich geantwortet habe, habe ich erst jetzt gesehen.


    Dass NDP Proxy aktiv sein müsste, halte ich erst einmal für ein Gerücht. Das Routing vom Gateway zum VPS betrifft ja den gesamten Prefix /64, aus dem auch Dein Wireguard schöpft. Die Clients hinter Wireguard haben eine linklokale Adresse und kommunzieren linklokal mit dem Server. Dass hier nur ein „host part“ des Prefix (<=64) zur Verfügung steht, sollte dem keinen Abbruch tun. Sofern Du den Clients eine öffentliche IP und die passende Route einträgst, kann ich keinen Use Case für einen NDP-Proxy erkennen. NDP-Proxying kann man übrigens auch schlicht im Kernel aktivieren: https://sysctl-explorer.net/net/ipv6/proxy_ndp/

    Einfaches NDP debuggen geht mit "ip -6 neigh show"


    Im Grunde hätte es wohl genügt, entweder manuell Einstellungen zu machen (client: route via lla des VPS/wg0 setzen und öff. IP aus /72 setzen, server: Route zur öff. IP des Clients via dessen lla) oder automatisiert über wg0 mittels radvd und/oder dhcpv6 Routen anzukündigen.


    Worin der Unterschied zum /48 bei he.net liegen sollte, ist mir nicht klar, außer, dass dort ein Linknet /64 und ein geroutetes Netz /48 existiert und der Tunnel über SIT realisiert wird, während hier ein natives v6-Netz vorliegt.

  • Das Problem ist "netcup-spezifisch". Wie dan3o3 bereits geschrieben hat, ist die gängige Lösung dazu gewesen, dass man den ndppd nutzt. Die sysctl Variable net.ipv6.conf.interface.proxy_ndp kannte ich bis jetzt noch nicht und habe ich noch nicht genutzt.


    Das erste IPv6 Netz einer KVM-Maschine bei netcup wird nicht geroutet, sondern "geswitcht". Dass bedeutet eben auch, dass du dich mit der Neighbour Discovery rumschlagen musst.

    Alle weiteren Netze, welche du hinzubuchen kannst und dem Server zu gewiesen sind, werden auf die angezeigte Adresse geroutet. Die Adresse setzt sich aus dem 64-Bit Präfix des ersten IPv6-Netzes zusammen und die letzten 64-Bit sind die "modified eui 64" der Ethernet-MAC-Adresse.


    Für deinen Anwendungsfall, dass du einen netcup Server als VPN-Server nutzen möchtest, welcher ein Netz nach hinten weiterreicht, ist das mit einem zusätzlichen v6-Netz von netcup deutlich einfacher, da du dann eben kein Neighbour Discovery Proxying machen musst, sondern ganz normal routest.

    Falls du stattdessen neben dem ersten IPv6-Netz von netcup dir einen Tunnel von Hurricane Electric legst, denke daran, dass du dann auch Source Based Routing machen musst, da du den Traffic nicht über das netcup-Netz ausleiten kannst.

  • Das erste IPv6 Netz einer KVM-Maschine bei netcup wird nicht geroutet, sondern "geswitcht". Dass bedeutet eben auch, dass du dich mit der Neighbour Discovery rumschlagen musst.

    Ich stimme da nicht ganz zu. Innerhalb der Broadcastdomain, über die auch die Linklokalen Adressen (hier des eth0) laufen - wie Du sagst „geswitched“ - läuft die Linklokale Kommunikation ab - wobei der Host nur sein Gateway fe80::1 kennen muss, über das auch sein öffentlicher Prefix geroutet wird. Und an diese Adresse wird dann ein etwaiges zusätzliches Netz geroutet.


    Bei he.net ist das nicht grundsätzlich anders. An die Stelle der Broadcast-Domain tritt ein SIT-Tunnel, innerhalb dessen zwar mit dem Linknetz (auch ein /64) gearbeitet wird. Das Linknetz liegt an jedem Tunnel-Endpoint mit einer Hostadresse - im Grunde /128 an, wobei auch hier eine LLA existieren muss. Das Routing erfolgt dann ebenfalls an die zugeteilte Adresse - mit dem Unterschied, dass es hier die Hostadresse des lokalen Endpunkts ist.

  • Das Problem ist "netcup-spezifisch". Wie dan3o3 bereits geschrieben hat, ist die gängige Lösung dazu gewesen, dass man den ndppd nutzt. Die sysctl Variable net.ipv6.conf.interface.proxy_ndp kannte ich bis jetzt noch nicht und habe ich noch nicht genutzt.

    Die Sysctl Geschichte habe ich ausprobiert und sie funktioniert leider nicht, was auch immer ndppd zusätzlich macht, die Kernel Variable reicht hier nicht.


    Zitat

    Für deinen Anwendungsfall, dass du einen netcup Server als VPN-Server nutzen möchtest, welcher ein Netz nach hinten weiterreicht, ist das mit einem zusätzlichen v6-Netz von netcup deutlich einfacher, da du dann eben kein Neighbour Discovery Proxying machen musst, sondern ganz normal routest.

    Hätte ich sogar in Betracht gezogen, allerdings finde ich diesen IPv6 Adressen Wahnsinn einfach verschwenderisch... :) Eigentlich ist das /64er Netz mehr als genug, wir reden hier von ner Hand voll Devices per VPN (Notebook, Handy etc.)...


    Zitat

    Falls du stattdessen neben dem ersten IPv6-Netz von netcup dir einen Tunnel von Hurricane Electric legst, denke daran, dass du dann auch Source Based Routing machen musst, da du den Traffic nicht über das netcup-Netz ausleiten kannst.

    Ich hatte sogar IPv6 von Netcup komplett disabled und nur den HE Tunnel genutzt, allerdings ist die Performance nicht genug, ich habe leider das Luxus-Problem eines FTTH 400/200er Anschlusses... ;)


    VG,

    Dan

  • Ich stimme da nicht ganz zu. Innerhalb der Broadcastdomain, über die auch die Linklokalen Adressen (hier des eth0) laufen - wie Du sagst „geswitched“ - läuft die Linklokale Kommunikation ab - wobei der Host nur sein Gateway fe80::1 kennen muss, über das auch sein öffentlicher Prefix geroutet wird. Und an diese Adresse wird dann ein etwaiges zusätzliches Netz geroutet.


    Ich gebe zu, bei der Routing Nummer via Link-Local stehe ich etwas auf dem Schlauch...

    Ähnliches kam auch vom Netcup Support, weiter ausführen wollte man das aber nicht mehr, ggf. kannst du mir mal konkret ein Beispiel aufzeigen, lerne ja gerne dazu...


    Code
    fe80::/64 dev eth0 proto kernel metric 256 pref medium
    default via fe80::1 dev eth0 proto static metric 1024 pref medium

    Aktuell sind das meine link-local Routen, eine Link-Local IP hat ausschließlich mein ETH0 Interface.

    Der Knackpunkt war ohne npddp habe ich auf eth0 nicht mal Pakete an die wg0 IP ankommen sehen (TCPDump), aus dem Grund wundere ich mich gerade etwas was bei mir Routen auf dem System ausrichten sollen...


    Dan

  • Der Knackpunkt war ohne npddp habe ich auf eth0 nicht mal Pakete an die wg0 IP ankommen sehen (TCPDump), aus dem Grund wundere ich mich gerade etwas was bei mir Routen auf dem System ausrichten sollen...

    Wireguard arbeitet meines Wissens auf Layer 3, ist also auf Routen angewiesen.

    Ich würde also verstehen, wenn über das wg0 ohne ndpdp nichts ankäme - wenn aber schon auf eth0 nichts ankommt, hast Du irgendwo in der Konfiguration vorher schon einen Knick gehabt.

    Ich gebe zu, bei der Routing Nummer via Link-Local stehe ich etwas auf dem Schlauch...

    Die Geschichte mit den LLAs ist so simpel, wie sie zunächst ungewohnt ist. Bei IPv4 gibt es das ARP (Address Resolution Protocol), das Dir für das Internet Protokoll den Bezug von IP-Adresse zu MAC-Adresse herstellt. Bei IPv6 hat man dieses Protokoll neu geschaffen und als NDP (Neigbor Discovery Protocol) im Wege von ICMPv6 realisiert. Es erfüllt im Grunde dieselbe Aufgabe wie ARP, kann aber mehr. Damit aber ICMP gesendet werden kann, benötigt man eine IP-Adresse: Ein Henne-Ei-Problem. Das wird in IPv6 einfach mit Linklokalen Addressen umschifft. Eine Linklokale Adresse ist pro Interface (pro Link - daher Link-Lokal) gültig.

    Sie setzt sich folglich aus dem Prefix fe80::/10 ergänzt um die MAC-Adresse in EUI64-Notation und einem Interface-Identifier zusammen.

    z.B.: fe80::[EUI64 der MAC-Adresse]%eth0.


    Da die MAC-Adresse pro Link jedenfalls eindeutig ist [Annahme], hat man mit IPv6 IMMER eine auch IP-Verbindung auf dem Link. Über diese IP-Verbindung kann man dann Nachbar-Informationen, Router-Informationen usw austauschen, aber auch routen (!).

    Damit aber so ein Routing von AUSSEN funktioniert, muss auch eine öffentliche IPv6-Adresse (meist ein Prefix mit /64, obwohl /128 auch genügen würde) auf dem Interface oder auf dem Router present sein, denn diese Adresse dient bei Paketen, die nach außen gehen, als Absenderadresse, an die sodann die Antwortpakete geschickt werden.


    fe80::1 ist im einfachsten Fall ein Alias für eine linklokale Adresse, meist verwendet man aber den Alias fe80::1 zur Ankündigung von redundanten Gateways etwa über Protokolle wie CARP (oder für Ciscoianer: HSRP oder in der Welt von Ascend Communications, DEC, IBM, Microsoft und Nokia: VRRP) - so auch in Hostingumgebungen.


    fe80::1 kann man seinerseits über SLAAC/radvd mittels Router Advertisment bekannt machen.


    Zur Funktionsweise eines NDP Proxy siehe: https://docs.paloaltonetworks.…ing/nptv6/ndp-proxy.html#


    Meiner Meinung nach ist ein NDP Proxy dann nicht erforderlich, wenn die Adresszuweisung aus dem Prefix korrekt gemacht ist. Wireguard müsste, wenn ICMPv6 funktioniert, Nachbarn korrekt auflösen und den mittels radvd delegierten Prefix an die Clients verteilen, sodass stets richtig geroutet wird, weil der Bezug von externem Prefix und LLA/Route stets aufgelöst werden wird. Wenn ich da einen Denkfehler haben sollte, lasse ich mich -bitte- gerne belehren.

  • Wireguard müsste, wenn ICMPv6 funktioniert, Nachbarn korrekt auflösen und den mittels radvd delegierten Prefix an die Clients verteilen, sodass stets richtig geroutet wird, weil der Bezug von externem Prefix und LLA/Route stets aufgelöst werden wird. Wenn ich da einen Denkfehler haben sollte, lasse ich mich -bitte- gerne belehren.

    Wireguard hat eine eigene Routingtabelle, die IP Adressen und die zugehörigen kryptografischen Schlüssel in einer Tabelle führt.

    Wireguard kann hierbei keine Duplikate von Netzwerken und einzelnen Adressen speichern.


    Außerdem muss jede erlaubte Adresse dem Wireguard per Konfiguration bekannt sein.

    Du kannst also nicht bei zwei Peers gleichzeitig die 0.0.0.0/0 Route als AllowedIps eintragen.

  • Wireguard hat eine eigene Routingtabelle, die IP Adressen und die zugehörigen kryptografischen Schlüssel in einer Tabelle führt.

    Wireguard kann hierbei keine Duplikate von Netzwerken und einzelnen Adressen speichern.

    Ist das so zu verstehen, dass es dann NDP unterbindet?!?