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
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 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
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
http://www.freebsd.org/doc/de/books/handbook/network-routing.html