[Michi240281]

Hat denn hier schon jmd versucht in den Einstellungen des Genexis das Interface abzuschalten und die Einstellung wieder importiert? Würde dann die FB eine "vernünftige" IPv6 bekommen können?

[Schimmelreiter]

(03.10.2014, 11:49)Michi240281 schrieb:  Hat denn hier schon jmd versucht in den Einstellungen des Genexis das Interface abzuschalten und die Einstellung wieder importiert? Würde dann die FB eine "vernünftige" IPv6 bekommen können?

Einfach so "bekommen" würde sie sie nicht, aber dann könnte man anscheinend doch eine Konstruktion basteln, in der die Fritz!Box den richtigen 6rd-Tunnel aufbaut.

Unter Umständen wäre aber die Erreichbarkeit der "Nachbarn" eingeschränkt ...
also "Ganzes IPv6-Internet außer anderen fl!nk-Kunden".

Aber je umständlicher die Konfiguration, um auf Biegen und Brechen dieses Ziel zu erreichen, desto mehr geht die Einrichtung in Richtung "Proof-of-concept", also machbar aber nicht wirklich praktikabel.


Obwohl, eigentlich sollte man es mal genau so konfigurieren, wie Du es getan hast.
Wenn es zig Versuche gibt falsche 6rd-Tunnel aufzubauen, dann sieht GFD vielleicht mal, welchen Bärendienst sie der Netzintegrität (Die immer als Argument herhalten muß, wenn ein Anbieter seine Zwangsrouter durchdrücken will) mit der Abschaltung der sauberen Lösung geleistet haben.


Für diejenigen, die die Screenshots nicht gesehen haben:

Mit den Einstellungen ...

IPv4-Adresse des Tunnelendpunktes: 100.127.0.1
IPv6-Präfix: 2a00:61e0:: / 32
IPv4-Maskenlänge: 8

... baut die Fritz!Box tatsächlich einen 6rd-Tunnel auf, allerdings leitet sie dabei das Präfix aus ihrer vermeintlichen WAN-IPv4 (z.B. 192.168.100.1) aus dem lokalen Netz des Genexis her, sie käme also auf das Präfix
2a00:61e0:a864:0100::/56
und auf dieses Präfix kommt dann logischerweise jede Fritz!Box, die als 192.168.100.1 im Netz des Genexis konfiguriert ist und das wird mit einiger Sicherheit mehr als eine sein ...


Das richtige Präfix kann sie bei diesen Einstellungen also nur dann ableiten, wenn der 2., 3. und 4. Teil der "WAN"-IPv4 der Fritz!Box mit der tatsächlichen WAN-IPv4 am Genexis übereinstimmt, wer also z.B. die
WAN-IPv4 100.64.100.200
hat, muß dafür sorgen, daß die Fritz!Box WAN-seitig die IPv4
10.64.100.200
sieht, nur dann kommt sie auf das richtige Präfix (Die 10 wird bei einer IPv4-Maskenlänge von 8 nicht berücksichtigt und 64.100.200 sind gleich).

Daraus resultieren drei Probleme:

• Solange der 6rd-Tunnel im Genexis aktiv ist, kann das nicht klappen, weil dann beide, Fritz!Box und Genexis, versuchen, denselben Tunnel aufzubauen.
• Bei jedem IP-Wechsel müßte der Genexis-Router und die Fritz!Box umkonfiguriert werden, um wieder Deckungsgleichheit herzustellen.
• Bei 6rd bilden alle Systeme mit selben Einstellungen eine 6rd-Domäne und kontaktieren sich direkt, unter Umgehung des 6rd-Gateways, per IPv4:
  
  Die Router mit den Präfixen 2a00:61e0:4070:5000::/56 und 2a00:61e0:4072:5200::/56 usw. usf. würden also
  - erkennen, daß sie in derselben 6rd-Domäne liegen
  - das Ziel-Präfix auf die IPv4 zurückrechnen, also xxx.64.112.80 bzw. xxx.64.114.82
  - dann für xxx die gestrichenen 8 Bit (oder die ersten 8 Bit des Gateways) ergänzen
  und
  - das umgebende IPv4-Paket direkt an 10.64.114.82 bzw. 10.64.112.80 statt an das Gateway adressieren.
  
  Wenn sie die gestrichenen 8 Bit aus der Gateway-Adresse holen, kommen sie auf 100. und damit die richtige IPv4, wenn sie sie aber aus der eigenen "WAN"-IPv4 holen kommen sie auf 10. und erzeugen somit ein Paket, das sein Ziel nie erreichen wird -> Andere fl!nk-Kunden wären nicht erreichbar.

