Hilfe beim Bau meiner Super-Duper-Firewall

[besterino]

Hallo einmal wieder liebe Freunde der gepflegten Selbstgeißelung!

Nachdem ich irgendwie an der Server-Front viel zu lange keine ToDos mehr hatte und außerdem ein Bandbreiten-Upgrade am heimischen DSL-Anschluss unmittelbar bevorsteht (toitoitoi), muss eine neue Baustelle her:

'ne (gescheite) Firewall / Routingkonfig. Mit VPN. 3 Physische Subnetze. Und irgendwie auch noch WLAN. Und irgendwie Support für eine (Windows-)Domäne/AD.

Also eigentlich will ich mal meine "gewachsenen Netze" entrümpeln.

Fangen wir mal mit dem aktuellen Stand an.

TEIL 1: Der Ist-Zustand

Im Prinzip habe ich 2 physische Netze:

1. ein 1Gbit-Netz direkt hinter der Fritzbox quasi als einzige "Firewall" nach draußen (Netz1, 10.0.1.0/24), und
2. ein 10Gbit-Netz für die Server und eine Workstation (Netz2, 10.0.2.0/24)

Im Netz1 hängen alle Geräte, also Drucker, Fernseher, Familien-PCs, WLAN-APs und auch die Server inkl. alle VMs (wegen der Internetverbindung). Die IP-Adressen für Netz1 vergibt grundsätzlich die Fritzbox per DHCP (mit einigen festen IPs für die Server und Drucker). Im Netz1 hängen auch die Domaincontroller-VMs (Active Directory), allerdings sind längst nicht alle PCs auch in der Domäne. Das heißt, für non-Domain Geräte ist die Fritzbox der primäre DNS, für domain-joined (Hyper-V und manche VMs) eben der DC - das muss ich dann aber den Domain-joined-Geräten immer manuell beibringen (nervig). Über das Netz1 verwalte ich auch sämtliche Server (wegen der Domain-Vertrauensstellung).

Im Netz2 hängen nur die Server und die Workstation. Es gibt (noch) keinen DHCP. Auch die DCs hängen nicht am Netz2 (Microsoft empfiehlt ja ausdrücklich nur eine NIC für DCs).

Dazu habe ich noch einen dritten Switch, den ich aber eigentlich derzeit nicht wirklich nutze (war mal gedacht für ein separates Management-Netz - auch weil mir am Hauptswitch die Ports ausgegangen sind, habe ich aber bisher nicht umgesetzt).

Habe auch mal ein Bild zum Ist-Zustand gepinselt:

TEIL 2: Wo soll's hingehen?

Problem 1: Der DHCP-Server der Fritzbox kann leider nicht wirklich, was ich will:

1. Ich möchte gerne dauerhaft ganz bestimmte IP-Adressen für bestimmte Kisten zuweisen (MAC1=IP1, MAC2=IP2 usw.).
2. Ich möchte gerne mehrere Subnetze mit DHCP beglücken (und auch darin MAC-abhängig IPs zuweisen).
3. Ich möchte am liebsten auch MTU-Settings wie MTU=9000 automatisch an die Clients pushen - das ist aber eher Wunschliste als Anforderung.

(Außerdem nervt mich die auf allen Clients automatisch gesetzte bzw. verwendete fritz.box-"Domäne" kollossal.)

Problem 2: Die Firewall der Fritzbox reicht mir nicht mehr.

4. Ich hätte gerne IPS.
5. Ich hätte gerne ein gescheites Monitoring über den Internet- und Intranetverkehr.
6. Ich hätte gerne eine saubere Trennung des Netz2 vom Netz1 (aber die Fileserver müssen trotzdem auch für die Familie aus Netz1 erreichbar sein).
7. Ich hätte gerne einen HA-Firewall-Cluster, z.B. mit pfSense - zwei ESXi-Boxen laufen ja sowieso permanent (aber auch das ist momentan eher Wunschliste als Anforderung)...

Problem 3: Ich hätte gerne die AD sauber getrennt vom Rest

8. Dafür könnte ich vielleicht den derzeit ungenutzten 1Gbit-Switch zum Aufbau eines dritten Netzes (Netz3, 10.0.3.0/24) als Management-/Domänen-Netz verwenden und das Netz2 quasi ausschließlich als Storage-Netz (SMB/iSCSI). Allerdings habe ich noch nicht ganz verstanden, ob ich dann Netz3 für die Domäne benutzen sollte, oder (auch) Netz2 und ob sich die Mist-Kisten dann auch vertrauen, wenn die IPs im Storage-Netz andere sind als im Domänen-Netz...

Problem 4: VPN-VM einmotten

9. Ich würde gerne die aktuelle VPN-VM einmotten und mit der Firewall direkt in einem erschlagen.
10. Die Lösung muss eine 100/40mbit Leitung verschlüsselt bekommen.
11. Über's VPN müsste ich mindestens auf eine Management-VM (quasi als DMZ?) kommen, um von dort dann die Server administrieren zu können.
12. OpenVPN finde ich ziemlich gut, wäre aber wechselbereit (vor allem, wenn ich dann auch den Tunnel Pre-WinLogin aufbauen könnte...)

