Beiträge von dan3o3

  • IPv6 Problem auf VPS System

    Zitat von eripek

    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

  • IPv6 Problem auf VPS System

    Zitat von chrko

    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

  • IPv6 Problem auf VPS System

    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!

  • IPv6 Problem auf VPS System

    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... ;)

  • 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