IPv6: Server und VMs

[schorsch_76]

Hallo,
seit etlicher Zeit nutze ich auf meinem Server VMs mit IPv4 um die Dienste zu trennen. Das Setup sieht so aus:

Code: Alles auswählen

   +-------+                +-------+                 +--------+
   |       |                |       |        Subnet 2 |        |
   | INet  |---> eth0------>| host  |------> br0+---->| vm1    |
   +-------+                |       |           |     +--------+
                            |       |           |
                            |       |           |     +--------+
                            |       |           |     |        |
   +-------+                |       |           +---->| vm2    |
   |       |                |       |           |     +--------+
   |       |     Subnet 1   |       |           |
   | VPN   +---->tap0------>|       |           |     +--------+
   |       |                |       |           |     |        |
   +-------+                |       |           +---->| vm3    |
                            +-------+                 +--------+ 

Aktueller Zustand:

• IPv4 only
• shorewall
• VPN kann auf alle Netze zugreifen
• INet wird per DNat auf die richtige VM weitergeleitet.
• Nur 2 VMs bieten Dienste die von der public IP zugänglich sein sind.
• DNS Eintrag ist nur auf die IPv4 Adresse. Kein AAAA Eintrag
• Subnetze Klasse C

Mein geplantes Setup:

• IP v4 + IP v6
• shorewall
• VPN kann auf alle Netze zugreifen
• INet wird per DNat auf die richtige VM weitergeleitet.
• Nur 2 VMs bieten Dienste die von der public IP zugänglich sein sind.

Von Hetzner habe ich eine IPv6 Adresse mit einem /64 Prefix. radvd kann nur ein /64 Prefix weitergeben. Da die mein public prefix schon /64 ist, kann ich radvd nicht auf dem internen br0 laufen lassen. Es ist ja schon eine Adresse auf meinem eth0 Interface. Oder geht das doch?

Ich hab mir schon ein Ipv6 Buch ("IPv6 Grundlagen - Funktionalität") gekauft. Hier werden aber mehr die Datenstrukturen erklärt, nicht wie man das ganze konfiguriert.

Habt ihr ein Buch/Link/Ratschlag für "Best practices mit IP v6"?

Wie würdet ihr das machen?

• Der Host soll dann mit shorewall6 die eingehenden Verbindungen außer Port x/y blocken?
• Wie die DNS (AAAA) Einträge setzen? Jede VM ihre eigene v6 IP in meinem Subnetz. Statisch?
• openvpn durch IPSec und strongswan ersetzen?
• VPN auf ipv4 lassen?
• ULA auf dem Internen + VPN netz? Wie geht das dann mit dem Internetzugriff? ULAs gehen ja nicht ins Internet ...

Fragen über Fragen ....

[TomL]

Ich finds ja echt faszinierend, was alles möglich ist und was man mit Linux alles bewerkstelligen kann. Und im Moment habe ich ganz ähnliche Probleme, denn seit letzten Freitag habe ich auch IPv4 und IPv6. Deshalb ich beschäftige mich auch gerade mit allen Problemen, die IPv6 so mit sich bringt.

Wie würdet ihr das machen?

Ganz anders! Nee, quatsch, natürlich nicht einfach nur anders, um anders zu sein. Aber ich frage mich die ganze Zeit schon, warum Du das so kompliziert löst, welche Vorteile das für Dich hat und ob sowas auch Vorteile für mich hätte...? Mir sind 2 Dinge aufgefallen, deren Sinn ich momentan nicht so richtig nachvollziehen kann:

Als erstes mal "Shorewall". Wozu braucht man das? Mit 3-4 in den iptables eingetragenen Regeln kann ich auf dem Server jeglichen Traffic unterbinden. Alles ist verboten! Das heisst, auch auf den VM kommt definitiv nix an. Dann öffnen ein paar weitere Regeln den LAN-internen Traffic. An diesem Punkt angekommen wäres es m.M.n. egal, ob Dienste in einer VM oder direkt im Host laufen - außer LAN wird eh alles DROP't. Danach fehlen noch ein paar ACCEPTS für explizite Ports und beim Output für established connects, damit die Dienste laufen. Meine Frage ist: welchen Vorteil hat shorewall gegenüber den manuell konfigurierten IPtables? Weil ich bei sowas eher misstrauisch bin und gerne auch die Zusammenhänge verstehen möchte, versuche ich stattdessen mit tcpdump und dem jeweiligen Dienst den Unterschied von Mit oder Ohne Regel zu bestätigen.