Problem 5: Und was mache ich mit WLAN?

13. Irgendwie hätte ich da gerne eine MAC-basierte Whitelist (die drauf dürfen ins heilige interne Netz mit Fileservern usw, die nicht drauf dürfen nur ins Internet).

Ach ja, das Ganze will ich mit einer Firewall-VM unter ESXi realisieren.

So. Womit bekomme ich das am besten umgesetzt? pfSense? UTM (ich brauch aber mehr als 50 IPs / Subnetz)? Sonstiges? Gibt es irgendwelche Empfehlungen zum allgemeinen Grundaufbau (Netz3 überhaupt nötig)? Sollten die DCs für "ihr" Netz auch DHCP-Server spielen oder kann ich das zentral in der Firewall machen?

Bilde mir ein, mich ja eigentlich ganz gut auszukennen mit Linux, Windows (Server) und Netzwerkkram. Aber die Wechselwirkungen zwischen DHCP/DNS/AD (vor allem über verschiedene Sub-Netze hinweg) durchschaue ich einfach noch nicht so ganz. Ansonsten muss ich einfach mal anfangen, aber einfach Trial-and-Error ist manchmal echt schmerzhaft...

 

[hominidae]

...in einer VM geht latürnich pfsense oder OPNsense.
Routeros von mikrotik gibt es in einer Variante für VMs/Cloud (CHR) oder für x86-Systeme, allerdings ist da OpenVPN nur teilweise umgesetzt.
Für die gewünschte Leistung/Durchsatz musst Du halt die passende Hardware in der VM bereitstellen..für VPNs am besten mit AES Support.

 

[Fatality]

hast du weniger als 50ip's im gesamtnetz?
dann zieh ne sophos UTM in ner vm auf, free.
Mit der erschlägst vermutlich alles was du brauchst+ nice to have wie html5-vpn

 

[hominidae]

...der TE sagte oben ja schon, dass er mehr braucht als 50 IPs/Subnetz.
RouterOS ist allerdings auch nicht free, zumindest wenn man den Speed braucht..einmalig ca. 50EUR, glaube ich.

 

[besterino]

Danke für Euer Feedback schon einmal!

Jo, die 50 IPs sind zu knapp und auf lizenzwidrige "workarounds" hab ich keine Lust.

Die ESXi-Hosts sind v1 bzw. v5er E3 Xeons, bringen also AES-NI mit. Müsste doch dann auch den VMs zur Verfügung stehen.

Glaub ich schau mal, wie weit ich mit pfSense komme. Muss mir noch klar werden, ob die pfSense auch für das Windows-Domain-Netz den DHCP macht, oder doch besser die DCs (mit der pfSense dann z.B. als Standardgateway?).

 

[magicteddy]

Routeros von mikrotik gibt es in einer Variante für VMs/Cloud (CHR) oder für x86-Systeme, allerdings ist da OpenVPN nur teilweise umgesetzt.

für V7 ist zumindest UDP angekündigt: Feature request: OpenVPN compression LZO and UDP - Page 4 - MikroTik RouterOS

-teddy

 

[AliManali]

Hi

Im Marktplatz hat letzhin einer ne Zywall 110 angeboten. Von der Leistung her ist die echt gut.

Die Zywall 110 habe ich auch in meinem Netzwerk, obwohl da noch ein Teil virtualisiert ist (VPN Gateway mit 2 Endians). Bei dem Netzwerk würde ich von einer virtualisierten Lösung absehen. Lässt Du auch in Zukunft die Fritte die Einwahl machen? Ist das WAN DSL, Kabel oder Fibre? Willst Du doppeltes NAT machen, oder willst Du direkt die öffentlichen IP's beziehen?

Wenn Du Geld für Lizenzen in die Hand nimmst, kannst Du die zywall auch zur UTM aufbohren. Ist allerdings recht teuer, wie ich finde.

http://www.hardwareluxx.de/communit...lancing-router-hardware-firewall-1139797.html

 

[besterino]

WAN ist (demnächst) VDSL mit fester IP. Eventuell irgendwann mal Glas, aber ich glaube nicht das die aktuelle Bedarfsbündelung die nötigen 40% erreicht...

Die Fritte macht also die "1. Firewall". Direkt dahinter soll dann aber eigentlich nichts mehr hängen außer der "großen/richtigen" Firewall.

Derzeit bin ich gerade am VMs sortieren und nach einer gewissen Logik feste MAC-Adressen an die VMs zu verteilen...

 

[AliManali]

Derzeit bin ich gerade am VMs sortieren und nach einer gewissen Logik feste MAC-Adressen an die VMs zu verteilen...

Ja, das hatte ich letzte Woche auf dem Plan. Ich hab da kein System mit den MAC Adressen, oder so. Ich lass die einfach generieren. Aber bei mir bekommen auch 95% der (v)NIC's ihre IP Adresse per DHCP von der Zywall und den Endians. Bei ein paar Adressen ist das leider nicht möglich: vom VPN Gateway. Leider.

Bei der Zywall kann man im Backup eine Textdatei öffnen, da stehen dann alle MAC Adressen und IP's drin. Macht auch im Zusammenhang mit Software Lizenzierung Sinn, sich die MAC Adressen zu merken.

