Beiträge von ConiKost

Ich hab mich getraut und es mal ausprobiert, indem ich ROS 7.17 Beta 5 installiert habe, welches heute erschienen ist. Funktioniert soweit ohne Probleme.

Entscheidend ist nur folgendes:

1) Neighbor Discovery muss das M-Flag aktiviert haben.

/ipv6/nd/set managed-address-configuration=yes

2) Pool mit /128 Prefixgröße anlegen, das ist so zwingend notwendig laut MikroTik. Prefix gibt dann die Nutzbaren Adressen an. /112 wäre als Beispiel die letzten 16 Bits FD23::0000 bis FD23::FFFF, welche an Clients ausgegeben werden. Vergebene Beispiel IP an ein Client: FD23::4

/ipv6/pool/add name=mypool prefix=fd23::/112 prefix-length=128

3) DHCPv6-Server Anlegen und den Pool inkl. Interface zuweisen. Optional könenn dann weitere Optionen und ähnliches gesetzt werden.

/ipv6/dhcp-server/add interface=bridge address-pool=mypool

Zitat von mbo77

- Einen ICMP-Ping kann man mitgeben, Pakete einer bestimmten Größe zu schicken und nicht zu fragmentieren:

Würde sagen, dass das passt. Pings bis Größe von 1464 möglich, was am Ende eine MTU von 1492 bedeuten würde. Das wäre mit PPPoE korrekt, da Baby Jumbo Frames vom ISP nicht unterstützt wird.

Zitat von mbo77

Dies sind Möglichkeiten, um Probleme mit der MTU und Fragmentierung einzugrenzen.

- Mittels tracepath die MTU entlang einer Route ermitteln:

Sieht auch für mich absolut okay aus. pmtu 1492 wird gemeldet.

Mit Last meinst du, wenn ich parallel so langsam hochladen? Dann hier. Ich sehe aber Null Unterschied.. Upload dümpelt mit ca. 85kb/s hoch. Verbindung via IPv6. IPv4 verhält sich identisch. Selbst im Falle von Download sehe ich Null Unterschied zu den unteren neuen MTR-Ausgaben.

Aber wenn es ein Peeringproblem wäre, dann dürfte doch ein direkter Wireguard-Tunnel das Problem eigentlich nicht umgehen? Wäre das jetzt ein anderer Server, wo ich mich hinverbinde, dann würde ich das in Richtung Peering deuten. Aber so?

Client -> Server

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|         xxxx:xxx:xxxx:xxxx:xxx:xxx:xx:1 -    0 |  111 |  111 |    0 |    0 |    0 |    0 |
|                        2a02:560:1:1::26 -    1 |  107 |  106 |    0 |    2 |   31 |    2 |
|                        2a02:560:1:2a::1 -    0 |  111 |  111 |    1 |    5 |   65 |    6 |
|                         2a02:560:1:9::2 -    0 |  111 |  111 |    1 |    6 |   56 |    2 |
|                        2a02:560:1:e1::2 -    0 |  111 |  111 |    1 |    1 |   17 |    1 |
|                    decix-gw.hetzner.com -    0 |  111 |  111 |    7 |    7 |    7 |    7 |
|                 core24.fsn1.hetzner.com -    0 |  111 |  111 |   11 |   11 |   12 |   11 |
|              ex9k2.dc3.fsn1.hetzner.com -    0 |  111 |  111 |   11 |   11 |   26 |   11 |
|                             xxxxxxxx.de -    0 |  111 |  111 |   11 |   11 |   12 |   11 |
|________________________________________________|______|______|______|______|______|______|
  WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)

Server -> Client