Und als nächstes die VMs. Ich installiere meinen Server lieber nach der Prämisse "nur das, was unbedingt für meine Anforderungen notwendig ist!". Und den Sinn von VM's auf einem Server, der (davon gehe ich im Moment aus) nicht der Öffentlichkeit zugänglich ist, sondern nur privat nutzbare Ressourcen zur Verfügung stellt, erkenne ich gerade mal nicht. Ich kenne im Moment nur VirtualBOX, welches auf einigen meiner PC im Desktop-Environment läuft. Ist das bei Dir anders? Denn bei meinen Anforderungen stellt sich die Frage, welchen Sinn hat es, auf einem Server ein DE zu installieren, damit OpenVPN in einer VM laufen kann? Warum muss OpenVPN überhaupt in einer VM laufen, wenn doch sowieso wieder ins LAN geroutet wird?

Ich frage mich beim Lesen Deines Modells, ob "zu kompliziert" letztendlich doch nur wieder Exploits generiert und ob die "Macht" nicht eher in kompromissloser Einfachheit besteht, die effektiv das tut, was getan werden muss. Fakt ist, NAT gibts unter IPv6 nicht mehr. Ob es Sinn hat, einem Client den direkten Connect ins Web zu verbieten, weiss ich im Moment noch nicht. Zur Zeit möchte ich NAT noch eher vermeiden und stattdessen lieber die Clients so ausrüsten, dass sie mit den Meteoriteneinschlägen aus dem WWW klarkommen, ohne zu explodieren. Im Moment mach ich mir also mehr Gedanken darüber, wie zuverlässig die Privacy Extensions laufen, wie die imho derzeit völlig unklare Implementierung in Debian Jessie tatsächlich aussieht und ich versuche gerade herauszufinden, welche Rolle mein Router überhaupt noch als Firewall bei einer End-to-End-Verbindung ins Internet spielt.

"wanne" (von dem ich mir jetzt mal wünschen würde, dass er mal aus dem Quark kommt und wach wird ) hat vor einiger Zeit einen für mich bemerkenswerten Satz gesagt, sinngemäß "Sicherheit fängt nicht mit der Installation irgendwelcher Tools an, sondern damit, auf unnötiges zu verzichten". Das ist für mich ein Leitspruch in meinem Netz geworden. Ich habe an anderer Stelle hier im Forum ein Problem mit den PE, und ich glaube, er wird das alles wissen.... vielleicht hilft er ja mal.....

[schorsch_76]

Auf dem Server laufen die VMs in qemu bzw libvirt-bin. Die VMs haben keine DE. Das ist klar. VM != Desktop

OpenVPN läuft auch auf dem Host da es Netzwerk Technik ist.

Vorteile:

• Apache, postfix, LDAP und postgres zu trennen. LDAP ist bsp nur über VPN zugänglich. Auch meine VMs haben nur das was wirklich für sie nötig ist.
• Host und VMs lassen sich nacheinander Upgraden (dist-upgrade). Beispiele: Postfix Syntax, Apache 2.2 auf 2.4 ...

Warum so kompliziert? Das ganze Netz wird mit einer IPTables Tabelle gemanagt. Es ist sicher, das ein Paket aus dem Netz, das nicht per DNAT auf seine VM kommt, als "nicht gematched" verworfen wird. Der Dienst ist lieber nicht erreichbar, als das er erreichbar ist und ich das aber nicht beabsichtigt habe. Explizite Erlaubnis bzw. DNAT

Auch das debianforum läuft in einer Vm. Hab ich hier irgendwann mal gelesen

Shorewall ist auch nur iptables mit policies. Es ist nur ein Parser der die Tabelle nach IP Tables Befehle umsetzt. Die Tabelle ist viel einfacher und übersichlticher als ein iptables Skript

