ich stehe derzeit ein wenig auf dem Schlauch und bräuchte mal nen Denkanstoß.
Ich bin dabei einen Hostserver mit Proxmox 6.1-5 unter Debian 10 auf einem Hetzner-Server für mehrere Gateways (für Multi-Domän) einzurichten. Ich habe von Hetzner eine IPv4 und nen IPv6/64 Subnet.
Testweise habe ich 2 vGateways (Debian10, batman, fastd, etc…) komplett eingerichtet.
Das funktioniert soweit auch einwandfrei. Ich kann mich mit einem Gluon-Node mit den vGW’s verbinden.
Clients bekommen dann nen IPv4 und IPv6.
Das v4-Netz ist per masquerading geNATet und nen Ping funktioniert einwandfrei.
Was aber nicht klappt ist nen Ping per IPv6. Also es geht gar kein Traffic per v6 raus…
Bisher verteile das v6 Subnetz einfach per radvd im Clientnetz.
Wenn ich einen Ping von einem Client mache, sehe ich den Ping per tcpdump auch über alle interfaces nach draußen gehen und bekomme auch eine Antwort am WAN des Proxmox, diese gibt aber zurück, das die Client-IPv6 nicht gefunden werden kann. Also ein Routing Problem?
Da stellt sich mir grundsätzlich die Frage, das v6 Netz auch per masquerading verstecken? Oder den vGW’s jeweils nen eigenes IPv6-Subnet für die Clients zuordnen?
Das klingt nach einem Routingproblem.
Da du radvd nutzt damit die Clients SLAAC machen brauchst du schon mal ein ganzes /64 dafür.
Hetzner teilt dir aber nur ein /64 zu. Das ist dafür gedacht auf deinem Hostsystem deine VMs mit IPv6 zu versorgen.
Da du das /64 nicht weiter aufteilen kannst, kannst du es nicht für Clients nutzen, die hinter einer VM hängen.
Entweder brauchst du also ein Subnetz, was größer ist als /64 oder du brauchst ein zweites /64 Subnetz. Als ich noch Hetzner-Kunde war (muss so 2013 gewesen sein) konnte man noch ein zweites Subnetz per Ticket anfragen.
Bei Hetzner sitzt das /64 des Servers bei mir auf br-vm, der Server routet ::/0 zu fe80::1%eth0 (Hetzner-IF), br-vm hat ebenfalls fe80::1/64 und das ist das Ziel für ::/0 in den VMs. Keine Ahnung, wie man das in Proxmox baut.
ABER: 1 /64 pro Mesh („Domäne“). Wenn Du ohne weitere (Hetzner-) v6-Netze mehrere Meshes abwickeln willst, wirst Du um NAT6 nicht umhinkommen.
Ich brauche entweder ein größeres Subnet oder ich muss das v6 genauso wie das v4 NATen.
Ich werde mal bei Hetzner anfragen ob die mir ein größeres Subnetz geben… ich denke mal nicht kostenlos
Wie macht Ihr das dann mit dem Multi-Domain. Auf einem Blech ist dann auch nur eine Domäne?
… welches Stand heute aber an den Server gebunden ist, sprich unerreichbar bei Serverreboot, -ausfall und -wechsel. Ein dynamisches Routing der /64 im /56 wäre wünschenswert.
Ernsthaft: bevor Du v6 NATtest (Prefix translation wäre noch halbwegs ok), laß’ es bitte ganz!
Ausreichend v6-Adressraum wird per Tunnel zugeführt.
ich habe schon mal 2 NAT gateways kaskadiert… für IPv6. Geht prinzipiell, sogar gut.
(ist halt, so, wenn man Upstream keine PD bekommt und dort nur ein /64 anliegt, man aber noch zwei Hops weiter möchte und im Transitnetz ebenfalls SLAAC braucht.)
Daß das nicht ginge, habe ich auch nicht behauptet; geil ist auch Prefix Translation, dann klappt selbst das rein-SSH-en Aber: IPv6 bietet genug Adressen, daß man mit Krücken wie NAT gar nicht anfangen sollte, die Fehler von IPv4 einzuschleppen. Notfalls ein /48 von Hurricane Electric reintunneln … (fast) alles ist besser als NAT.
Nicht ganz das, aber mit genügend Geld bekommt man bei Hetzner „dynamische“ IPv4 und IPv6 Subnetze. Nur man bezahlt dann halt beispielsweise für ein /64 10 € im Monat und dann nochmal 1,19 € für das TB Traffic. Nur für Ausfallsicherheit ist das schon ein stolzer Preis. Gerade das der Traffic halt keine Flatrate ist.
Ist die logische Konsequenz dann nicht, die Host-IPs für das externe Interfacing zu nutzen (Gateways, Tunnel zu $woanders) und das Mesh mit ›beweglichen‹ IPs zu versorgen, z. B. $woanders = FFRL?
Das ist vermutlich eine der wenigen günstigen Möglichkeiten die man hat. Aber man macht sich dann ohne eigene ›beweglichen‹ IPs ein gutes Stück abhängig vom FFRL.
Ein IPv6-PI-Netz (typischerweise ein /48 als kleinesten routebaren Prefix) kostet jährlich 50 EUR netto ans RIPE; wenn das eine deutsche LIR – als sog. Sponsoring LIR – einer deutschen natürlichen oder juristischen Person weiterberechnet, kommen da ggf. 20% niederländische und darauf 19% deutsche MwSt. obendrauf.
Tipp: tatsächlichen Adressbedarf zusammenstellen und PI in einem Rutsch (z. B. 2-4 /48 für 2 bis 4 Standorte (== RZen)) anfordern, und auf viel Diskussionsbedarf gefaßt sein, wenn man statt 4 x /48 ein /46 bekommen möchte.
Effektiv zahlt man nicht per /48, sondern pro Assignment (was 4 /48 oder ein /32 sein kann (für letzteres würde mich die akzeptierte Begründung interessieren ) die 50 EUR/Jahr.
Netzpolitischer Hinweis: PI-Adressraum ist von der Idee her an den Endnutzer zugewiesen; an sich darf diese Adressen also nur z. B. der Verein Freies Funken Niederelbe e. V. nutzen, konkret einzig dessen Mitglieder — nicht aber z. B. ein zu einer Besprechung anwesender Gast (dem hätte strenggenommen nur eine Adresse aus einem nicht-PIv6-Bereich, oder eben gar kein IPv6, gegeben werden dürfen).
Dank einer Initiative von @Barbarossa vor ein paar Jahren ist die Policy geändert worden, sodaß man mit PIv6-Adressraum per WLAN auch Außenstehenden einen Internetzugang ermöglichen darf.
Frage: bietet der FFRL sich eigentlich als Sponsoring LIR für Freifunk-Communities an?
Achtung, Voraussetzung für die Zuweisung einer AS-Nummer ist derzeit Multihoming, sprich: Euer AS-in-spe braucht >1 Upstream AS, deren Kontaktdaten im Antrag auch ans RIPE kommuniziert werden müssen (AFAIK aber von dort nicht weiter geprüft werden — wäre auch etwas zu viel des Guten, würde das RIPE NCC in Zeiten der DSGVO bei einem ISP anrufen und fragen, welche Vertragsbeziehungen bestehen …). Praktischerweise bieten sowohl Hurricane Electric als auch NetAssist neben IPv6-via-Tunnel auch IPv6-BGP-via-Tunnel an …
Ok, wie sieht der einfachste Weg zur eigenen ASN mit eigenem IPv6-PI-Adressraum also aus?
Wir definieren die Anzahl der Rechenzentren/auf Netzebene disjunkten Orte, an denen wir Server mieten [1/2/3/4/…] oder aufstellen (wegen Community-IX) wollen.
Wir haben uns eine Sponsoring LIR gesucht, zum Beispiel einen befreundeten ISP oder eines der AngeboteamMarkt, um eine AS-Nummer und unsere PIv6-Netze zu beantragen.
Wir holen uns v6-Tunnel von Hurricane Electric und NetAssist, geben deren Kontaktdaten für die Multihoming-Anforderung des RIPE NCCs an, schicken alle Daten für PIv6 und ASN an unsere Sponsoring LIR.
Am Ende des Prozesses haben wir eine zugewiesene AS-Nummer (wie FFRL, FFNW, 4830.org und andere), ein oder mehrere (v6-) Netze — und ein Verständnis, daß jetzt die Arbeit erst losgeht (hinting @collimas)
Denn nun muß man sehen, wie man seine Netze tatsächlich geroutet bekommt, natürliche Anlaufstelle wäre für mich der FFRL (auch wenn wir es in Eigenregie realisiert haben) und/oder andere Freifunk-Organisationen (wichtiger Baustein ist auch der Community-IX).
Kurzum: man kann sich einer anderen Organisation hingeben, man kann aber auch komplett sein eigenes Ding fahren oder eine Kombination davon — die Kosten pro Monat oder Jahr sind nicht exorbitant hoch.
Danke für deinen Text.
Wir hatten da vor 1-2 auch mal ein Dokument angefangen, das noch etwas ausführlicher sein sollte, aber z.B. Tunnel bisher nicht erwähnt. Vielleicht willst du ja daran weiterschreiben, damit es vielleicht veröffentlichungsfähig wird? Ich wäre nur Nutznießer der Informationen, noch machen wir soetwas nicht selbst.
Sehe ich es richtig, dass dein Text zwei Varianten vorsieht? Entweder Hardware und routing per FFRL/*IX/… oder Mietserver und tunnel von HE und netassist?
Ist dir aufgefallen, dass netassist.ua ein SSL-Cert hat das vor 8 Tagen abgelaufen ist?
Hast du langjährige Erfahrung mit deren Verlässlichkeit?
Wir sind mit Tunnelbroker ohne BGP an sich seit 2015 sehr zufrieden, jedoch weiß ich da keine gute Möglichkeit, um es redundant aufzubauen (hinsichtlich Serverausfall auf unserer Seite).
Andererseits fahren wir seit 2015 ohne jegliche Redundanzen und haben höhere Availability-Messwerte als jeder Consumer-ISP
Hallo,
es freut mich, dass ich mit meiner Frage eine Diskussion hin zu einem eigenen Freifunk v6-Subnetz wiederbelebt habe. Dies wäre für uns in der Zukunft sicherlich auch ein interessantes Thema.
Das obige Problem haben wir nun erstmal mit den /56 Subnetz von Hetzner einfach lösen können.
Dem schließt sich nun aber ein weiteres Problem an die ich mit meinen rudimentären IPv6 Kenntnisse leider nicht gelöst bekomme.
Wir haben jetzt 2 Blech-Server mit jeweils einem eigenem /56 Subnetz. Auf diesem diverse Gateways-VMs, welche entsprechend ein /64 Teilnetz bekommen und verteilen. Nun ist es so, das Beispielsweise auf beiden Servern je ein Gateway der gleichen Domäne, also des gleichen Client-Netz liegen. Die beiden Gateways verteilen per radvd ihr eigenes /64 Subnetz und die Clients genieren entsprechend für jedes Netz jeweils eine IPv6.
Jetzt kommt es vor, dass ein Client mit einer IP von GW1 (der FF-Router ist verbunden über GW1) seine Daten über GW2 schickt. Das funktioniert natürlich nicht.
Was kann ich machen, damit ein Client entsprechend seiner IP das richtige Gateway wählt?
Das ist das „alte“ Quertraffic-Problem und schlägt bei allen Batmannetzen mit mehreren Supernodes (und Gateways) zu.
Will sagen: Es ist leider kein spezielles Hetzner-Problem.
Schau mal nach den diversen Quertraffic-Threads.
(Und ja, es behaupten Menschen, dass das nicht wirkllich ein Problem ist, da Batman…)
Das es kein spezielles Hetzner-Problem ist, ist mit bewusst.
Ich denke aber, dass das auch kein Batman-Quertraffic Problem in dem Sinne ist, sondern ehr ein IPv6.
Freifunk/Batman mit mehreren Gateways ist im IPv6-Sinn ja ein Multihoming-Umgebung. D.H. es gibt mehrere Router mit unterschiedlichen Präfixen welche diese per SLAAC an die Hosts verteilen.
Das gibt es ja nicht nur in Freifunk/Batman-Netzen. Für IPv4-DHCP hat Batman dies ja elegant gelöst, in dem DHCP-Anfragen an die anderen Gateways blockiert.
Nur, was kann ich mit IPv6 machen? So wie es jetzt ist, ist es ein Glücksspiel, ob ich per IPv6 raus komme oder nicht. Eigentlich sucht sich ja in Multihoming-Umgebungen der Client das Gateway anhand von Qualitätsmerkmalen. Ist es z.B. eine Lösung, wenn man an einem Gateway nur Traffic von Adressen des eigenen Präfix forwarded und den Rest wegkippt?
Aber: IPv6 bietet genug Adressen, daß man mit Krücken wie NAT gar nicht anfangen sollte, die Fehler von IPv4 einzuschleppen. Notfalls ein /48 von Hurricane Electric reintunneln … (fast) alles ist besser als NAT.
) die 50 EUR/Jahr.