Start: 2024-11-13T23:06:19+0100
HOST: xxxxxxxx                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1.|-- 2a01:4f8::a:12:b                                         0.0%   110    0.3   0.5   0.2   7.5   1.0
 2.|-- core22.fsn1.hetzner.com (2a01:4f8:0:3::6a5)              0.0%   110    0.3   1.7   0.2  39.2   5.2
 3.|-- core0.fra.hetzner.com (2a01:4f8:0:3::4e2)                0.0%   110    4.8   4.9   4.8   5.2   0.1
 4.|-- ipv6.de-cix.fra.de.as13045.htp.net (2001:7f8::32f5:0:1)  0.0%   110   11.8  11.2  10.6  25.0   1.9
 5.|-- 2a02:560:1:e2::1                                         0.0%   110   16.5  13.1  10.8  41.6   4.3
 6.|-- 2a02:560:1:c::1                                          0.0%   110   15.5  13.5  11.0  57.5   5.2
 7.|-- ???                                                     100.0   110    0.0   0.0   0.0   0.0   0.0
 8.|-- xxxx:xxx:xxxx:xxxx:xx:xxx:xx:xxx                         0.0%   110   11.5  11.5  11.4  11.7   0.0

Kleines Update auf meine Nachfrage bei MikroTik: Damit ist normaler DHCPv6 Support für Clients tatsächlich gemeint. Dann kann man normal DHCP-Optionen und Adressen an IPv6-Clients gezielt ausgeben, wenn man das nicht per SLAAC machen will.

Hat jemand eine Einschätzung, ob das Peeringprobleme sind? Ich habe einen GF-Anschluss von htp und eine Dedi-Serverkiste bei Hetzner. Seit einiger Zeit (einen genauen Zeitrahmen kann ich nicht sagen) fällt mir auf, dass ich massive Uploadprobleme (getestet https, ftp und scp) habe. Während Download vom der Hetznerkiste nahezu vollen Gigaspeed bringt, läuft der Upload mit maximal 150-200kb/s. Egal zu welcher Uhrzeit. Sei es 3 Uhr nachts oder 14 Uhr Nachmittag oder 10 Uhr Vormittag.

Sobald ich zur erwähnten Hetznerkiste einen Wireguard-Tunnel (Wireguard ist direkt auf der Hetznerkiste installiert) direkt aufbaue (Alles wird dann darüber geroutet), habe ich allerdings vollen Uploadspeed. Wenn ich trenne, bricht die Geschwindigkeit sofort ein. Würde das aber nicht eher gegen ein Peeringproblem sprechen, da doch die Verbindung per Wireguard effektiv den selben Weg zum Server geht wie ohne?

Die regulären Testseiten für Geschwindigkeitstests wie speedtest.net oder Breitbandmessung liefern volle Geschwindigkeit.

MTR sieht aus meiner Sicht unauffällig aus?

=== Client -> Hetzner (IPv4) ===
|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                      cerberus.bsg75.lan -    0 |    9 |    9 |    0 |    0 |    0 |    0 |
|               a81-14-248-224.net-htp.de -    0 |    9 |    9 |    1 |    1 |    6 |    6 |
|               a81-14-249-144.net-htp.de -    0 |    9 |    9 |    1 |   10 |   47 |   25 |
|     Gi-6-1-0-1308.HRZ-R-P-00.net-htp.de -    0 |    9 |    9 |    2 |   11 |   56 |    2 |
|     Gi-1-1-0-1160.HTZ-R-P-00.net-htp.de -    0 |    9 |    9 |    1 |    1 |    4 |    1 |
|                    decix-gw.hetzner.com -    0 |    9 |    9 |    7 |    7 |    7 |    7 |
|                 core23.fsn1.hetzner.com -    0 |    9 |    9 |   11 |   11 |   12 |   12 |
|              ex9k2.dc3.fsn1.hetzner.com -    0 |    9 |    9 |   11 |   11 |   11 |   11 |
|                             xxxxxxxx.de -    0 |    9 |    9 |   12 |   12 |   12 |   12 |
|________________________________________________|______|______|______|______|______|______|

=== Hetzner -> Client (IPv4) ===