https://linux.die.net/man/5/shorewall-rules

Code: Alles auswählen

Example 1: 
Accept SMTP requests from the DMZ to the internet          #ACTION SOURCE  DEST PROTO      DEST    SOURCE  ORIGINAL
         #                               PORT    PORT(S) DEST
         ACCEPT  dmz     net       tcp   smtp

Am Ende werkelt auch der Kernel mit seinen iptables.

[schorsch_76]

Ich habe mir jetzt "IPV6 - Workshop" als eBuch gekauft und durchgelesen. Jetzt ist vieles so viel klarer.

Ich werde mir jetzt erst mal zuhause ein paar TestVMs installieren und dort die gelesenen Sachen ausprobieren.

• Intern wird dann alles unter ipv6 laufen.
• Mit nat64 und nat46 wird die Kommunikation mit v4 ablaufen.
• Alte Sachen die kein v6 können, kommen in ein eigenes Subnetz das dann über nat64 bzw nat46 angebunden wird.
• Intern wird es mit ULA ein privates Netz geben das ähnlich der privaten IPs unter v4 sind.
• Knackpunkt sind auf einem Interface können mehrere IPs sein. ULA und Global Scope.
• Auf der Firewall wird dann nur bsp. Port 80 für ip 2003:xxxx durchgelassen. Der DNS Eintrag lautet dann eben exakt auf den Webserver in meinem Subnetz.
• Mail ist dann genauso. Der DNS Eintrag lautet dann auf diese V6 Adresse. Momentan sind unter v4 alle auf der Haupt IP und intern dann per DNAT weitergeleitet.
• Per DNS Proxy kann dann auch unter dem v6 Netz auf reine V4 Ziele zugegriffen werden. bind9 oder totd (Trick or Trait daemon) mitunbound

Ich melde mich wieder

[1] http://lostintransit.se/2014/08/26/a-qu ... and-nat46/

[schorsch_76]

Am Wochenende hab ich jetzt am Laptop etwas gespielt mit Test VMs. Das Setup sieht wie oben aus, nur ohne VPN. Internet ist am Testsetup an wlan0. Auch die public global ipv6 ist ein /64 Subnetz.

Mit radvd und ULA Adressen kann man mit einem /64 Prefix arbeiten.

Code: Alles auswählen

auto eth0
allow-hotplug eth0
iface eth0 inet manual
   pre-up   ifconfig eth0 up
   pre-down ifconfig eth0 down

iface eth0 inet6 manual

auto br0
iface br0 inet static
        address 192.168.11.1
        netmask 255.255.255.0
        bridge_stp on
        bridge_fd 2.5
        bridge_maxwait 2
        bridge_ports eth0
        up      echo 0 > /sys/devices/virtual/net/$IFACE/bridge/multicast_snooping

iface br0 inet6 static
        address 2001:DB8:1::1
        netmask 48
        up      ip6tables -t nat -A POSTROUTING -o wlan0 -s 2001:DB8:1::/48 -j MASQUERADE

Mit radvd gebe ich ein /64 Präfix aus meinem ULA an br0 bekannt.

Code: Alles auswählen

interface br0
{
        AdvSendAdvert on;
        MinRtrAdvInterval 30;
        MaxRtrAdvInterval 100;
        AdvLinkMTU 1280;

        prefix 2001:DB8:1:1::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on; 
        };
};

Das ULA Präfix hab ich so erzeugt:

Code: Alles auswählen

dd if=/dev/urandom bs=1k count=1 | sha256sum | cut -b1-10

Davor noch ein fd.

Man benötigt ausserdem das ipv6 forwarding Flag auf 1
sysctl.conf

Code: Alles auswählen

net.ipv6.conf.all.forwarding=1

Ja, Ich setze hier NAT ein um das ULA Präfix zu ersetzen gegen mein globales Präfix an wlan0. Das NAT hier läuft anderst als unter v4
Siehe [1]

Das hier ist das einfachste Setup um mit einem /64 Netz aus einem anderen Subnetz ins Internet zu kommen.