Wenn Du eh doppeltes NAT machst, kannst Du auch ohne Bedenken eine virtualisierte Lösung nehmen.

 

[besterino]

Naja, die MACs vergebe ich jetzt nach:

1. Block: Host-Ident#
2. Block: Phys-Nic (00) oder virt-Nic (01)
3. - 4. Block VM-Nr. (pro Host)
5. Block: VM in nested Hypervisor (01)
6. Block: Nic-Nr.

Nicht perfekt aber sollte reichen.

 

[besterino]

Na geil. Fröhliches Rumspielen mit MAC-Adressen kann zu lustigen Fehlern führen. Wie ich (auf die harte Tour) herausgefunden habe, kann man nicht so ohne weiteres die Blöcke besetzen, sondern da hängen tiefere Dinge dran:

(Quelle)

Jetzt muss ich nur noch irgendwie herausfinden, wie ich da jetzt einen gesunden Mix von "richtig" und "self-made" hinbekomme.

HilfreicherLink:
Nomenklatur für Hyper-V, vmWare und Citrix

Ich habe mich jetzt also in "Anlehnung" an einen vmWare-Adressbereich (00:0c:29) mal als ersten 3er-Block 02:0c:29 ausgesucht (01=multicast bit und gibt die besagten Probleme/geht nicht) und vergebe den zweiten 3-er durchnummeriert nach Host/VM/NIC.

VM1 auf Host1 mit Zweit NICs hat also NIC1: 02:0c:29:01:01:01 und NIC2: 02:0c:29:01:01:02

Mal schauen, ob das so klappt... wünscht mir Glück! ;-)

 

[besterino]

Nachtrag: sieht gut aus. 8 VMs über 2 Hosts laufen jetzt mit den neuen MAC-Adressen. Als nächstes kommen die Hyper-Vs und dann kann ich mich mal an die pfSense setzen...

 

[AliManali]

Musstest Du die VM's neu aktivieren? Scheinst ja auch mit M$ unterwegst zu sein.

 

[besterino]

Öh glaub nicht. Die aktuellen VMs sind aber zum Großteil Solaris und Linux, bisher nur zwei MS DCs die auf Eval-Lizenzen (180 Tage) und eine Windows 10 Kiste - müsste ich m.W. nicht neu aktivieren.

Wäre auch komisch, maximal wird nach MAC-Address-Wechsel eine neue NIC erkannt.

 

[the_pi_man]

Dumme Frage an den TE:

Was zum Geier machst du mit dem ganzen Geraffel?

 

[besterino]

Was zum Geier machst du mit dem ganzen Geraffel?

Tjo, eigentlich primär herumspielen.

