Follow

Mal eine dumme Frage:
Kann ich mit nur einem /64 IPv6 Adressraum mehrere lokale Netze betreiben, die voneinander abschotten und denen gleichzeitig eine Verbindung ins Internet erlauben?

Beispiel
- pfsense
- zwei Netze
NetzA = "Internet of shit"-Geräte
NetzB = alles andere
- ein /64 ipv6-Adressraum 2a01:4f8:200:710e:0:0:0:0/64

Regeln
- niemand darf Verbindungen aus dem Internet in lokale Netze machen
- alle dürfen Verbindungen ins Internet machen
- NetzB darf Verbindungen nach NetzA machen

@mk
Kenne mich leider nicht mit IPv6 aus, aber wäre VLAN da nicht eine Lösungsoption?

@cinux

naja es geht mit um das logische routen von ip verbindungen...nehmen wir einfach mal an beide netze sind schon physikalisch voneinander getrennt.

pfsense hat drei interfaces
- internet
- netzA
- netzB

-> wie richtige ich ipv6 ein

@mk
Mhh.. mir erschließt es sich nicht wieso du zwingend ein Netzwerk über NetzA und NetzB haben willst. Ich würde das trennen.
Spontan würde ich jetzt zu einer Bridge raten. Aber ich wüsste nicht wie du verhindern willst das NetzA eine Verbindung zu NetzB aufbaut. Dazu müsstest du wissen welche Geräte zu NetzA und welche zu NetzB gehören. Wenn aber beide das selbe Netz nutzen (selber DHCP) wird das schwer ohne static leases.
Leider kann ich mangels ipv6 erfahrungen nicht viel helfen. :-( sorry

@mk
Sollte mit VLAN`s machbar sein?
Zumindest geht das meines Wissens mit diversen Switche die das unterstützen oder zum Bleistift auch mit einer IPFire.
@mk TLDR: Jein - bei OPNsense kann man kleinere Netze als /64 (also z.B. ein /80) im UI konfigurieren und nutzen, somit klappt das bei pfsense sicher auch - evtl. zickt das pfsense UI bei gewissen services, aber notfalls konfigurierst Du das im XML oder direkt in den entsprechenden /etc Dateien per ssh.

Das "Problem" ist, dass kleinere subnetze Netze als /64 eigentlich nicht im Standard vorgesehen sind. Man soll den Endkunden ein /48 routen und diese können dann die nächsten 16 Bit für das Subnetting nutzen (also maximal 65535 Subnetze - in der Regel weniger da hierarchisch gegliedert). Technisch ist es aber kein Problem und IPv6-stacks sowohl von Linux, BSD (inkl. MacOS) und Windows lassen solche Konfigurationen zu. Ich hatte allerdings hin und wieder Probleme, dass gewisse Admin-Skripte oder -Werkzeuge keine Subnetz-Grössen kleiner als /64 akzeptieren, da diese eben nicht Standard-Konform sind - man muss das dann Händisch in den entsprechenden Konfigurations-Dateien eintragen.

Ich selbst nutze diese kleineren Subnetze auf einigen Docker-Hosts um Services direkt aus dem IPv6-Internet zugänglich zu machen. Diese Hosts sind selbst in einem normalen /64 Subnetz angesiedelt und kriegen ein /79 Subnetz daraus geroutet (von einem OPNsense Router), dieses wird von Docker in /80 Netze aufgeteilt, eines als internes standard-IPv6 Zwischennetz, wenn nichts anderes im Container angegeben wird (so wie bei IPv4) und die anderen werden verwendet wenn ich explizit ein IPv6 Subnetz von Docker verlange. Die Services welche extern erreichbar sein sollen werden in ein solches IPv6 Subnetz und (per docker proxy) an die externe IPv4 exposed.

Problem bei dieser Konfiguration: Diese /79 Subnetze können standardmässig nur von aussen erreicht werden - Andere Docker-Hosts im gleichen /64 wollen Pakete an dieses Netz direkt zustellen und leiten diese nicht an den default gateway weiter. Falls nötig muss man somit manuelle gateways für alle diese Netze auf allen Hosts konfigurieren (das habe ich auf meinem monitoring Host gemacht). Eleganter wäre es, wenn ich, wie vom Standard vorgesehen, alle diese Hosts in unabhängige Netze platziere und somit alles automatisch via default gateway abgewickelt werden würde. Das würde allerdings zusätzlichen Traffic für diesen Router bedeuten (und zusätzliche VLANs, Paketfilter-Regeln, etc.), würde dann aber auch die Sicherheit erhöhen, da ich die Zugriffe von einem Host zum anderen feiner Kontrollieren kann.

Die /etc/docker/daemon.json sieht z.B. so aus:

{ "userns-remap": "default", "ipv6": true, "fixed-cidr-v6": "[subnetz hier]::/80", "log-driver": "syslog", "log-opts": { "syslog-address": "unixgram:///dev/log" } }



Und die ansible tasks zum Anlegen des Subnetzes und eines nginx containers auf diesem Host sieht so aus:

- name: create IPv6 network docker_network: name: ipv6 enable_ipv6: yes ipam_config: - subnet: "{{ docker_nginx_ipv6_prefix }}/80" - name: nginx container docker_container: name: nginx image: nginx:1.20.1-alpine pull: yes state: started restart_policy: always privileged: no read_only: yes init: yes networks_cli_compatible: no networks: - name: ipv6 ipv6_address: "{{ docker_nginx_ipv6_address }}" [hier weitere interne Netze, an denen die verschiedenen web apps lauschen] ports: - 80:80 - 443:443 env: TZ: "{{ docker_timezone }}" tmpfs: - /run volumes: - /srv/nginx/cache:/var/cache/nginx:rw - /srv/nginx/conf.d:/etc/nginx/conf.d:ro - /srv/nginx-certbot/certificates:/etc/letsencrypt:ro - /srv/www:/srv/www:ro tags: docker-nginx

@elrido

"alle diese Hosts in unabhängige Netze platziere und somit alles automatisch via default gateway abgewickelt werden würde. Das würde allerdings zusätzlichen Traffic für diesen Router bedeuten (und zusätzliche VLANs, Paketfilter-Regeln, etc.), würde dann aber auch die Sicherheit erhöhen, da ich die Zugriffe von einem Host zum anderen feiner Kontrollieren kann."

Ich will einen Punkt haben an dem ich Filterregeln definiere..alles andere ist Augenwischerei und gefährlich.

@elrido

Quick and Dirty howto 1/4

NetzA == internet of shit Netzwerk == WindowsNetzwerk

---
Adressraum, der zu mir geroutet wird: 2a01:4f8:200:710e:0:0:0:0 /64
---
1. Adressraum in kleinere Stücke zerhacken und via static-ipv6 an die Interfaces verteilen
WAN: 2a01:4f8:200:710e:0:0:0:254 /112
NetzA: 2a01:4f8:200:710e:0:0:1:254 /112
NetzB: 2a01:4f8:200:710e:0:0:2:254 /112

@cinux
@kranfahrer

@elrido

Quick and Dirty howto 2/4

2. DHCPv6 Server auf den lokalen Interfaces aktivieren (nicht auf WAN)
- Adresspool und DNS-Server (pfsense IPv6 Adresse) einstellen

@cinux @kranfahrer

@elrido

Quick and Dirty howto 3/4

3. Im DNS Resolver IPv6 Link-Local Verbindungen erlauben

@cinux @kranfahrer

@elrido

Quick and Dirty howto 4/4

4. Firewall

NetzA
- Alias mit lokalen Netzen anlegen
- Firewall-Regel: Alle Verbindungen erlauben ausser denen, die als Ziel die Netze im Alias haben ("invert match" gegen den alias)
- Firewall-Regel: lokales Netz darf mit pfsense sprechen (für z.B. DNS)

NetzB
- Firewall-Regel: Verbindungen überallhin erlauben (Destination "any" anstatt "invert match")

@cinux @kranfahrer

@cinux @kranfahrer @mk DHCPv6 ist nur nötig wenn die standardmässigen Router-Advertisements nicht ausreichen (z.B. für persistente IPs basierend auf der MAC-Adresse) oder diese bewusst ausgeschaltet hat.
@mk Ok, also ist ein Subnetz pro host plus eines für Docker die Konfiguration die Du Dir wünscht.

In meinem Fall habe ich nur Paketfilterregeln zwischen Extern und der DMZ in der alle diese VMs sind, aber nichts was die VMs daran hindert untereinander zu kommunizieren.

@mk

Um das vollständig zu separieren brauchst du separate IPv6 Netze. Dabei kommt es darauf an, wo dein Netzbereich (dein "Prefix") herkommt. Hast du z.B. einen Router davor stehen, der den Prefix im lokalen Netz bekanntmacht, dann kannst du auf der pfsense Prefix Delegation (PD) aktivieren. Bei einem statischen Prefix kannst du natürlich routen, wie du magst.

Ansonsten solltest du dein Io* Netz auch per VLAN und wahrscheinlich auch mit eigenem WLAN (SSID) separieren.

@buzztee

ich hab das so gelöst 🙂
mastodon.satoshishop.de/@mk/10

der ipv6 adressraum kommt von nem router bei hetzner...das ist dann wohl "statisch" ^^

@mk
Ja, aber ohne SLAAC. Du musst das 64 in 2 kleinere schneiden.
Die erste Regel ist bei pfsense sowieso gegeben. Die beiden anderen regeln sind abbildbar.
Die beiden Netze müssen natürlich, wie @tux schon erwähnte, getrennt werden.

@alex

hmm nen /64 kleiner schneiden ist irgendwie scheiße..hetzner soll mit gefälligst nen /56 geben xD

@tux

@mk
Aber hey nur einmalig. Also vermutlich einrichtungsgebühr.
@buzztee @tux @elrido

@alex

Käufer: Hallo..ich hätte gerne 1 Auto

Verkäufer: No problema, Amigo.. Hier hast du 1 Auto

Käufer: Ey, aber das hat nur drei Reifen

Verkäufer: Isse keine Probleme, Senior..Hier hassu vierte Reifen..Reifen koste nix, mussu nur bezahle 17,85€ für Montage durch Techniker.

@buzztee @tux @elrido

@alex

Wenn wir uns darauf einigen wollen, dass IPv6 Netze immer /64 sind, dann gehört dazu, dass man einen IPv6 Raum bekommt, der größer ist, damit man Netze definieren kann.

Ich kann mich noch daran erinnern, dass Internet-Endkunden /48 Netze bekommen haben...

@buzztee @tux @elrido

@mk
Naja du hast bei hetzner ja einen Server, da sehe ich aus Betreiber Sicht nicht unbedingt die Notwendigkeit dir so einen großen Adressraum zur Verfügung zu stellen. Selbst wenn man da virtuelle Maschinen drauf laufen lässt gibt man denen halt eine statische IP.
Und man hat ja ne Menge Adressen bei einem /64 für eine statische Zuordnung zur Verfügung.

Und wie gesagt brauchst du ein größeres Netz auch nur bei SLAAC, wenn du dhcpv6 einsetzt kannste auch das /64 nutzen.
@buzztee @tux @elrido

@alex

"Naja du hast bei hetzner ja einen Server, da sehe ich aus Betreiber Sicht nicht unbedingt die Notwendigkeit dir so einen großen Adressraum zur Verfügung zu stellen[...]Und man hat ja ne Menge Adressen bei einem /64 für eine statische Zuordnung zur Verfügung."

Ich habe bei denen einen rootserver auf dem ich zwei komplett abgekapselte Infrastrukturen betreibe.

mariokuschel.info und satoshishop.de haben jeweils eine eigene pfsense, eigene netze und server.

@buzztee @tux @elrido

@alex

Wie dieses "software defined netzwork/infrastructure" funktioniert, hab ich hier mal erklärt.

Migration einer kompletten IT-Umgebung in weniger als 10min von einem Standort zu einem anderen - kurze Version
peertube.satoshishop.de/w/1q5f

Migration einer kompletten IT-Umgebung von einem Standort zu einem anderen - lange Version
peertube.satoshishop.de/w/7BfV

Sorry für das schlechte Audio. Ich habe im Moment keine Zeit das zu fixen.

@buzztee @tux @elrido

@alex

"Selbst wenn man da virtuelle Maschinen drauf laufen lässt gibt man denen halt eine statische IP."

Das thema mit den "global ipv6 netzen" hat sich für mich eh erledigt,weil ich nicht unnötig viele externe abhängigkeiten in meiner infrastruktur haben will.

ich experimentiere derzeit mit internen Unique Local IPv6 Unicast Addresses und ipv6-NAT.

wenn ich die infrastruktur zu nem anderen hoster migriere, muss ich nur die eine öffentliche ipv6 adresse anfassen.

@buzztee @tux @elrido

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!