Besser wäre es also, man modifiziert die 6rd-Parameter so, daß die IPv4-Maskenlänge 32 beträgt, dann gibt es keine gemeinsame 6rd-Domäne mehr und die vermeintliche "WAN"-IPv4 der Fritz!Box wäre egal, da dieser Teil im Präfix fest eingetragen würde ...
Das klappt aber derzeit irgendwie noch nicht so recht ...
Vermutlich müßte man erst den Genexis überzeugen, keinen 6rd-Tunnel mehr aufzubauen, damit er für die Fritz!Box (oder einen anderen nachgeschalteten Router) frei wird.

Es bleibt der Nachteil, daß die Fritz!Box nun bei jedem IP-Wechsel umkonfiguriert werden müßte, da der 6rd-Tunnel für die neue WAN-IPv4 angepaßt werden muß.
Immer bis das passiert kollidiert der 6rd-Tunnel des alten IPv4-Inhabers mit dem des neuen, aber das ist genau das, was fl!nk/GFD verdient hat.

[Michi240281]

Das heißt, dass mit den Einstellungen, die ich bisher vorgenommen habe, bei Flink/NEW/DGF auf den Servern Anfragen ankommen, die für "Chaos" sorgen? Also die merken dann, dass da was passiert und "ins Leere läuft", was dann Auswirkungen auf die Netzintegrität haben könnte? Dann bin ich dafür, dass das so viele wie möglich so einstellen, um die DGF zum Umdenken zu bewegen und die saubere Lösung wieder ermöglichen!

EDIT: Hab mir jetzt auch mal die Einstellungen des Genexis exportiert. Ist ja recht übersichtlich. Wenn ich mich dazu entschließe, mal probeweise den "tunnnel 1" mit einem "shutdown"-Befehl zu versehen, wie müsste ich denn im Falle, dass dann der Genexis kein 6rd Tunnel mehr aufbaut die Einstellungen in der FB ändern? Nen Risiko sollte es bei den Genexis-Einstellungen ja nicht geben, oder? Per IPv4 sollte ich ja nach wie vor auf die Box kommen um die originale cfg wieder zu importieren! Vllt gäbe es ja sogar einen Befehl, den man da eintragen könnte, damit aus

interface tunnel1
ipv6 access-group guiipv6aclfwdin forward

irgendwie ein Bridge-Modus wird?

Und wenn man hier was ändert:

interface vlan1
!ip address dhcp
!ipv6 address auto

könnte man ja vllt dafür sorgen, dass sich der Genexis nicht mehr per DHCP ne IPv4 vom NEW Server holt, sondern immer die gleiche behält?!? Zumindest könnte man im Netz für noch mehr Verwirrung sorgen!!! ;-)

[Schimmelreiter]

(03.10.2014, 16:06)Michi240281 schrieb:  Das heißt, dass mit den Einstellungen, die ich bisher vorgenommen habe, bei Flink/NEW/DGF auf den Servern Anfragen ankommen, die für "Chaos" sorgen? Also die merken dann, dass da was passiert und "ins Leere läuft", was dann Auswirkungen auf die Netzintegrität haben könnte?

Mit Deinen Einstellungen quillt "bestenfalls" ein Log auf ...

Deine Einstellungen führen dazu, daß die Fritz!Box ein Präfix ableitet, das es gar nicht geben kann:
Der für CGN reservierte Adressbereich geht von
100.64.0.0
bis
100.127.255.255