Allerdings bin ich bei uns auch so etwas wie ein "IT-Beauftragter", der als Schnittstelle zwischen IT und Business "übersetzt" und wechselseitig verprobt, was gewollt und (vielleicht) möglich ist. Da hilft es dann tatsächlich in der Kommunikation mit beiden Seiten, wenn man das Gefühl vermitteln kann, man wüsste zumindest halbwegs worum es geht und/oder mit leuchtenden Augen vor den blinkenden Lichtern im Serverraum steht und mit den Admins über die jüngsten Schwachsinnigkeiten im eigenen Homelab fachsimpelt... (Keine Sorge, an die Company-IT geh' ich nicht ran, das überlasse ich brav den Profis.)

Daneben bin ich aber natürlich auch - wie wahrscheinlich alle hier - der IT-Dienstleister für Family & Friends und habe insofern einen kleinen Produktiv-Bereich, den ich einfach nicht verfummeln darf...

Aber back to topic:

pfSense lüppt inzwischen und versorgt auch brav meine beiden Hauptnetze mit IPs über DHCP.

Mal als Erfahrung (bzw. Gedächtnisstütze für mich selbst):

1. vNICs / VMware-Tools:

Erster Punkt war aber, dass zwar eine vmxnet3-vNIC automatisch erkannt wird, die vmware-tools aber nicht laufen. Da ich nach einer (offenbar älteren) Anleitung zunächst die NICs als E1000 konfigurierte hatte, musste ich die noch einmal durchtauschen (auch dabei hat sich eine gewisse Logik mit festen MAC-Adressen als hilfreich erwiesen ). Da pfsense die vmxnet3-Adapter offenbar von Haus aus erkennt, wäre mein Tipp also direkt diesen NIC-Typ vor der Installation des OS für die VM zu wählen.

Dank dieser Anleitung habe ich dann auch die Installation der VMware-Tools hinbekommen und ESXi zeigt jetzt auch brav VMware Tools "Installiert und läuft" und die IP-Adressen kann ich in der Übersicht ebenfalls sehen.

Exkurs @ the_pi_man: So verschiedene Hosts mit verschiedenen physikalischen Netzen sind übrigens echt sehr hilfreich, wenn man remote an der Netzwerk-Konfig rumbastelt und sich nicht aussperren darf... So habe ich gerade auf einem ESXi die Firewall-VM laufen, auf einem anderen ESXi eine Client-VM für die Konfig und ein aktuell "ungenutztes physisches Netz" zum Testen. Wenn alles läuft oder für weitere Tests mit anderen Clients, stecke ich nur schnell was um (oder ändere noch einfacher die Anbindung der physischen Netze an die jeweiligen virtuellen Switches) und habe ratz-fatz den ehemaligen Testbetrieb in "Produktion".

Punkt 2 von Problem 1 ist damit also bereits erledigt.

2. MTU-Settings im Netz über DHCP verteilen

Ebenfalls (zumindest teilweise) gelungen ist von Problem 1 der Punkt 3, nämlich der DHCP-Server auf der pfSense pushed die MTU-9000 an die Clients - zumindest mit einem Linux-Client erfolgreich getestet. Tests mit Solaris und Windows stehen noch aus.

Dazu habe ich in der pfSense unter den zusätzlichen BOOTP/DHCP-Optionen für die Option 26, Unsigned 16Bit Integer den Wert 9000 eingetragen:

Die mal flugs auf DHCP-umgestellte Ubuntu-VM zeigt dann auch artig nach einem Aufruf von "dhclient" die neue MTU=9000 (ggf. muss man je nach Distribution in der /etc/dhcp/dhclient.conf - bzw. entsprechende Datei bei anderen Distris - in der "request"-Zeile den Wert "interface-mtu" ergänzen, Quelle).

Als nächstes werde ich wohl mal die verschiedenen zurzeit vorhandenen festen IPs auflösen und der pfSense ein paar MACs beibringen... (Ziel erreicht: neue Aufgaben = neue Spielwiese)

 

[besterino]

Nachtrag: Windows fragt die MTU-Größe wohl gar nicht beim DHCP-Server ab, kann man ergo also darüber auch nicht steuern... warum überrascht mich das nicht? *grummel* Naja, schwacher Trost: ist bei Apple Macs wohl auch so. Echt ein Jammer.

Mal schauen, was Solaris da macht.

 

[besterino]

Zu Solaris (11.3):

Auch bei Solaris 11.3 ist es nicht so ganz einfach, dem System beizubringen, per dhcp request als Client die MTU vom DHCP-Server (also FreeBSD / pfSense) zu ziehen. Vorab: habe es noch nicht hinbekommen.

Habe dazu die /etc/default/dhcpagent editiert und zu der PARAM_REQUEST_LIST=...24,25,26,27 hinzugefügt. Nutzt aber nix.

Laut der /etc/dhcp/inittab kann der dämliche DHCP ja eigentlich die Option 26: denn angeblich zeigt inittab "information about all supported DHCP options" und eben auch die gewünschte MTU/Option 26.

dladm show-linkprop -p mtu zeigt zu der NIC:

LINK     PROPERTY        PERM VALUE        EFFECTIVE    DEFAULT   POSSIBLE
net1     mtu             rw   1500         1500         1500      1500-16366

Also _SOLLTE_ die MTU doch möglich sein.

Komischerweise zeigt ipadm show-ifprop -p mtu aber irgendwie etwas anderes:

IFNAME      PROPERTY        PROTO PERM CURRENT    PERSISTENT DEFAULT    POSSIBLE
net1        mtu             ipv4  rw   1500       --         1500       68-1500
net1        mtu             ipv6  rw   1500       --         1500       1280-1500

Wenn ich "brute force" die MTU auf z.B. 12000 hochschraube, ändert sich POSSIBLE auf 68-9000 - scheint also nur die MTU-Range zu sein, mit der das System dann auch wirklich arbeiten kann.

Exkurs: Wenn man die MTU mit "dladm set-linkprop -p mtu=9000 netXXXX" wegen einer Fehlermeldung "link busy" nicht setzen kann, muss man die Konfiguration von "Automatic" auf "Manual" ändern. Das geht mit "netadm enable -p ncp DefaultFixed" (Quelle). Das hat mich auch etwas Nerven gekostet - immerhin gefolgt von dem wohligen Gefühl, wieder was zu Solaris dazu gelernt zu haben...

Habe schon versucht, den dhcpagent im debug modus für weitere Analyse zu starten, das klappt aber irgendwie nicht...

Aber: mit einem Linux-Client im gleichen Netz klappt es.

 

[xrisse]

Ich würde nen Mikrotik Router als Firewall und VPN-GW empfehlen. Gut und günstig, betreiben wir seit Jahren (>100 Stück)

Gesendet von meinem ONEPLUS A3003 mit Tapatalk

 

[TCM]

Was zur Hölle ist das mit den MAC-Adressen? Wenn dir bis dato nicht bekannt war, dass bestimmte Bits in MAC-Adressen ganz bestimmte Bedeutungen haben, warum glaubst du dann, dieses händische Rumfummeln wäre sinnvoll oder notwendig? Hast du das irgendwo im Internet gelesen oder ist dir das selbst eingefallen? Was ist der Sinn dahinter?

 

[besterino]

Komm mal mit dem Ton wieder ein wenig auf Normalmaß runter.

Wenn Du mit Hypervisoren und VMs arbeitest, kommst Du kaum daran vorbei, Dich mit MACs zu beschäftigen, schon weil für bestimmte Szenarien feste MACs zum Beispiel die Empfehlung sind bzw. dynamische/automatische MACs zu Problemen führen. Und wen man sich mit Dingen zum ersten Mal beschäftigt, weiß man üblicherweise nicht gleich alles, das unterstelle ich jetzt mal ganz frech auch bei Dir. Und das wie auch die Fehler und Probleme sind in einer Testumgebung so wie bei mir (falls Du das hier vernünftig mitgelesen hättest, wüsstest Du auch das) auch mal überhaupt kein Beinbruch sondern auch quasi schon konzeptionell vorausgesehen und in Kauf genommen.

Und natürlich macht ein System auch hinter MACs SINN, so wie bei eigentlich ALLEM was man macht eine Logik eher hilft als schadet. Schon um doppelte MACs zu vermeiden oder eben auch an der MAC zu sehen, um welche VM es sich handelt, Whitelisting nach Gruppen und und und. Es ist eher so: wenn man sich ETWAS tiefer mit Netzwerken beschäftigt, kommt ziemlich schnell zu dem Thema...

Jetzt wusste ich in diesem konkreten Fall leider nur, das die MACs (zum Teil) Hersteller-spezifisch sind. Dass da auch Topologieimformationen hinterlegt sind, wusste ich in der Tat nicht. Aber so what? Wieder was gelernt und das Wissen mit Euch geteilt. Wer's schon wusste, darf sich gerne nicht angesprochen fühlen oder aber natürlich auch gerne meinen Horizont erweitern.

Wenn Du aber meinst, Du könntest mit Deinem Ton mich in irgendeiner Weise überzeugen, Du hättest a) was interessantes beizutragen, b) mehr Ahnung als ich oder c) mich von wagenhalsigen Experimenten bei völliger Ahnungslosigkeit bzw. gefährlichen Halbwissen abhalten, muss ich Dich leider enttäuschen.

