DMZ

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

Alternative mit DrayTek Vigor

Nameserver - Problem bei Load-Balancing

• Schlundtech

host nsb3.schlundtech.de
nsb3.schlundtech.de has address 217.160.113.53
nsb3.schlundtech.de has address 83.169.55.13

• http://code.google.com/intl/de-DE/speed/public-dns/

8.8.8.8 and 8.8.4.4

Hibakusha

• ist das Gateway innerhalb 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!

Dezidierter Server

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.115.0   *               255.255.255.0   U     0      0        0 eth0
91.89.152.0     *               255.255.252.0   U     0      0        0 eth1
link-local      *               255.255.0.0     U     0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
default         HSI-KBW-091-089 0.0.0.0         UG    0      0        0 eth1

#
# also 91.89.152.1 ist HSI-KBW-091-089-152-001.hsi2.kabel-badenwuerttemberg.de

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 Internet-Zugangs-Endpunkt ist isoliert und kann keine "Nachbarn" im Netz sehen. Es ergeben sich einige Vorteile ...

• http://www.linuxjournal.com/article/7268
• http://www.cyberciti.biz/tips/howto-configure-linux-virtual-local-area-network-vlan.html
• http://www.heise.de/netze/artikel/VLAN-Virtuelles-LAN-221621.html

Gruppen

0 Reserviert bzw. existiert nicht
1 LAN "Shared"
2 DMZ "Shared"

9 DSL Modem 1
10 DSL Modem 2
11 Kabel Modem 1
12 frei

13 Server Gruppe 1
14 Server Gruppe 1
15 Server Gruppe 1
16 Uplink

# trusted (Internet, Drucker, NAS)


# neutral

25 Client 1 (Internet / Drucker )
..  Client n
100 Client 101

# untrusted

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

Ports

der (Smart) Switch besitzt eine Port-Konfiguration. Sie kann nur 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 und einfach ein System mit einer gefälschten MAC Adresse einführen kann. Das würde bedeuten, egal in welchen Port des Switch ich fahre - meine Konfiguration bleibt erhalten.

Client Ports

• 01 raib25
• 02 h
• 03
• 04
• 05
• 06
• 07
• 08
• 09 WAN A
• 10 WAN B
• 11 WAN C
• 12 WAN D
• 13 Server A
• 14 Server B
• 15 Server C
• 16 Uplink "LAN"

Isolierte Ports

09 DSL 16000
10 DSL 3000
11 Kabel BW
12 - frei -

Server / Uplinks

13 raib25
14 - frei -
15 - frei -
16 Uplink DGS-1024

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

Also Du brauchst erst mal einen "unkonfigurierten" physikalisch existierenden Netzwerk-Adapter. Also z.B. "eth0". Da darf keine Netzwerk-IP oder so was konfiguriert sein, solche Sachen machst Du später bei den VLANs. Sind alle Konfigs von ´"eth0" entfernt erstellst Du einen Neuen Netzwerk-Adapter auf Basis von "eth0". Der Name ist gleich dem virtulenn VLAN ID.

Links

• Advanced Routing http://www.freebsd.org/doc/de/books/handbook/network-routing.html
• Eingesetzte Mainboards http://www.asus.com/Motherboards/Intel_CPU_on_Board/AT5NM10I/