Daraus folgt, daß die für IPv6 an den Kundenanschlüssen genutzten Präfixe zwischen
2a00:61e0:4000:0000::/56
und
2a00:61e0:7fff:ff00::/56
liegen.

Mit der üblichen Einstellungen für private LANs von 192.168.x.y landet man aber zwischen
2a00:61e0:a800:0000::/56
und
2a00:61e0:a8ff:ff00::/56

Wenn die Leutz bei GFD/fl!nk ihren Job nicht komplett im Lotto gewonnen haben, dann werden sie diesen Adressbereich erst gar nicht zum 6rd-Gateway routen, sondern nur den, der sich valide ergeben kann (Also 2a00:61e0:4000::-2a00:61e0:7fff:ffff:fff:fff:fff:fff).

Der schlimmstmögliche Schaden, der auftreten könnte, wäre, daß dieser Adressbereich für andere Zwecke in Benutzung ist und nun dort Anfragen aufschlagen, die für Dich bestimmt waren, weil Du vorgibst, diese Adressen zu besitzen, sie aber trotzdem zum richtigen Ziel geroutet werden.

Aber wieviele Anfragen wären das wohl? Ja nur die Handvoll privater Clients, die Du so hast.
Dein eigener Schaden ist viel größer, weil Deine Rechner nun versuchen, mit diesen IPv6-Adressen zu arbeiten, keine Antworten kriegen und dann erst auf IPv4 zurückfallen ....

---

Übrigens:

Wenn GFD/fl!nk den Kunden schnell helfen wollte, dann könnten sie den Kunden ein 6in4-Gateway zur Verfügung stellen.

Externe 6in4-Anbieter wie Hurricane Electric oder SixXS könnt Ihr nicht nutzen, weil Eure IPv4-Adressen von der Außenwelt nicht erreichbar sind, genau das muß das 6in4-Gateway aber können.
Ein 6in4-Gateway innerhalb des fl!nk/GFD-Netzes könnte das aber.

Ich finde es immer sehr spannend, daß Firmen in Deutschland unglaublich kreativ sind, wenn es darum geht, den Kunden zu ärgern, aber nie, wenn es darum geht, ihm auch mal entgegen zu kommen.

Nichts spricht dagegen, auf 100.127.0.1 auch noch ein 6in4-Gateway einzurichten und die Adressbereiche
2a00:61e0::-2a00:61e0:3fff:ffff:ffff:ffff:ffff:ffff
und
2a00:61e0:8000::-2a00:61e0:ffff:ffff:ffff:ffff:ffff:ffff
hätte fl!nk/GFD auch noch zur Verfügung, denn die werden sie für 6rd niemals brauchen.

Höchstens
2a00:61e0:168c::-2a00:61e0:168f:ffff:ffff:ffff:ffff:ffff
bräuchten sie noch, wenn sie auch für Kunden mit öffentlicher IPv4 (185.22.140.0-185.22.143.255) 6rd verwenden.