Ich will nämlich immer etwas LERNEN. Das geht am besten, wenn man's selber macht und dabei sind Fehler nunmal normal (und in meinem Fall sogar antizipiert und eingeplant).

So long.

 

[TCM]

Dann musst du aber auch z.B. die GUIDs der Systeme händisch verwalten, denn die sind ja auch zufällig und könnten kollidieren. Ich verstehe vielleicht noch, dass man für eine, zwei VMs Hand an die MAC-Vergabe legt, aber für jede VM ist das einfach der falsche Ort, um seine OCD auszuleben.

Warum z.B. sollte man die Nummer einer VM in die Adresse mit reinkodieren? Nimm mal an, der gesamte Host geht flöten und du musst jede VM wieder manuell importieren. Dass die Nummer dann dieselbe ist, ist doch gar nicht garantiert. Du schaffst eine völlig unnötige Verbindung zwischen zwei "Datensätzen", die nichts miteinander zu tun haben, aus rein ästhetischen Gründen, weil es irgendwie geordneter aussieht. Aber die wahre Natur der Daten dahinter ignorierst du einfach. Will sagen: dein System schafft eine permanente Verbindung zwischen so vielen Variablen (NIC-Nummer?!), dass die kleinste Änderung das System komplett zunichte macht. Du nimmst dir jede Flexibilität, an dem Setup Dinge ändern zu können und musst bei jedem Detail eine zusätzliche Liste pflegen, nämlich ob die MAC-Adresse tatsächlich noch zum Setup passt.

Mit einem vernünftigen Setup kannst du die Zuordnung von MAC-Adresse zu VM aus deiner DHCP-Config ablesen.

 

[besterino]

Alles nach Bedarf bzw. Lust und Laune. Ich hab hier bis zu 5 Server, die ich mangels Enterprise-Lizenzen für SCCM/SCOM, vSphere & Co. nicht zentral administrieren kann. Davon mindestens 2 auf ESXi, 1 auf Hyper-V und der Rest mal so, mal so, gerne eben auch in einem Hyper-V Cluster zwischendurch mit HA-VMs.

Da hilft mir eine gewisse Ordnung ungemein - auch bei der Bezeichnung der VMs, Hostnamen und Nummerierung an verschiedenen Stellen um VMs und physische Hosts auseinander zu halten bzw. auf den ersten Blick erkennen zu können.

Ich bin ja schon so bescheuert, und dokumentiere was ich mache (hier zum beispiel ja eher allgemein, die Details dann in noch in Excel) weil nichts nervender ist, als nach z.B. 6 Monaten sich wieder an etwas ran zu setzen und um weiter machen zu können erst wieder bei 0 oder 0,5 anfangen zu müssen... das Problem mit IT als Hobby...

P.S.: meine VMs sind fast alle Server-VMs. Und mein DHCP soll ja gerade immer dem gleichen System/VM die gleiche IP geben - aber das geht am besten über die MACs. Bisserl ein Henne-Ei-Problem. Die physischen Kisten zum Beispiel behalten natürlich Ihre echten MACs. Übrigens werden die fest vergebenen MACs beim VM-Import ebenfalls wieder gesetzt. Hast Du automatische Vergabe, wird's eben 'ne neue.... Käse halt.

 

