6
1und1 Debian Minimal - Iptables Forward on VMware-Server 2.0.1 Host-Only , NAT
Einen schönen Guten Abend wünschen Wir erst einmal....
Wir haben uns mit der von Wladi750 angesprochen Thematik außeinander gesetzt. -> THEMA
Nun ist ein Debian Minimal auf unserem RootServer samt VMWare-Server 2.0.1 im Betrieb.
Unser RootServer besitzt 3 IPs welche momentan alle auf ein und die selbe MAC im Rechenzentrum zeigen.
Aktuell befinden sich alle VMs auf Host-Only.
Ganz grob ist unser Ziel: Eine IP auf eine VM legen zu können. Bridged ist NICHT möglich dank dem Aufbau im Rechenzentrum von 1&1!!!
Aktuell sieht unsere /etc/network/interfaces so aus:
Eine Variante unsere Iptables zu erstellen seht ihr hier:
wiederum eine andere Variante die uns ein Freudiger Mitarbeiter unserer Firma zukommen lies ( "anscheinden" unter Ubuntu 6.04 Dapper lauffähig ) seht ihr hier:
Diese beiden Varianten haben wir ausprobiert und dabei ist beim ersten script folgendes herausgekommen:
erstes Script:
diese ausgabe bringt uns nicht weiter da wir immer noch keinen SSH Zugriff auf die Vmware weder im NAT noch im Host-Only Modus erhalten!
zweites script:
Diese Ausgabe klingt plausiebel jedoch dennoch nicht funktionsfähig:
Bei dem ersten Script kam keinerlei Output von
Das zweite Script gab diese Ausgabe von
So nun verwundert mich als Admin eigendlich nur noch eines: Warum habe ich in der letzen Ausgabe keine Source sowie Destination ??
Mehrere Konstelationen habe ich schon durch, das würde den ohnehin schon langen Post nochmals verlängern
Ich habe auch schon nach einem Modul für iptables gesucht welches den kompletten IP Stack FORWARDEN würde. Gemeint ist mit IP Stack jeglicher Verkehr der über TCP sowie UDP gesendet würde.
An die Sicherheitsfreaks unter uns :-P die Vmwares werden vor dem "Online-Gang" einer Prüfung unterzogen um das Allgemeinwohl zu schützen :-P
Vielen Dank im Vorraus an die Leute die es bis zum Ende durchgehalten haben
Mit freundlichen Grüßen
Euer NySoft Team
Wir haben uns mit der von Wladi750 angesprochen Thematik außeinander gesetzt. -> THEMA
Nun ist ein Debian Minimal auf unserem RootServer samt VMWare-Server 2.0.1 im Betrieb.
Unser RootServer besitzt 3 IPs welche momentan alle auf ein und die selbe MAC im Rechenzentrum zeigen.
Aktuell befinden sich alle VMs auf Host-Only.
Ganz grob ist unser Ziel: Eine IP auf eine VM legen zu können. Bridged ist NICHT möglich dank dem Aufbau im Rechenzentrum von 1&1!!!
Aktuell sieht unsere /etc/network/interfaces so aus:
eth0 Link encap:Ethernet HWaddr 00:XX:XX:XX:XX
inet addr:87.xxx.xxx.xxx.xxx Bcast:87.xxx.xxx.xxx.xxx Mask:255.255.255.255
inet6 addr: fe80::219:XXXX:XXXX:XXXX/XX Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:109810 errors:0 dropped:0 overruns:0 frame:0
TX packets:32674 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14228060 (13.5 MiB) TX bytes:6972509 (6.6 MiB)
Interrupt:20
eth0:0 Link encap:Ethernet HWaddr 00:XX:XX:XX:XX
inet addr:87.xxx.xxx.xxx.001 Bcast:87.xxx.xxx.xxx.001 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:20
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:24423 errors:0 dropped:0 overruns:0 frame:0
TX packets:24423 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:23205390 (22.1 MiB) TX bytes:23205390 (22.1 MiB)
vmnet1 Link encap:Ethernet HWaddr 00:50:56:C0:00:01
inet addr:172.16.122.129 Bcast:172.16.122.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:320 errors:0 dropped:0 overruns:0 frame:0
TX packets:1347 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
vmnet8 Link encap:Ethernet HWaddr 00:50:56:C0:00:08
inet addr:192.168.214.130 Bcast:192.168.214.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:474 errors:0 dropped:0 overruns:0 frame:0
TX packets:466 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)Eine Variante unsere Iptables zu erstellen seht ihr hier:
#!/bin/bash
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -F
iptables -A FORWARD -i eth0 -o vmnet1 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i vmnet1 -o eth0 -j ACCEPT
iptables -A FORWARD -j LOG
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
#iptables -A FORWARD -i eth0 -o vmnet1 -p tcp --dport 22 -j ACCEPT
#iptables -A PREROUTING -t nat -i eth0 -p tcp -d 87.XXX.XXX.XXX --dport 25 -j DNAT --to 192.168.214.128:22wiederum eine andere Variante die uns ein Freudiger Mitarbeiter unserer Firma zukommen lies ( "anscheinden" unter Ubuntu 6.04 Dapper lauffähig ) seht ihr hier:
#iptables -t nat -A POSTROUTING -s 172.16.122.128 -o eth0 -j MASQUERADE
#iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-dest 172.16.122.128 -d 87.XXX.XXX.XXX
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j DNAT --to-dest 172.16.122.128 -d 87.XXX.XXX.XXX
#iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 21 -j DNAT --to-dest 172.16.122.128 -d 87.XXX.XXX.XXX
#echo "iptables -L"
#echo performance | tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
#echo performance | tee /sys/devices/system/cpu/cpu1/cpufreq/scaling_governorDiese beiden Varianten haben wir ausprobiert und dabei ist beim ersten script folgendes herausgekommen:
erstes Script:
s15asdbasd:/home/scripts# iptables -t nat -n -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT 0 -- 0.0.0.0/0 87.XXX.XXX.XXX to:172.16.122.128
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:25
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:25
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:25
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:172.16.122.128:22
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:172.16.122.128:22
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:25
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:25
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:22
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:22
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:192.168.214.128:22
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:192.168.214.128
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:192.168.214.128
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:192.168.214.128
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:192.168.214.128
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:192.168.214.128:22
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:172.16.122.128
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:172.16.122.128
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT 0 -- 172.16.122.128 0.0.0.0/0 to:87.XXX.XXX.XXX
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
SNAT 0 -- 172.16.122.128 0.0.0.0/0 to:87.XXX.XXX.XXX
SNAT 0 -- 172.16.122.128 0.0.0.0/0 to:87.XXX.XXX.XXX
SNAT 0 -- 172.16.122.128 0.0.0.0/0 to:87.XXX.XXX.XXX
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 192.168.214.128 0.0.0.0/0
MASQUERADE 0 -- 192.168.214.128 0.0.0.0/0
MASQUERADE 0 -- 192.168.214.128 0.0.0.0/0
MASQUERADE 0 -- 192.168.214.128 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0diese ausgabe bringt uns nicht weiter da wir immer noch keinen SSH Zugriff auf die Vmware weder im NAT noch im Host-Only Modus erhalten!
zweites script:
s1asdasdwqer:/home/scripts# iptables -t nat -n -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT 0 -- 0.0.0.0/0 87.XXX.XXX.XXX to:172.16.122.128
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:25
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:25
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:25
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:172.16.122.128:22
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:172.16.122.128:22
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:25
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:25
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:22
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:172.16.122.128:22
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:192.168.214.128:22
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:192.168.214.128
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:192.168.214.128
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:192.168.214.128
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:192.168.214.128
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:192.168.214.128:22
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:172.16.122.128
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:22 to:172.16.122.128
DNAT tcp -- 0.0.0.0/0 87.XXX.XXX.XXX tcp dpt:25 to:192.168.214.128:22
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT 0 -- 172.16.122.128 0.0.0.0/0 to:87.XXX.XXX.XXX
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
SNAT 0 -- 172.16.122.128 0.0.0.0/0 to:87.XXX.XXX.XXX
SNAT 0 -- 172.16.122.128 0.0.0.0/0 to:87.XXX.XXX.XXX
SNAT 0 -- 172.16.122.128 0.0.0.0/0 to:87.XXX.XXX.XXX
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 192.168.214.128 0.0.0.0/0
MASQUERADE 0 -- 192.168.214.128 0.0.0.0/0
MASQUERADE 0 -- 192.168.214.128 0.0.0.0/0
MASQUERADE 0 -- 192.168.214.128 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
MASQUERADE 0 -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destinationDiese Ausgabe klingt plausiebel jedoch dennoch nicht funktionsfähig:
Bei dem ersten Script kam keinerlei Output von
iptables -L iptables -L s15adsaqewwe:/home/scripts# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT 0 -- anywhere anywhere
LOG 0 -- anywhere anywhere LOG level warning
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
Chain OUTPUT (policy ACCEPT)
target prot opt source destinationSo nun verwundert mich als Admin eigendlich nur noch eines: Warum habe ich in der letzen Ausgabe keine Source sowie Destination ??
Mehrere Konstelationen habe ich schon durch, das würde den ohnehin schon langen Post nochmals verlängern
Ich habe auch schon nach einem Modul für iptables gesucht welches den kompletten IP Stack FORWARDEN würde. Gemeint ist mit IP Stack jeglicher Verkehr der über TCP sowie UDP gesendet würde.
An die Sicherheitsfreaks unter uns :-P die Vmwares werden vor dem "Online-Gang" einer Prüfung unterzogen um das Allgemeinwohl zu schützen :-P
Vielen Dank im Vorraus an die Leute die es bis zum Ende durchgehalten haben
Mit freundlichen Grüßen
Euer NySoft Team
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 115243
Url: https://administrator.de/forum/1und1-debian-minimal-iptables-forward-on-vmware-server-2-0-1-host-only-nat-115243.html
Ausgedruckt am: 25.12.2024 um 14:12 Uhr
6 Kommentare
Neuester Kommentar
Hallo NySoft Team,
um den Zugriff per SSH auf den RootServer nutze ich die Freeware Software von PuTTY.
Der Port 22 muss in der Firewall Einstellungen freigegeben sein.
In Deiner Konfiguration fehlt noch einiges.
In der VMWare soll die Schnittstelle vmnet1 im NAT Modus eingerichtet werden, das ist dann auch der Gateway.
Zwei Script sollen eingerichtet werden:
iptables
#!/bin/sh
iptables -t nat -I PREROUTING -d 87.106.90.62 -j DNAT --to 192.168.1.2
iptables -t nat -I PREROUTING -d 87.106.90.63 -j DNAT --to 192.168.1.3
iptables -t nat -I PREROUTING -d 87.106.90.64 -j DNAT --to 192.168.1.4
iptables -t nat -I PREROUTING -d 192.168.1.2 -j SNAT --to 87.106.90.62
iptables -t nat -I PREROUTING -d 192.168.1.3 -j SNAT --to 87.106.90.63
iptables -t nat -I PREROUTING -d 192.168.1.4 -j SNAT --to 87.106.90.64
Die Öffentlichen IP-Adressen müssen zu den Virtuellen NICs zugewiesen werden
network
#!/bin/sh
ifconfig eth0:0 87.106.85.20 (hier wird die Öffentliche IP Adresse eingetragen, mit der Du auf den RootServer zugreifst)
ifconfig eth0:1 87.106.90.62 (hier wird die weitere Öffentliche IP Adresse eingetragen, die nachträglich bestellt wurde)
ifconfig eth0:2 87.106.90.63 --- # ---
ifconfig eth0:3 87.106.90.64 --- # ---
route add 87.106.85.20 eth0:0
route add 87.106.90.62 eth0:1
route add 87.106.90.63 eth0:2
route add 87.106.90.63 eth0:3
Mit dem Befehl -yast- unter SSH gelangt man in die Firewall / Masquerading.
Immer die Schnittstelle eth 0:1 verwenden, mit dem entsprechenden Port für Remotezugriff.
Als letztes soll die Firewall aktiviert werden.
Danach sollen die NICs entsprechen aussehen:
s15327523:~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:28:85:C5:9C:35
inet addr:87.106.85.20 Bcast:87.106.85.20 Mask:255.255.255.255
inet6 addr: fe80::221:83ff:fec2:9c35/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8816645 errors:0 dropped:0 overruns:0 frame:0
TX packets:10274122 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1602013740 (1527.7 Mb) TX bytes:9826799369 (9371.5 Mb)
Interrupt:252 Base address:0x8000
eth0:0 Link encap:Ethernet HWaddr 00:28:75:C5:9C:35
inet addr:87.106.85.20 Bcast:87.255.255.255 Mask:255.0.0.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:252 Base address:0x8000
eth0:1 Link encap:Ethernet HWaddr 00:28:85:C5:9C:35
inet addr:87.106.90.62 Bcast:87.255.255.255 Mask:255.0.0.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:252 Base address:0x8000
eth0:2 Link encap:Ethernet HWaddr 00:28:85:C5:9C:35
inet addr:87.106.90.63 Bcast:87.255.255.255 Mask:255.0.0.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:252 Base address:0x8000
eth0:3 Link encap:Ethernet HWaddr 00:28:85:C5:9C:35
inet addr:87.106.90.64 Bcast:87.255.255.255 Mask:255.0.0.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:252 Base address:0x8000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:56186 errors:0 dropped:0 overruns:0 frame:0
TX packets:56186 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:49455188 (47.1 Mb) TX bytes:49455188 (47.1 Mb)
vmnet1 Link encap:Ethernet HWaddr 00:50:56:C0:00:01
inet addr:192.168.3.1 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7239751 errors:0 dropped:0 overruns:0 frame:0
TX packets:4422085 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Jetzt soll der Remotezugriff möglich sein.
Viel Erfolg
Wladi750
um den Zugriff per SSH auf den RootServer nutze ich die Freeware Software von PuTTY.
Der Port 22 muss in der Firewall Einstellungen freigegeben sein.
In Deiner Konfiguration fehlt noch einiges.
In der VMWare soll die Schnittstelle vmnet1 im NAT Modus eingerichtet werden, das ist dann auch der Gateway.
Zwei Script sollen eingerichtet werden:
iptables
#!/bin/sh
iptables -t nat -I PREROUTING -d 87.106.90.62 -j DNAT --to 192.168.1.2
iptables -t nat -I PREROUTING -d 87.106.90.63 -j DNAT --to 192.168.1.3
iptables -t nat -I PREROUTING -d 87.106.90.64 -j DNAT --to 192.168.1.4
iptables -t nat -I PREROUTING -d 192.168.1.2 -j SNAT --to 87.106.90.62
iptables -t nat -I PREROUTING -d 192.168.1.3 -j SNAT --to 87.106.90.63
iptables -t nat -I PREROUTING -d 192.168.1.4 -j SNAT --to 87.106.90.64
Die Öffentlichen IP-Adressen müssen zu den Virtuellen NICs zugewiesen werden
network
#!/bin/sh
ifconfig eth0:0 87.106.85.20 (hier wird die Öffentliche IP Adresse eingetragen, mit der Du auf den RootServer zugreifst)
ifconfig eth0:1 87.106.90.62 (hier wird die weitere Öffentliche IP Adresse eingetragen, die nachträglich bestellt wurde)
ifconfig eth0:2 87.106.90.63 --- # ---
ifconfig eth0:3 87.106.90.64 --- # ---
route add 87.106.85.20 eth0:0
route add 87.106.90.62 eth0:1
route add 87.106.90.63 eth0:2
route add 87.106.90.63 eth0:3
Mit dem Befehl -yast- unter SSH gelangt man in die Firewall / Masquerading.
Immer die Schnittstelle eth 0:1 verwenden, mit dem entsprechenden Port für Remotezugriff.
Als letztes soll die Firewall aktiviert werden.
Danach sollen die NICs entsprechen aussehen:
s15327523:~ # ifconfig
eth0 Link encap:Ethernet HWaddr 00:28:85:C5:9C:35
inet addr:87.106.85.20 Bcast:87.106.85.20 Mask:255.255.255.255
inet6 addr: fe80::221:83ff:fec2:9c35/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8816645 errors:0 dropped:0 overruns:0 frame:0
TX packets:10274122 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1602013740 (1527.7 Mb) TX bytes:9826799369 (9371.5 Mb)
Interrupt:252 Base address:0x8000
eth0:0 Link encap:Ethernet HWaddr 00:28:75:C5:9C:35
inet addr:87.106.85.20 Bcast:87.255.255.255 Mask:255.0.0.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:252 Base address:0x8000
eth0:1 Link encap:Ethernet HWaddr 00:28:85:C5:9C:35
inet addr:87.106.90.62 Bcast:87.255.255.255 Mask:255.0.0.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:252 Base address:0x8000
eth0:2 Link encap:Ethernet HWaddr 00:28:85:C5:9C:35
inet addr:87.106.90.63 Bcast:87.255.255.255 Mask:255.0.0.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:252 Base address:0x8000
eth0:3 Link encap:Ethernet HWaddr 00:28:85:C5:9C:35
inet addr:87.106.90.64 Bcast:87.255.255.255 Mask:255.0.0.0
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:252 Base address:0x8000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:56186 errors:0 dropped:0 overruns:0 frame:0
TX packets:56186 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:49455188 (47.1 Mb) TX bytes:49455188 (47.1 Mb)
vmnet1 Link encap:Ethernet HWaddr 00:50:56:C0:00:01
inet addr:192.168.3.1 Bcast:192.168.3.255 Mask:255.255.255.0
inet6 addr: fe80::250:56ff:fec0:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7239751 errors:0 dropped:0 overruns:0 frame:0
TX packets:4422085 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Jetzt soll der Remotezugriff möglich sein.
Viel Erfolg
Wladi750
Such mal nach dem Skript vmware-config.pl, lass das laufen, fast alles bis zum networking mit ENTER bestätigen.
Bei der Network-Konfiguration von vmware die Nutzung von Host-Only-Networking mit YES bestätigen.
Danach die Suche nach freien Subnetzen verneinen.
Selbst eine eigene lokale Netzwerk-IP und Subnetz-Maske angeben.
Diese IP wird der Internet-Gateway und DNS-Server für die Guest-Systeme in vmware sein, daher am Besten sowas wie 192.168.2.1 wählen.
Als Subnetz-Maske kann man z.B. 255.255.255.0 nehmen.
Diese IP gehört nun zum vmnet1-Interface, welches die Schnittstelle zu den VMWare-Guest-Systemen bilden sollte.
Jetzt die Guest-Systeme in VMWare einrichten...
Netzwerk-Adapter für die einzelnen Systeme jeweils auf "Host-Only" stellen.
NICHT AUF bridged, sondern host-only, also "vmnet1" im Normalfall.
Statische IP-Adressen der Guest-Systeme konfigurieren.
Jedem VMWare-Guest-System eine lokale freie Netzwerk-IP wählen (z.B. 192.168.2.101 für Guest1, dann 192.168.2.102 für Guest2, etc.)
Die Subnetz-Maske vom Root-Server übernehmen (z.B. 255.255.255.0).
Als Gateway- und DNS-Server-IP in jedem Guest-System die IP vom vmnet1-Interface einstellen (nach obigem Beispiel 192.168.2.1)
/etc/sysctl.conf modifizieren:
Danach sollte ein:
und ein:
zum gewünschten Ziel verhelfen.
Mach ich immer so, schnurrt immer.
@Wladi:
WENN MAN KEINE AHNUNG HAT, EINFACH MAL DIE ...
YAST UNTER DEBIAN?
Lonesome Walker
PS: auch unter Windows wäre das zu machen gewesen...
Aber ich mach ja nur noch selten was, seit dem hier so viele Leute wie wladi rumgurken...
Bei der Network-Konfiguration von vmware die Nutzung von Host-Only-Networking mit YES bestätigen.
Danach die Suche nach freien Subnetzen verneinen.
Selbst eine eigene lokale Netzwerk-IP und Subnetz-Maske angeben.
Diese IP wird der Internet-Gateway und DNS-Server für die Guest-Systeme in vmware sein, daher am Besten sowas wie 192.168.2.1 wählen.
Als Subnetz-Maske kann man z.B. 255.255.255.0 nehmen.
Diese IP gehört nun zum vmnet1-Interface, welches die Schnittstelle zu den VMWare-Guest-Systemen bilden sollte.
Jetzt die Guest-Systeme in VMWare einrichten...
Netzwerk-Adapter für die einzelnen Systeme jeweils auf "Host-Only" stellen.
NICHT AUF bridged, sondern host-only, also "vmnet1" im Normalfall.
Statische IP-Adressen der Guest-Systeme konfigurieren.
Jedem VMWare-Guest-System eine lokale freie Netzwerk-IP wählen (z.B. 192.168.2.101 für Guest1, dann 192.168.2.102 für Guest2, etc.)
Die Subnetz-Maske vom Root-Server übernehmen (z.B. 255.255.255.0).
Als Gateway- und DNS-Server-IP in jedem Guest-System die IP vom vmnet1-Interface einstellen (nach obigem Beispiel 192.168.2.1)
/etc/sysctl.conf modifizieren:
net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
iptables -t nat -I PREROUTING -d 87.xxx.xxx.xxx -j DNAT --to 192.168.2.101und ein:
iptables -t nat -I POSTROUTING -s 192.168.2.101 -j SNAT --to 87.xxx.xxx.xxzum gewünschten Ziel verhelfen.
Mach ich immer so, schnurrt immer.
@Wladi:
WENN MAN KEINE AHNUNG HAT, EINFACH MAL DIE ...
YAST UNTER DEBIAN?
Lonesome Walker
PS: auch unter Windows wäre das zu machen gewesen...
Aber ich mach ja nur noch selten was, seit dem hier so viele Leute wie wladi rumgurken...
Wladi750 hat auf diesen Post geantwortet da wir ihn drum gebeten hatten.
Er hat in einem der vorherigen Themen uns Angeboten auf seine Lösung zurückgreifen zu können. Daher bitte kein böses Blut.
Aber danke für die schnelle Antworten an alle Beide.
Die Lösung von Wladi750 haben wir bereits getestet erfolglos. Leider.
Das es YAST unter Debian nicht gibt wissen wir. Das hat nur "Soße".
Die Antwort von "Lonesome Walker" werden wir heute Abend direkt ausprobieren. Wenn dies auch nicht klappt, melden wir uns wieder.
Na dann gib uns doch mal deine E-Mailadresse.
Vielen Dank nochmal.
MfG NySoft Team
Er hat in einem der vorherigen Themen uns Angeboten auf seine Lösung zurückgreifen zu können. Daher bitte kein böses Blut.
Aber danke für die schnelle Antworten an alle Beide.
Die Lösung von Wladi750 haben wir bereits getestet erfolglos. Leider.
Das es YAST unter Debian nicht gibt wissen wir. Das hat nur "Soße".
Die Antwort von "Lonesome Walker" werden wir heute Abend direkt ausprobieren. Wenn dies auch nicht klappt, melden wir uns wieder.
PS: auch unter Windows wäre das zu machen gewesen...
Aber ich mach ja nur noch selten was, seit dem hier so viele Leute wie wladi rumgurken...
Aber ich mach ja nur noch selten was, seit dem hier so viele Leute wie wladi rumgurken...
Na dann gib uns doch mal deine E-Mailadresse.
Vielen Dank nochmal.
MfG NySoft Team
Es geht nicht um böses Blut.
Es geht um Desinformation und Unwissen, GEFÄHRLICHES Unwissen...
Bei meinem Lösungsansatz habe ich noch vergessen, wie man die zusätzlichen IP's hinzufügt...
Das mit eth0:1, eth0:2, ... ist alles andere als toll, aber das wird man über kurz oder lang ja feststellen...
Lonesome Walker
Es geht um Desinformation und Unwissen, GEFÄHRLICHES Unwissen...
Bei meinem Lösungsansatz habe ich noch vergessen, wie man die zusätzlichen IP's hinzufügt...
Das mit eth0:1, eth0:2, ... ist alles andere als toll, aber das wird man über kurz oder lang ja feststellen...
Lonesome Walker
Das mit "Debian Minimal" habe ich überlesen, Sorry.
Wir nutzen den openSUSE 11 mit Parallels Plesk Panel 9 (64-Bit).
Durch die beschriebene Konfiguration habe ich drei Windows Server 2003 Standart x64 Guest-Systeme produktiv seit einem halben Jahr ohne Probleme am laufen.
@lonesome Walker: für eine bessere Lösung mit der IP´s Zuweisung währe ich Dir dankbar
P.S. Falls so ein Fehler (YAST unter Debian) in dem Forum auftaucht, erkennt es doch jeder, oder?
Wir nutzen den openSUSE 11 mit Parallels Plesk Panel 9 (64-Bit).
Durch die beschriebene Konfiguration habe ich drei Windows Server 2003 Standart x64 Guest-Systeme produktiv seit einem halben Jahr ohne Probleme am laufen.
@lonesome Walker: für eine bessere Lösung mit der IP´s Zuweisung währe ich Dir dankbar
P.S. Falls so ein Fehler (YAST unter Debian) in dem Forum auftaucht, erkennt es doch jeder, oder?
naja ob böses blut nun oder nicht, ich denke hilfreicher für alle die diesen post lesen wäre die lösung aller probleme:
die iptables ^^ ich werde morgen in aller frische dies alles nochmals detailiert durchgehen und eventuelle fehler bis jetzt ausmerzen... dannach werde ich mich wieder melden.
Meines Wissens nach ist eine Host-Only Umgebung mit den Virtuellen Interfaces keine schlechte idee.. Ich möchte kein doppeltes nat ( iptables / vmware ) betreiben, dabei geht ne menge performance mal eben so flöten... so wie wladi es oben beschrieben hat, ausgenommen nun ob es funktioniert oder nicht...
gn8 allerseitz
Ralph Schneider
Administration NySoft
die iptables ^^ ich werde morgen in aller frische dies alles nochmals detailiert durchgehen und eventuelle fehler bis jetzt ausmerzen... dannach werde ich mich wieder melden.
Meines Wissens nach ist eine Host-Only Umgebung mit den Virtuellen Interfaces keine schlechte idee.. Ich möchte kein doppeltes nat ( iptables / vmware ) betreiben, dabei geht ne menge performance mal eben so flöten... so wie wladi es oben beschrieben hat, ausgenommen nun ob es funktioniert oder nicht...
gn8 allerseitz
Ralph Schneider
Administration NySoft