Das werden sie aber hoffentlich nicht tun (Wenn sie was taugen), denn schon der nächste Block von 1024 öffentlichen IPv4-Adressen (Größere Blöcke gibt's von der RIPE nicht mehr) könnte im Ergebnis mit dem CGN-Bereich kollidieren.

---

(03.10.2014, 16:06)Michi240281 schrieb:  EDIT: Hab mir jetzt auch mal die Einstellungen des Genexis exportiert. Ist ja recht übersichtlich.

Ja, irgendwie zu übersichtlich.

(03.10.2014, 16:06)Michi240281 schrieb:  Wenn ich mich dazu entschließe, mal probeweise den "tunnnel 1" mit einem "shutdown"-Befehl zu versehen, wie müsste ich denn im Falle, dass dann der Genexis kein 6rd Tunnel mehr aufbaut die Einstellungen in der FB ändern?

keinen ... "keinen 6rd-Tunnel mehr aufbaut".

Mein erster Versuch wäre definitiv:

Code:

6rd Prefix = 2a00:61e0:xxyy:zz00:: / 56
6rd prefix length = 56
6rd BR FQDN = 100.127.0.1
IPv4 mask length = 32

Wobei xx, yy und zz aus dem 2., 3. und 4. Teil der WAN-IPv4 (Wie im Genexis angezeigt) zu errechnen wären (Dezimal -> Hex).

(03.10.2014, 16:06)Michi240281 schrieb:  Und wenn man hier was ändert:

interface vlan1
!ip address dhcp
!ipv6 address auto

könnte man ja vllt dafür sorgen, dass sich der Genexis nicht mehr per DHCP ne IPv4 vom NEW Server holt, sondern immer die gleiche behält?!?

Falsches vlan.

Wenn überhaupt, dann

Code:

interface vlan320
ip address <IPv4 Adresse> <IPv4 Maske>

so wie derzeit unter Netzwerk -> Interfaces für das Interface WAN angezeigt, ohne die spitzen Klammern.

(03.10.2014, 16:06)Michi240281 schrieb:  Zumindest könnte man im Netz für noch mehr Verwirrung sorgen!!! ;-)

StGB §303a - Datenveränderung
StGB §303b - Computersabotage

Wenn ich sage, "man müßte", dann meine ich das im Sinne von "man müßte Kinderschändern die Eier abreißen".
Müßte man, darf man aber leider nicht.

[Michi240281]

Mist! Habe die cfg des Genexis geändert, aber nun meckert das Drecksteil beim erneuten Import! Er meldet: Ungültige Konfigurationsdatei! :-(

[Schimmelreiter]

(03.10.2014, 19:17)Michi240281 schrieb:  Mist! Habe die cfg des Genexis geändert, aber nun meckert das Drecksteil beim erneuten Import! Er meldet: Ungültige Konfigurationsdatei! :-(

Tjor, das
!hash
am Ende ist eine Prüfsumme ...

Es könnte eine md5sum sein.
Nein, könnte es nicht ...

----

Es sieht aus wie base64-encoded ...
Wenn man es dekodiert ist es für eine sha256 zu kurz und für eine md5 zu lang.

sha-1 haut hin ...
base64 encoded sha-1 könnte es sein ...

[Michi240281]

Hast n Programm um base64 checksummen zu berechnen? Habe mir gerade "JackSum" und "HashmyFiles" geladen, die beherrschen aber kein Base64....

[Schimmelreiter]

(03.10.2014, 19:42)Michi240281 schrieb:  Hast n Programm um base64 checksummen zu berechnen? Habe mir gerade "JackSum" und "HashmyFiles" geladen, die beherrschen aber kein Base64....

base64 ist kein Checksummenformat ...
base64 verwendet man normalerweise, um 8-Bit-ASCII oder UTF-8 über Transportwege zu transportieren, die nur bis 7-Bit-ASCII zuverlässig funktionieren ...

Ein besseres uuencode/uudecode also.

Zur Base64-Konvertierung gibbet genug Websites.

[Michi240281]

Hmmm ok! Verstehe!

Was muss ich denn da wählen bei der Konvertierung? UTF-8, ASCII, CP1256,.........?

Und vor allem welchen Inhalt der cfg konvertieren? Wenn ich den gesamten Inhalt nehme wird das viel zu lang.........

[Schimmelreiter]

(03.10.2014, 19:52)Michi240281 schrieb:  Hmmm ok! Verstehe!

Was muss ich denn da wählen bei der Konvertierung? UTF-8, ASCII, CP1256,.........?

Und vor allem welchen Inhalt der cfg konvertieren? Wenn ich den gesamten Inhalt nehme wird das viel zu lang.........

Wenn ich's Dir erklären muß, sind die Chancen gering, daß Du es hinkriegst ...

Zuerst brauchen wir die sha-1 der Config (excl. der alten Checksumme) und DIE wird dann base64 encodet.

Sowas verifiziert man aber an der unveränderten Config, denn da weiß man ja, was rauskommen muß ...