[fdsonne]

Das frage ich mich allerdings auch... Irgendwie, Spielerei/Bastellei gut und schön, aber bei so manchen Aussagen hier stellen sich mir echt fragen...
Auch die Themen mit dem DC/DNS und der Fragen dafür/dazu. Ich weis ja nicht.

Auch erschließt sich mir die Trennung der Netze nicht, wenn eh alle VMs in beiden Netzen aktiv sind. -> völliger Hohlsinn. Lass diese 1GBit/sec Kacke ganz weg und gut ist. Das brauchst du bestenfalls für die Clients, die ausschließlich 1GBit NICs haben. Dann gibts irgendwo nen Link zwischen dem 1GBit Switch und dem 10GBit Switch -> worüber all der Traffic geht, der eben von den Clients zu den VMs/Servern soll und fertig die Laube. Reicht dir dort der Speed nicht, besorg dir nen 1GBit Switch mit 10G Uplinks oder von mir aus mach LACP oder ähnliches.

Das ist/wirkt hier alles doch etwas abenteuerlich und wenig bis gar nicht sinnig...
Vor allem auch, verstehe ich das Bild oben richtig, du hast nen Hyper-V Cluster, wo der dritte Host als nested Install auf einem ESXi virtualisiert ist? Welchen tieferen Sinn soll das haben? Nested ist mir schon klar und auch der Sinn dahinter, sieht mir aber nicht nach dem aus, wofür man das generell einsetzt!




Konkret zu den Punkten von oben:
1. -> schenk es dir, ist unsinn. Entweder du vergibst IPs via DHCP, dann brauchst du nix anderes als die MAC im DHCP einzudrehen -> ganz sicher aber nicht die MAC nach was auch immer für einer Syntax zu erzeugen. Oder du vergibst einfach fixe IPs... Für die Hand voll Server dürfte das definitiv kein Problem darstellen. Das bekommen selbst Unternehmen mit hunderten oder tausenden Teilnehmern hin.
2. -> dann tue es. Stichwort IP Helper
3. -> braucht man das zwangsweise? Dort wo es sinnig ist, kannst du es fix eindrehen. Beim Rest? Ich denke nicht, dass es auf der Clientseite sinnig sein wird, bringt doch effektiv nur bedingt etwas.

(Außerdem nervt mich die auf allen Clients automatisch gesetzte bzw. verwendete fritz.box-"Domäne" kollossal.)
-> dann schmeiß die FB raus

4. -> was stellst du dir darunter genau vor? Ich frage deswegen, weil allein deine Aussagen Fragen aufwerfen. Nicht dass du dem Irrglauben unterliegst, ich schalte IPS ein und das ist dann alles!?
5. -> Netflow oder dergleichen könnten das liefern
6. -> dürfte so ziemlich das einfachste sein, was man machen kann. 2x VLANs und ein Router mit Interfaces in beiden Netzen -> fertig. Ggf. Firewall zusätzlich/alternativ nutzen
7. -> Overkill aus meiner Sicht... Machen kann man natürlich viel. Die Frage ist, geht das in deiner Konstellation? Du hast vor der Firewall halt eine FB stehen. Keine Ahnung, wie das dort genau umgesetzt ist, sprich ob es dann eine Cluster IP auf der public Seite gibt -> weil wenn nicht, kannst du Port Forwardings von public nämlich vergessen, da diese schlicht nur auf eine IP zeigen.

8. -> was willst du da trennen!? Wenn es dir beliebt, bau ein drittes VLAN dafür und fertig. Da eh alles virtuell ist, und der Spaß wohl alles auf einem Server liegt!? Reicht ein simpler zusätzlicher vSwitch bzw. eine Portgruppe mit entsprechendem Uplink und VLAN dafür. Aus meiner Sicht musst du aber nochmal ein paar Grundlagen verinnerlichen. Nicht böse gemeint, aber die Frage, ob du nun IP Netz 2 oder 3 nimmst ist was völlig anderes ob du Switch A oder B nimmst, zwei völlig verschiedene paar Schuhe-> und dazu eigentlich sogar irrelevant, wenn der Spaß virtuell ist. Auch solltest du dir über die Konsequenzen einer VLAN Trennung und Splittung der IP Netze im Klaren sein -> denn das heist, ALLES an Traffic zu oder von diesen getrennten Bereichen, wird über den Router/die Filewall geballert. Entsprechend Bumms muss das Ding haben. IPS/IDS und andere Spielereien kommen oben drauf. IPSec Durchsatz ist da nur das kleinste übel...

Zu den anderen Punkten, VPN ist abhängig der bevorzugten Lösung, ob VM oder in Hardware, musst du entscheiden. Ob auf dem selben "Blech" also der einen existierenden/zu bauenden Firewall oder nicht, ebenso. Da kann man dir nur bedingt Rat geben, gehen wird das alles, sinnig kann auch alles sein, wenn man eben die richtigen Gründe dafür hat.