Start: 2024-11-13T11:05:57+0100
HOST: xxxxxxxxx                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1.|-- static.17.209.4.46.clients.your-server.de (46.4.209.17)  0.0%    10    0.2   2.7   0.2  13.9   5.2
 2.|-- core24.fsn1.hetzner.com (213.239.229.245)                0.0%    10    0.3   0.8   0.3   3.1   1.0
 3.|-- core4.fra.hetzner.com (213.239.224.90)                   0.0%    10    4.9   4.9   4.8   5.0   0.0
 4.|-- ipv4.de-cix.fra.de.as13045.htp.net (80.81.195.102)       0.0%    10   10.6  10.7  10.6  10.8   0.1
 5.|-- a81-14-249-160.net-htp.de (81.14.249.160)                0.0%    10   17.6  20.9  11.3  51.2  14.7
 6.|-- a81-14-249-8.net-htp.de (81.14.249.8)                    0.0%    10   11.8  13.8  11.1  21.1   3.8
 7.|-- a81-14-249-145.net-htp.de (81.14.249.145)                0.0%    10   26.7  13.7  11.2  26.7   5.2
 8.|-- axx-xxx-xx-xxx.net-htp.de (xx.xxx.xx.xxx)                0.0%    10   11.7  11.7  11.7  11.8   0.0

=== Client -> Hetzner (IPv6) ===

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|         xxxx:xxx:xxxx:xxxx:xxx:xxx:xx:1 -    0 |   14 |   14 |    0 |    0 |    1 |    0 |
|                        2a02:560:1:1::26 -   10 |   10 |    9 |    0 |    1 |    1 |    1 |
|                        2a02:560:1:2a::1 -    0 |   14 |   14 |    1 |    3 |   16 |    2 |
|                         2a02:560:1:9::2 -    0 |   14 |   14 |    1 |    2 |    7 |    4 |
|                        2a02:560:1:e1::2 -    0 |   14 |   14 |    1 |    1 |    4 |    3 |
|                   decix2-gw.hetzner.com -    0 |   14 |   14 |    7 |    7 |    7 |    7 |
|                 core24.fsn1.hetzner.com -    0 |   14 |   14 |   11 |   11 |   11 |   11 |
|              ex9k2.dc3.fsn1.hetzner.com -    0 |   13 |   13 |   11 |   11 |   11 |   11 |
|                             xxxxxxxx.de -    0 |   13 |   13 |   11 |   11 |   11 |   11 |
|________________________________________________|______|______|______|______|______|______|

=== Hetzner -> Client (IPv6) ===

Start: 2024-11-13T11:09:07+0100
HOST: xxxxxxxxx                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1.|-- 2a01:4f8::a:12:b                                         0.0%    10    0.2   0.3   0.2   0.4   0.0
 2.|-- core22.fsn1.hetzner.com (2a01:4f8:0:3::6a5)              0.0%    10    0.4   1.4   0.3   9.9   3.0
 3.|-- core0.fra.hetzner.com (2a01:4f8:0:3::4e2)                0.0%    10    4.9   4.9   4.9   5.0   0.1
 4.|-- ipv6.de-cix.fra.de.as13045.htp.net (2001:7f8::32f5:0:1)  0.0%    10   10.6  13.8  10.5  27.1   6.9
 5.|-- 2a02:560:1:e2::1                                         0.0%    10   11.4  11.9  10.8  15.1   1.4
 6.|-- 2a02:560:1:c::1                                          0.0%    10   21.3  12.9  11.0  21.3   3.6
 7.|-- ???                                                     100.0    10    0.0   0.0   0.0   0.0   0.0
 8.|-- xxxx:xxx:xxxx:xxxx:xx:xxx:xx:xxx                         0.0%    10   11.5  11.5  11.4  11.5   0.0

Vermutlich ist das was internes, wie z.B. ein Nimbus-Ticket bei der Telekom

Was ist denn ein Camel-Sync

Sofern MikroTik nicht was anderes mit der Aussage "DHCPv6 address delegation service" meint, soll in den nächsten ROS 7.17 Beta tatsächlich Unterstützung für DHCPv6 im Bezug auf Adressen kommen. War jedenfalls heute die Antwort von denen auf meine Frage, wie die Roadmap für DHCPv6 stateful support im LAN aussieht.

Da MikroTik per DHCPv6 PD an andere LAN Clients vergeben kann und SLAAC kann, wüsste ich nicht, was das sonst sein soll.

