#!/bin/sh

INTIF="vmnet1" #Internes Interfacew (VMware)

EXTIF="eth0" #Externes Interface (Internet)

echo "Loading required stateful/NAT kernel modules..."

/sbin/depmod -a

/sbin/modprobe ip_tables

/sbin/modprobe ip_conntrack

/sbin/modprobe ip_conntrack_ftp

/sbin/modprobe ip_conntrack_irc

/sbin/modprobe iptable_nat

/sbin/modprobe ip_nat_ftp

/sbin/modprobe ip_nat_irc

echo "    Enabling IP forwarding..."

echo "1" > /proc/sys/net/ipv4/ip_forward

echo "1" > /proc/sys/net/ipv4/ip_dynaddr

# FWD: Allow all connections OUT and only existing and related ones IN

iptables -A FORWARD -i $EXTIF -o $INTIF -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT

# Enabling SNAT (MASQUERADE) functionality on $EXTIF

iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE

iptables --table nat --append POSTROUTING -o vmnet1 -j MASQUERADE

iptables --table nat --append POSTROUTING -o eth0 -j MASQUERADE

iptables -P OUTPUT ACCEPT # output immer annehmen

iptables -P OUTPUT ACCEPT -t nat

# Outgoing

iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE

iptables -A FORWARD -i $EXTIF -o $INTIF -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT

# NAT #

#######

iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE # was rausgeht wird maskiert

#iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j DNAT --to $INTIP # -> vmnet1

iptables -t nat -I PREROUTING -p tcp -i eth0 --dport 443 -j DNAT --to 192.168.0.210:443

Ein Gast-Betriebssystem unter VMWare auf einem Linux-Server zu betreiben, ist nicht besonders kompliziert, und wenn als Netzwerk-Modell VMWare NAT (vmnet8) gewählt wird, hat das Gast-Betriebssystem sofort freien Internetzugang.

Problematisch wird die Sache, wenn man von außen Zugriff auf bestimmte Gast-Dienste gewähren möchte, also z.B. einen Webserver, VNC oder Remote Desktop betreiben möchte, denn der NAT-Service von VMWare arbeitet wie jede andere Firewall: er blockt alle eingehenden Anfragen.

Die übliche Lösung ist das VMWare Bridging (vmnet0). Betreibt man VMWare auf einem angemieteten Root-Server, scheidet das aus, weil man normalerweise weder ein geeignetes IP-Netz, noch öffentliche IP-Adressen erhält, die nicht bereits auf Netzwerkkarten des Linux-Servers gebunden sind.

Weniger bekannt, aber sehr einfach und elegant ist die Konfiguration des VMWare NAT-Dienstes für Port-Forwarding. Dazu trägt man einfach in der Datei /etc/vmware/vmnet8/nat/nat.conf die gewünschten Port-Weiterleitungen ein. Um beispielsweise den TCP Port 8880 auf Port 80 der virtuellen Maschine umzuleiten, muss hier stehen:

[incomingtcp]
8880 = 192.168.133.128:80

Nach den Einträgen unbedingt
/usr/lib/vmware/net-services.sh restart
ausführen.

Dabei ist 192.168.133.128/24 das private Netz der VM, und 128 immer die erste, per VMWare-DHCP zugewiesene Adresse, bei nur einer Maschine braucht man daher noch nicht mal eine statische IP-Adresse im Gast-OS. Achtung: Diese Einstellungen werden erst bei einem kompletten Restart von VMWare übernommen. Jede Neukonfiguration mit vmware-config.pl löscht diese Einträge wieder!

Das funktioniert prima, hat aber den Nachteil, dass der incoming Traffic unakzeptabel langsam ist. (Auf einem Dual CPU Highend Server war outgoing 100 Mbit/s, aber incoming nur 200 kbit/s erreichbar, getestet mit VMWare Server V.1.0.1) Für den VNC-Zugang ohne Filetransfer oder ein paar interaktive Dienste reicht das aus, aber keinesfalls für mehr.

Bleibt als letzte Möglichkeit der Host-Only-Modus von WMWare, bei dem das gesamte Routing zur virtuellen Maschine manuell über die Linux-Firewall eingerichtet werden muss. Besonders elegant ist diese Lösung nicht, weil diese Linux-Firewall auch gleichzeitig den gesamten anderen Traffic zur Linux-Box beeinträchtigt, aber das ist Geschmackssache.

Unter Suse Linux 10 braucht man sich dafür nicht mit iptables herumzuschlagen, sondern kann alles über YAST an der Firewall einstellen. Zunächst richtet man eine neue Firewall-Schnittstelle mit Namen vmnet1 ein, und ordnet sie der internen Zone zu. (Der Name ist egal, er wird vom Router nicht verwendet). Jetzt kann IP-Masquerading eingeschaltet werden. Hier trägt man dann die forwarding ports ein, unter "Umleiten an IP" mus die IP-Adresse des Gast-Systems stehen, also in obigem Beispiel: 192.168.133.128, sowie der Ziel-Port.

Unter Erlaubte Dienste / Interne Zone kann Firewall vor interner Zone schützen abgewählt werden, wenn man aus dem Gastsystem über alle Ports ins Internet möchte (wer hat bloß diese unsägliche deutsche Übersetzung bei Suse verbrochen!).