WLAN ist wieder ein anderes Thema. MAC basiert irgendwas zu tätigen ist aber irgendwie kappes. Denn wie du vielleicht schonmal festgestellt hast bei deiner Spielerei mit den MAC Adressen -> diese lassen sich ändern
Willst du WLAN in Sinnvoll, dann mach es mit Zertifikaten/Radius oder ähnlich. Sinnigerweise benötigst du dafür einen WLAN Controller oder wenigstens einen (oder mehrere) APs, die eine Art NAC können. Also policy based die Regeln definieren... Auch hier ist wieder eine Grundsatzfrage zu klären. Wer steuert den Spaß? Steuert das der WLAN AP/der Controller? Oder steuert das die Firewall? Oder ist beides in einem Gerät integriert?
Die Quick and Dirty Lösung wäre dazu wohl einfach eine Art Guest Portal zu nutzen -> alle bekannten Clients kommen intern, alle "unbekannten" Clients oder eben der Rest, dürfen nur public... Das kann sogar die FB, soweit ich weis... Mehr Steuermöglichkeiten aber = mehr Kosten = mehr Aufwand. Das geht soweit, dass du bis auf die Einhaltung bestimmter Parameter prüfen kannst. Bspw. hat der Client nen aktuellen Virenscanner oder aktuelle Windows Updates drauf usw. und dann aufgrund dessen ihn nur in ein Netz lassen (oder Access gewähren) wo er sich die aktuellen Viren Pattern laden und die aktuellen Updates ziehen darf, aber sonst gar nix anderes geht.

Und natürlich macht ein System auch hinter MACs SINN, so wie bei eigentlich ALLEM was man macht eine Logik eher hilft als schadet. Schon um doppelte MACs zu vermeiden oder eben auch an der MAC zu sehen, um welche VM es sich handelt, Whitelisting nach Gruppen und und und. Es ist eher so: wenn man sich ETWAS tiefer mit Netzwerken beschäftigt, kommt ziemlich schnell zu dem Thema...

Bis auf ein paar wenige Ausnahmen wirst du mit den MAC Adressen eigentlich so gar nix zu tun haben...
Warum? In deinem Netzwerk wirst du idR eine Ebene drüber ansetzen. Es geht dabei eher um IP Kommunikation. Für das "lernen" kann man sich das ja ansehen -> aber hat man es verstanden, dann fällt einem recht schnell auf, dass es irrelevant ist.
Um eine IP zu MAC Zuordnung zu bekommen, gibt es übrigens ARP Tables. Das wirst du (sinnigerweise) auf deiner Firewall abgreifen können, denn die sollte sogut wie alle Clients kennen, wenn es das zentrale Device ist. Für IP zu Name gibts dazu noch DNS/Reverse DNS. Kurzum, es braucht schlicht die MAC überhaupt nicht... Die kann sein was will, scheiß egal.

Diese aus meiner Sicht "Unart", Namen von Systemen mit IPs oder MAC Adressen zu versehen, halte ich auch für gänzlich unsinnig, einfach weil man sich damit jegliche Flexibilität raubt -> und/oder im Falle einer Migration das System inkonsequent wird.
Nur mal ein Beispiel, ich hab nen Mailserver, der heist von mir aus MAIL01 als VM, die 01 entspricht dabei der IP .1 im letzten Byte und von mir aus noch der IPv6 IP ::1 im letzten Feld. Wie migriere ich nun das Ding auf eine neue Version? Doppelte Namen ist nicht, doppelte IPs ebenso nicht. Entweder ich biege ALLES um, um aus MAIL01 MAIL02 zu machen, temporär, damit MAIL01 frei wird und ich IPv4/IPv6 sowie MAC wieder frei habe -> oder es kümmert mich gar nicht und der Mailserver heist einfach nur so, wie die Zähler gerade frei sind...

Weil du ja davon sprachst, wenn man sich ETWAS tiefer beschäftig -> dann kommt man schnell darauf, dass diese 100% fixe und idiotensichere Struktur in der Praxis nicht standhalten kann und wird -> einfach weil man NULL Flexibilität hat und es dazu NULL ersichtliche Vorteile daraus gibt

 

[TCM]

Zum Thema WLAN würde ich einfach irgendeinen TP-Link mit OpenWrt nehmen, verschiedene WLANs aufspannen und diese je auf ein VLAN legen. Was welcher Client darf, entscheidet dann Firewall/Router. Mit OpenWrt geht auch 802.1x mit RADIUS und pipapo.

 

[besterino]

Danke!

Nee, IP zu MAC matching mach ich zum Beispiel nicht. Und ihr habt beide recht, dass zum Beispiel ein Matching zu einem Host z.B. schon in einem Cluster nicht funktioniert (heute ist die VM auf Host1, morgen auf Host2...).

Ist ja alles auch gar nicht in Stein gemeißelt, daher bin ich durchaus wirklich für sachdienliche Hinweise dankbar. Ein Teil meiner Themen dürften sich wohl auch in der Tat mit gescheiter Konfig von DNS/ReverseDNS erledigen.

 

[fdsonne]

P.S.: meine VMs sind fast alle Server-VMs. Und mein DHCP soll ja gerade immer dem gleichen System/VM die gleiche IP geben - aber das geht am besten über die MACs. Bisserl ein Henne-Ei-Problem. Die physischen Kisten zum Beispiel behalten natürlich Ihre echten MACs. Übrigens werden die fest vergebenen MACs beim VM-Import ebenfalls wieder gesetzt. Hast Du automatische Vergabe, wird's eben 'ne neue.... Käse halt.