Das ist auch kein Dual Stack Lite. Dann würde IPv4 komplett via IPv6 getunnelt werden.

Ja, es gibt dafür keine Option leider..

Wie ich grad lernen musste, kann offenbar Windows kein Setzen eines statisch Interface Identifier für IPv6 (RFC 7217).. danke Microsoft .

Zitat von pufferueberlauf

Die Idee, dass es eine gute Idee waere eine EInzigartige Hardware ID mit der WEelt zu teilen... Wenn man das z.B. mit dem eigenen Notebook macht ergibt das ein 1A Tracking-Token das funktioniert egal in welchem (IPv6) Netz man sich mit dem Laptop eingelogt hat. Ein Traum fuer Werbetracker... und naiv finde ich, dass die IPv6 macher noche alle vom Guten im Internet ausgegangen sein mussten, dass ihnen diese Missbrauchssart gar nicht in den Sinn kam. Waren wohl noch unschuldigere Zeiten

Dagegen gibt es doch die Privacy Extensions. Du hast dann neben der abgeleiteten die temporäre IPv6-Adresse, welche per Standard genutzt wird. Wobei ich das für die öffentliche IPv6-Adresse garnicht im Sinne hatte. Verstehe aber gut, was du meinst.

Weißt du eigentlich, ob man auf mobilen Geräten in der Google und Apple Welt auch einen statischen Interface Identifier setzen kann?

Ich habe mit EUI64 lokal passend ULA am laufen. Ist ja am Ende eh nur intern für das Netzwerk gedacht. Wobei man nicht vergessen darf, IPv6 ist so alt, da hat man sich das Internet wie heute noch garnicht so vorgestellt

Zum Vergleich bei mir das fs.com-Modul an einem F2110 (AON htp):

Achsooo. Du meinst also ein statisch vergebener Interface Identifier auf dem Client. Du meinst dann sowas wie z.B. "ip token set ::AA:BB:CC:DD/64 dev eth1" (Gibt vielleicht ja noch andere Wege, nur als Beispiel gemeint).

Zitat von pufferueberlauf

Persoenlich halte ich EUI64 fuer zu naiv, aber jeder wie er/sie moechte.

Was ist daran naiv? (Ernstgemeinte Frage) Ich weiß, dass irgendein RFC EUI64 als deprecated erachtet, meine ich.

Zitat von pufferueberlauf

Na, auf dem Hoist der als Server dienen soll muss man schon manuell einen (gerne auch nur zusaetzlichen) festen IPv6 Interface-Identifier konfigurieren... damit braucht man dann nicht mehr den Umweg ueber die (ebenfalls nicht invariablen) MAC Adressen gehen zu muessen. Aber das hilft halt nur wenn die Firewall erlaubt Praefix-Bits zu ignorieren...

Ich nehme an, dass du mit dem Interface Identifier eben jene 64-Bits meinst, welche aus der MAC-Adresse sich bildet, aka EUI64 mit SLAAC?

Leider kann MikroTik bis heute kein Stateful DHCPv6.. und via SLAAC wüsste ich nicht, dass man per DUID eine feste IPv6-Adresse vergeben könnte. Maximal durch EUI64 predictable. Aber dann bräuchte man immer noch das Skript von flamy

Perfekt Vielen Dank, das war mir nicht so klar. Dann macht es auf jeden Fall Sinn mit dem Skript. Ich nehme an, dass die IPv6-Adressen via SLAAC und EUI64 vergeben wird, damit es 'predictable' bleibt?

Mich würde interessieren, was dein Einsatzzweck der Adresslist hier ist. Für Clients wie Port Forwarding? DNS? Welche Einträge nutzt du hier in der IPv6 Firewall mit den Adresslisten?

Alternativ wäre ja RouterOS mit dem RB5009 von MikroTik zu überlegen.

Zitat von flamy

Ich wüsste nicht, dass automatisch die ipv6 in einer Adressliste, bei einer Änderung des Präfixes geändert wird.

Das stimmt natürlich. Aber was genau ist hier dein Einsatzzweck mit den Adresslisten? Für eine Statefull Firewall ist nicht notwendig.