[1] http://mirrors.bieringer.de/Linux+IPv6- ... ter6..html

Edit: Typo

[wanne]

So was ich anders machen würde:
Nicht ULAs sondern dein IPv6 Netz+DHCPv6 oder Statische IPs nehmen. (Hat den Vorteil, dass jeder Rechner von außen und innen gleich heißt und jeden Port nutzen kann.

Statt NAT folgende Regeln auf den Clienten (Beispiel für einen HTTP-Server):

Code: Alles auswählen

iptables -P INPUT DROP
iptables -A INPUT -p tcp -m tcp --syn -dport 80 ACCEPT #Dein Server
iptables -A INPUT -p tcp -m tcp --syn -dport 443 ACCEPT 
iptables -A OUTPUT -d mirror.hetzner.de -p tcp -m tcp --syn --dport 80 ACCEPT #updates
iptables -A OUTPUT -d  httpredir.debian.org -p tcp -m tcp --syn --dport 80 ACCEPT #security-updates
iptables -A INPUT -p tcp -m tcp --syn -j REJECT # Weitestgehend NAT
iptables -A OUTPUT -p tcp -m tcp --syn -j REJECT # Ausgehende Verbindungen wie NAT
iptables -A INPUT -p tcp -j ACCEPT
iptables -A OUTPUT -p tcp -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT

Das ist deutlich Härter als jedes NAT, weil es kein Holepunching oder Kommunikation abseits der entsprechenden Serverports erlaubt und lässt sich dann aber auf beliebige andere Protokolle abseits von TCP erweitern.
Und nebenbei ist es um längen effizienter. Wobei die frage ist, ob du Bandbrieten hast, bei denen du da was merkst.

[TomL]

Moin æ all

Seit (ungelogen) einer halben Stunde starre ich jetzt auf die Regeln und versuche zu verstehen, wie und warum das funktioniert und was überhaupt gemeint ist. Es fängt schon mit der Überschrift an, wo ich über deren Bedeutung rätselrate. Bedeutet das, diese Regeln sind für den HTTP-Server und ersetzen die von Schorsch gedachten NAT-Regeln auf den Clients? Ich tue mich insbesondere im Zusammenhang mit diesen Regeln gerade auch total schwer mit schorsch's Vorsatz trotz IPv6 wieder auf NAT zurückzugreifen. IPv6 macht doch NAT überflüssig... wieso sollte man freiwillig daran festhalten wollen? Irgendwie krieg ich das alles nicht mehr auf die Reihe....

Aber natürlich interessieren mich ganz besonders die Regeln... und ich hoffe, jemand hilft mir beim verstehen.

Die erste Zeile ist einfach. Mit dem Policy-Drop wird nur der Default-Weg aller Pakete festgelegt, für die es keine Ausnahme (Accept, Reject) in den folgenden Regeln gibt.

Dann folgen 4 Zeilen (2 Input, 2 Output) wo mich das Synflag irritiert. Entspricht "--syn" im übertragenen Sinne einem "-m conntrack --ctstate NEW"? Wenn dem so wäre, bedeutet das, dass "NEW" für eingehenden Verbindungen nur auf den Ports 443/80 erlaubt ist, und das auf den gleichen Ports NEW für ausgehenden Verbindungen nur mit den beiden Domains als Dest erlaubt ist? Alle anderen NEW-Connects werden in den nächsten beiden Zeilen REJECT'ed....? Dabei irritiert mich der Comment "NAT" ... wieso "NAT" ...?... da ist doch alles abgefackelt, was in dieser Regel ankommt. Und wenn diese Regel match't, dann gilt halt der REJECT, aber nicht nur für NAT.

Die nächsten 4 ACCEPTS sehe ich wieder im gleichen Zusammenhang mit dem Conntrack-State. Weil NEW oberhalb konkret behandelt wurde, betreffen diese 4 Zeilen eigentlich nur established und related Connects... auch wenn das nicht explizit angegeben wurde. Stimmt diese Interpretation?

Und auch die letzten beiden Zeilen sind mir noch unverständlich... da wundert mich, dass die keinen Limiter enthalten, z.B. 5 Pings/s erlauben und dann DROP'n. Braucht man sowas gar nicht?

Als letztes bereitet mir noch das Holepunching kopfzerbrechen. Ist das auch möglich, wenn auf dem Server gar keine Anwendung auf irgendeinem Port "lauscht", die z.B. eine P2P-Verbindung etablieren kann? Dieser Gedanke würde mir beispielweise Kopfschmerzen bereiten, wenn ich auf der Maschine das JDL-Web-Interface oder Teamviewer nutzen würde. Aber sonst...?... oder muss man sich immer darüber Gedanken machen?

Kann bitte jemand beim Übersetzen helfen?

[wanne]

@TomL: Du hast die regeln eigentlich vollständig richtig interpretiert.

IPv6 macht doch NAT überflüssig... wieso sollte man freiwillig daran festhalten wollen?

schorsch_76 wollte ein volles /64 für seine VMs Hat von Hetzner aber nur ein /64 bekommen. Entsprechend hat er wieder Adressmangel und macht NAT.

Entspricht "--syn" im übertragenen Sinne einem "-m conntrack --ctstate NEW"?

Ja. aber eben nur für TCP. Nicht für UDP, ICMP oder SCTP. Deswegen ist es auch um Längen schneller. Meine Regel ist einfach nur ein Matching von ein paar Bits. Conntrack arbeitet mit großen Tabellen.

Dabei irritiert mich der Comment "NAT" ... wieso "NAT" ...?

Es war eben als Alternative zu der NAT basierten lösung von schorsch_76 gedacht. Deswegen der Vergleich.

Weil NEW oberhalb konkret behandelt wurde, betreffen diese 4 Zeilen eigentlich nur established und related Connects... auch wenn das nicht explizit angegeben wurde.

related wären (z.B. Bei FTP) vor allem neue TCP Verbindungen entsprechend fallen die in die --syn Regeln. Oder für MTU Discovery oder Rejects ICMP Pakete, die späte kommen. Etsprechend betrifft das nur established.

Und auch die letzten beiden Zeilen sind mir noch unverständlich...

ICMP erfüllt weit mehr Funktionen als nur Ping. Wärend Type 1 (Für falsche adressen), 2(MTU Discovery) noch nur für die Performance wichtig sind. Sind in IPv6 mit NDP und dem ganzen Multicast zeug auch noch wirklich essentielle Aufgaben in ICMP gewandert.

da wundert mich, dass die keinen Limiter enthalten, z.B. 5 Pings/s erlauben und dann DROP'n. Braucht man sowas gar nicht?

Ich habe es meistens drin, wenn ich eh schon ne Firewall aufsetze. Für wirklich nötig halte ich es aber nicht. Ne amplification bekommst du da nirgends. Die Dinger sind so schnell (bzw. eher schneller) beantwortet wie gefiltert und eventuelle Angreifer müssten so viel senden, wie ich antworte. Absolut kein lohnendes Angriffsziel.

Als letztes bereitet mir noch das Holepunching kopfzerbrechen. Ist das auch möglich, wenn auf dem Server gar keine Anwendung auf irgendeinem Port "lauscht", die z.B. eine P2P-Verbindung etablieren kann?

Wenn du deine Anwendungen kontrollierst (Was immer die bessere Variante ist) brauchst du nie eine Firewall.
In sofern ist sowas eigentlich immer sinnlos. Ist halt eher als backup für unerwünscht handelnde Anwendungen gedacht. (Und vor allem ist iptables relativ effizient und braucht oft zum Filtern viel weniger Ressourcen als die dahinter liegende Anwendung. Entsprechend ist das auch ein (D)DOS schutz.)
Ansonsten ist "lauscht" ja eher der falsche Ausdruck. der Sinn von holepunching ist ja, dass es für beide so aussieht, als hätten sie die Verbindung aufgebaut und würden nicht auf die andere Seite warten.

[MSfree]

da wundert mich, dass die keinen Limiter enthalten, z.B. 5 Pings/s erlauben und dann DROP'n. Braucht man sowas gar nicht?

Ich habe es meistens drin, wenn ich eh schon ne Firewall aufsetze. Für wirklich nötig halte ich es aber nicht. Ne amplification bekommst du da nirgends. Die Dinger sind so schnell (bzw. eher schneller) beantwortet wie gefiltert und eventuelle Angreifer müssten so viel senden, wie ich antworte. Absolut kein lohnendes Angriffsziel.

Wenn der Server in einem Rechenzentrum mit dicker Anbindung steht, mag das stimmen. Einen DSL-Anschluß mit einem Upstream-zu-Downstreamverhältnis von 1:10 kannst du den Upstream realtiv einfach fluten. Pingpakete sind auch nicht in der Größe limitiert. Wenn ich damit jemanden schaden wollte, flute ich den mit 64kByte großen Paketen und der muß dann auch mit 64kByte großen Paketen Antworten.

[schorsch_76]

Momentan arbeite ich mich in diese ganze v6 Thematik eben ein. Das Nat funktioniert ist aber eben wieder eine Krücke.

Zuhause hab ich von der Telekom ein /56 Netz. Hier hab ich dann mit Prefix Delegation ein /64 Netz auf die interne Brücke eine öffentliche 2003:xxx/64 IP. Der Rechner als Router konfiguriert und ich komme direkt ins Netz. Auf der Brücke läuft dann ein radvd. Mit dhcpcd5 hab ich die PD gemacht.

Mit der Interfaces Datei und dem inet6 Segment kann man wohl auch PD machen. Aber das hab ich noch nicht zum laufen bekommen.

Edit: Bei Hetzner im Wiki steht auch noch was interessantes:

Aus einem Subnetz können auch eine oder mehrere Einzeladressen herausgelöst werden, während der Rest weitergeleitet wird. Man beachte dabei die Präfixlängen:
ip address add 2001:db8:61:20e1::2/128 dev eth0
ip address add 2001:db8:61:20e1::2/64 dev br0


Die Hosts an br0 geben als Gateway dann 2001:db8:61:20e1::2 an.

https://wiki.hetzner.de/index.php/Zusae ... n#Subnetze

[TomL]

Du hast die regeln eigentlich vollständig richtig interpretiert.

Nachdem ich ein paar Flüchtigkeitsfehler beseitigt habe (bei mir wurde das fehlende "-j" zum ACCEPT bemeckert), meine Mirrors eingetragen und die Regeln auf meinem Test-Pi mal getestet habe, kann ich feststellen: "wieder was dazugelernt". Das funktionierte perfekt! Und ich werde das angepasst auf meinem Server übernehmen.

[schorsch_76]

Damit hab ich von der Telekom Fritzbox ein Präfix per Delegation bekommen.

/etc/dhcpcd.conf

Code: Alles auswählen

allow_interfaces wlan0,br0

noipv4
noipv6rs

interface wlan0
 ipv6rs
 iaid  1
 ia_pd 1/::/64 br0/0/64

radvd.conf

Code: Alles auswählen

interface br0
{
        AdvSendAdvert on;
        prefix ::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
                Base6Interface br0;
        };
};

Damit erhält der Host eine v6 Adresse auf der wlan0 und br0 Schnittstelle.
Routen sehen so aus:

Code: Alles auswählen

ip -6 route
2003:8b:xxxx:ea00::/64 dev wlan0 proto kernel metric 303  mtu 1492 pref medium
2003:8b:xxxx:eafa::/64 dev br0 proto kernel metric 204  pref medium
fe80::/64 dev br0 proto kernel metric 256  pref medium
fe80::/64 dev wlan0 proto kernel metric 256  pref medium
default via fe80::3a10:d5ff:fe4e:b972 dev wlan0 metric 303  mtu 1492 pref medium

Das nur als Krumen für andere die dasselbe machen wollen

[schorsch_76]

Nachtrag:
Hab jetzt meinen Server wie im Hetzner Wiki fit für IPv6 gemacht. Eine Adresse (die des Hosts) aus dem Subnetz herausgelöst. Wie das zuhause mit einem dynamischen Präfix geht, hmm ...

Mit Shorewall6 hab ich nur den Webzugriff auf die www VM erlaubt.
VPN bleibt momentan noch auf v4.