Das ist auch sinnig so mit der Dokumentation, denn auch wenn du das "mal" gebaut hast, in ein paar Monaten/Jahren erinnerst du dich sicher nicht mehr an alles, was du da irgendwann mal eingedreht hast.
Möglicherweise wäre es sogar sinnig, sich entsprechende Software zu besorgen. Bspw. ein IP-Adress Tool, ich nutze für das Thema PHPIpam. Ist ein PHP/Web based IP-Adress Management Tool, da trägst du bspw. die genutzten IPs und IP Netze ein, das ganze kannst du ans DNS Koppeln -> was bspw. ein Grund ist, warum die DNS Infrastruktur sinnig aufgebaut sein sollte. Das Teil pollt bei gedarf die IPs auf Verfügbarkeit usw. So bekommst du binnen einem Blick die Adressen der Maschinen raus ohne irgendwelche Tabellen und Listen händisch zu pflegen.

PS: VM-Import dürfte nicht so ultra häufig vorkommen. In der Praxis ist eher das Ausrollern von Templates die Regel. Sprich du brauchst ne neue Kiste, dann legst du das nicht von Hand an oder ähnliches, sondern deployst einfach ein Template. Auch dort hsat du bspw. auf der VMware Seite keine direkte Möglichkeit, die MAC fix zu drehen -> im Nachgang. Will man sich normal aber nicht antun. Machst du es richtig, läuft das Ausrollern fully unattended. Das heist, ohne jegliches Zutun deinerseits.

Ist ja alles auch gar nicht in Stein gemeißelt, daher bin ich durchaus wirklich für sachdienliche Hinweise dankbar. Ein Teil meiner Themen dürften sich wohl auch in der Tat mit gescheiter Konfig von DNS/ReverseDNS erledigen.

Wie gesagt, das A und O ist eigentlich eine saubere Planung... Wenn dir im Nachgang auffällt, das da noch irgendwas nicht passt, wirds meist fricklig oder es artet in basteln aus.
Planst du aber sauber, dann sollte sich fast jedes Problem damit lösen lassen.
Gerade das Thema AD/DNS ist da so eine Sache. Wenn man schon ein AD betreibt, bietet es sich an, das gleich für effektiv ALLES zu nutzen. Sprich die Zonen im DNS sind genau die, wo all die Clients ihre Einträge einhämmern. Vorwärts wie Rückwerts... Dann hast du also schonmal die halbe Miete drin, denn du musst neben dem Namen (FQDN) effektiv gar nix wissen zur VM/dem Server/dem Client. Keine MACs, keine IPs usw., der Name ist entscheidend... Auf der Netzwerkseite wirst du allerdings mit IPs arbeiten, ggf. kann die/deine Firewalllösung auch Regeln anhand von FQDNs abwickeln -> müsstest du dir überlegen, ob das für dich eine Lösung ist, wenn ja, dann könnte man sich auch die IPs effektiv komplett schenken. Du könntest alles volldynamisch verteilen (lassen) und es gibt bei sauberer Funktion keinen wirklichen Nachteil -> und für dich nur Vorteile vor allem im Aufwand.


Was mir übrigens noch auffällt. Schau dir sinnigerweise, wenn du sowieso derartiges umsetzen willst, auch IPv6 an, das wird kommen. Vllt nicht heute und nicht morgen, aber irgendwann... Muss man sowas mal betreiben, sollte man wissen, was man dann tut, denn es erfordert teils doch etwas andere rangehensweise. Du könntest also in der Umsetzung initial einfach Dual Stack fahren. Also IPv4 + IPv6 gleichzeitig... Macht die Thematik zwar ungemein komplexer -> gehts aber auch im Wissensaufbau (und davon gehe ich aus), kann es definitiv nicht schaden

 

[TCM]

Schau dir sinnigerweise, wenn du sowieso derartiges umsetzen willst, auch IPv6 an, das wird kommen. Vllt nicht heute und nicht morgen, aber irgendwann...

IPv6 ist seit 20 Jahren da. Diese falsche Einschätzung, dass es nicht heute oder morgen, sondern irgendwann kommt, verhindert eher, dass sich die Leute zügig damit auseinandersetzen. Wenn die Tatsache, dass bestimmte Kabelanbieter keine IPv4-Adressen mehr pro Kunde verteilen, das nicht deutlichmacht, dann weiß ich auch nicht mehr weiter. Jeder, der einen der großen Anbieter nutzt, hat IPv6. Jeder kann sich auf Hurricane Electric Internet Services - Internet Backbone and Colocation Provider einen Tunnel besorgen und hat dann zu Hause ein statisches /48 für Serverdienste. Es gibt keinerlei Ausreden, das noch vor sich herzuschieben.

 

[besterino]

Ich kann mir aber die IPv6 Blöcke so schlecht merken..

 

[TCM]

Bitte einmal aus dem Kopf die IP-Adresse von www.google.com aufsagen!