Die Port-Weiterleitung funktioniert natürlich nur, wenn die Firewall eingeschaltet wird, dann ist sie allerdings auch auf der externen Zone aktiv, und blockt zunächst auch komplett alle anderen Zugriffe auf Linux. Unter Erlaubte Dienste / Externe Zone müssen daher der DNS, Webserver, FTP, Plesk, die VMWare Console usw. noch freigeschaltet werden.

Das Gastsystem bekommt eine statische IP-Adresse. Wenn für vmnet1 das Class C Netz 172.16.200.0/24 bei der VMWare-Installation eingerichtet wurde, ist einzutragen:

Gast IP-Adresse: 172.16.200.100 (zum Beispiel)
Default Route: 172.16.200.1
DNS Server: 172.16.200.1 (Ja, VMWare macht korrektes DNS-Forwarding! )

Das Positive an dieser Lösung: Es ist weder eine zweite Netzwerkkarte noch eine zweite IP-Adresse nötig, um beliebige Dienste der virtuellen Maschine von außen zu erreichen, und die Geschwindigkeit ist in jeder Richtung hervorragend.

Dieser Artikel stammt von Martin -> aus dem ip-forum.net (super Arbeit!)
Link: http://ip-forum.net/forum/index.php/topic,342.msg1167.html#msg1167

Wer programmiert sollte jederzeit eine Kopie von seinen Entwicklungen und den Vorgängern haben!
Dazu ist ein SubVersion da!

Installation:
Zuerst Updaten!
apt-get update

Wenn nicht schon vorhanden - einen Apache installieren!
apt-get install apache2

Nun kommt das Subversion inklusive Webpanel dran.
apt-get install subversion libapache2-svn

Nun diese Liste abarbeiten:
mkdir /var/lib/svn
svnadmin create /var/lib/svn
chown -R www-data /var/lib/svn
htpasswd -cm /etc/apache2/dav_svn.passwd testuser
nano /etc/apache2/dav_svn.authz und dort das Eingeben! ->

[/]
* = r
testuser = rw



weiter gehts:
svnserve -d -r /var/lib/svn
In der /etc/apache2/mods-available/dav_svn.conf folgendes hinzufügen.
<Location /svn>
  DAV svn
  SVNPath /var/lib/svn
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
  AuthzSVNAccessFile /etc/apache2/dav_svn.authz

  <LimitExcept GET PROPFIND OPTIONS REPORT>
    Require valid-user
  </LimitExcept>

  # SSLRequireSSL
</Location>
Nun noch

apt-get install enscript websvn
Euer SVN ist nun unter http://ip/websvn zu erreichen!
svn://ip
Um das SVN bei einem Neustart zu starten: svnserve -d
---
Vielen Dank an Thomas Krenn
http://www.thomas-krenn.com/de/wiki/Subversion_unter_Debian_mit_Webaccess

• Man sollte mehr als 70 GB Speicher auf dem Laufwerk zur Verfügung haben!
• Es kann bis zu 24 Std. dauern bis alles runtergeladen ist
• Es werden in diesem Fall keine Sicherheitsupdates geladen -> sollten immer aktuell sein!

Zuerst updaten!
apt-get update

Jetzt holen wir uns den Mirror!
apt-get install apt-mirror

Jetzt noch den Apache2 damit wir die Pakete auch verteilen können!
apt-get install apache2

Optional: Wenn ihr so wie ich die Sercurity Patches nicht haben wollt, entfernt in dieser Datei die Option: security
/etc/apt/mirror.list

Nun holen wir uns alles:
su – apt-mirror -c apt-mirror

Nun nach ca. 24 Stunden können wir ein dem Apache Verzeichnis was flüstern!
ln -s /var/spool/apt-mirror/mirror/ftp.de.debian.org/debian /var/www/debian

-- Der Mirror ist nun einsatzfähig!
Dem Client teilt man in der Datei: /etc/apt/sources.list folgendes mit!
Schaut am besten in eurem Mirror nach
deb http://xxx.xxx.xxx.xxx/debian unstable main contrib non-free
xxx mit eurer IP ersetzen.

Datenschutz  bedeutet das die Daten nicht an dritte weitergegeben werden!
*Gesicht*book macht das gerne! Es werden eure Nutzerdaten sowie Profilbilder etc. an Partner verkauft!

Schicht 2: Sicherungsschicht
- Daten werden anhand von Checksummen geprüft und in Frames gepackt.

Schicht 3: Vermittlungsschicht:
- möchte an das richtige Netz geroutet/vermittelt werden!

Schicht 4: Transportschicht:
Wir nun weitergereicht an den Client.

Schicht 5: Kommunikationsschicht:
Zuständig für Auf- und Abbau von Verbindungen.

Schicht 6:  Darstellungsschicht:
Umwandlung der Daten in ein verständliches Standardformat.

Schicht 7: Anwendungsschicht:
Stellt die Verbindung zwischen Netzwerkdiensten und den Anwendungen her.

Gateway (Der Macho -.-) -> kann in jedes Paket, Paketsammlungen, Frames..... und und und sehen -> Schicht 7