DMZ: Unterschied zwischen den Versionen

Version vom 1. Juli 2010, 08:35 Uhr

ADSL2+ Modem (192.168.1.1)
  |
  |
  |
+-eth1@.254----------------+
*                          *
* Host Hibakusha           *
*                          * 
+-eth0@.1------------------+
  |
  |
  |  192.168.68.0/255.255.255.0  (DMZ-Netz "Heiwadori")
  |
  |
+-eth1@.254---------------+
*                         *
* Host Heiwakoen          * 
*                         *
+-eth0@.20----------------+
  |
  |
  | 192.168.115.0/255.255.255.0 (LAN-Netz "Lummerland")
  |
  |
 **** Clients

Plan

Info zur Verwendung der japanischen Worte: Zur Erhaltung der Erinnerung an den Atombomben Abwurf von Hiroshima und in tiefen Respekt vor allen Opfern verwende ich folgende japanische Ausdrücke für Domänen und Hostnamen des Sicherungskonzeptes:

Hibakusha (Explosionsopfer) -> Host der dem Internet ausgesetzt ist
Heiwadori (Friedensallee) -> Domäne
Heiwakoen (Friedenspark) -> Host der den Router für das interne LAN darstellt

reale Umsetzung

Hibakusha

ist das Gateway inerhalb der DMZ (eth0, oranges Kabel), er ist mit dem Internet verbunden (eth1, magenta Kabel). Ich denke er macht ein ganz normales NAT, hierzu hat er eine zentrale Regel:

#
# anfragen aus dem lokalen Netz verfälschen dass es mit einer IP funktioniert
#
$IPTABLES -t nat -A POSTROUTING -o dsl0 -j MASQUERADE

#
# Pakete neu stückeln, so dass das DSL Netz damit klar kommt
#
$IPTABLES -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Routing: Hierbei ist wichtig, dass im bekannt ist wohin er "Antworten" ans LAN schicken darf. Dabei ist ja Heiwakoen unser "Router"

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
217.5.98.1      *               255.255.255.255 UH    0      0        0 dsl0
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
192.168.115.0   192.168.68.254  255.255.255.0   UG    0      0        0 eth0   <-- wichtig, sonst geht nix!
link-local      *               255.255.0.0     U     0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
default         *               0.0.0.0         U     0      0        0 dsl0

Heiwakoen

ist das Gateway für das normale LAN (eth0, beiges Kabel), er hat jedoch Verbindung zum DMZ-Netz (eth1, organges Kabel), er muss sich anfühlen wie ein normaler Router, dass hinter ihm die DMZ und der wirkliche Router steht soll das LAN natürlich nicht merken! Ich denke Heiwakoen macht den DHCPD für beide Netze.

Status

Problem: auf der Maschine selbst funktioniert das inet. Das LAN sieht Heiwakoen ja als Router an, Pakete mit "fremden" IPs landen bei diesem internen Router. Ich hatte gedacht der merkt das selbst, dass er diese Pakete an "sein" Gateway weiterleiten muss ...

erfolgloser Versuch:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 192.168.1.2

erfolgreicher Versuch:

das Routing auf "Hibakasu" war falsch: Er fand keine Route mehr zurück ins LAN. Siehe den Auszug seiner korrekten Routing Tabelle!

VLAN

ab Juni 2010: Vom Einsatz von VLANs verspreche ich mir einige Kostenersparnisse. Insbesondere kann alles auf den Switch aufgeschaltet werden was (RJ45-)Beine hat. So will ich DSL+DSL+Kabel Modem auf eigene VLANs schalten. Jeder Endpunkt ist isoliert und kann keine "Nachbarn" im Netz sehen. Es ergeben sich einige Vorteile ...

Gruppen

0,1 Reserviert 

2 DSL Modem 1
3 DSL Modem 2
4 Kabel Modem 1

5 DMZ "Shared"
6 LAN "Shared"

10 Client 1
.. Client n
99 Client 89

100 Guest 1 (nur Internet)
101 Guest 2 (nur Internet)
... Guest n
110 Guest 11

ich bin mir noch nicht sicher, ob das alles mit dem D-Link DGS-2010-16 funktioniert.

Ports

der (Smart) Switch besitzt eine Port-Konfiguration. Sie kann Statisch sein, das heisst Du musst Dinge festlegen für den physikalisch exisierenden Port 9 (als Bespiel). Das bedeutet wahlfreies Umstecken der Netzwerkkabel am Switch (so wie früher) is nich' Man könnte die Port-Konfiguration aber auch MAC Adress-Abhängig machen, wär für mich OK, da bei mir keiner einfach MAC Adressen mitlauschen kann un Das würde bedeuten, egal in welchen Port des Switch ich fahre - meine Konfiguration bleibt erhalten.

tagged ...

.... an diesem Port bedeutet:

Im Tx: Der VLAN-ID wird belassen, ist er nicht vorhanden wird er hinzugefügt
Im Rx: Der VLAN-ID wird belassen, ist er nicht vorhanden wird er hinzugefügt

untagged ...

.... an diesem Port bedeutet:

Im Tx: Der VLAN-ID wird entfernt (falls vorhanden)
Im Rx: Der VLAN-ID wird entfernt (falls vorhanden)

   | 
   | 
 *---*   Tx: Richtung Switch Port -> NIC
 | P |   Rx: Richtung NIC -> Switch Port
 *---*
   |
 *------*
 | NIC  |
 *------*

Rx: Alles was ohne VLAN ID kommt könnte man ja ergänzen Rx: Alles war mit VLAN-ID kommt könnte man ja fälschen oder man könnte "unerlaubte" VLAN Pakete ja verwerfen

-> da sind noch viele Fragen offen

unmanaged ... =

VLAN-IDs sind und bleiben da wenn sie da sind. Wenn nicht: Pech

Anlegen bei openSUSE

http://en.opensuse.org/YaST/Network/11.0-vlan

Links

http://www.freebsd.org/doc/de/books/handbook/network-routing.html