(Gelöst)VMWare-Server 2: Host Ubuntu 10.4 keine I-Verbindung

Hilfe bei Problemen mit der Installation oder Benutzung des VMware Server 2.

Moderatoren: irix, Dayworker

Member
Beiträge: 14
Registriert: 28.11.2009, 20:25

(Gelöst)VMWare-Server 2: Host Ubuntu 10.4 keine I-Verbindung

Beitragvon mike175de » 10.08.2011, 08:58

Hallo Commuinity,

vllt. hat einer eine Lösung, da ich inzwischen schier am verzweifeln bin und auch ü/die SuFu keine Lösung gefunden habe.

Zum Aufbau der VMWare-Lösung:
* VMWare-Server 2 ist auf einem Ubuntu 10.4 installiert. Die Netzwerkkarten (3x) sind alle gebridged (kein NAT o.ä.) und im Host über die /etc/netwok/interface festen IP-Adressen zugeordnet.
* Als Gast ist die IPFire-FW-Lösung installiert. Diese benutzt alle drei NICs in folgender Konstellation: eth0 als green für das interne Netzwerk, eth1 als red zur Einwahl ins I-Net und eth2 als blue für den WLAN-Bereich.

Zum Problem:
Ich bekomme im Host-System keine I-Net-Verbindung zustande, obwohl ich im Netzwerk die Guest-IPFire-Lösung anpingen kann und auch das Webinterface ü/ https://...:8333 aufrufen kann. Die I-Net-Verbdinugn wird vom IPFire sauber aufgebaut und steht auch zur Verfügung (z.B. im IPFire-Update bereich getestet). Auch eine zweite Guest-Lösung (Mailserver) kommt ohne Probleme ins I-Net.
Nameserver sind in der resolv.conf auf die IP-Adresse von eth0 dem green-NIC des IPFire eingestellt.

Versuchte Lösungen:
* Wenn ich im Firefox die Proxy-Einstellungen auf den IPFire setze, kann ich ins I-Net - soweit so gut. Jedoch ist dann z.B. ü/apt-get update keine I-Net-Verbindung im Gesamtsystem möglich. Deswegen:
* Allgemeinen Proxy unter Netzwerk-Proxy (Gesamtsystem) eingestellt. Ergebnis keine Änderung, weiterhin kein Zugriff ins I-Net z.B. bei Nutzung von apt-get update.
* Innerhalb der von Synaptic unter Einstellungen den IPFire-Proxy eingestellt => Jetzt funktioniert z.B. apt-get update.

Wäre ja soweit auch akzeptabel, aber:
* Ich bekomme immer noch keine I-Net-Verbinidung meines Hosts z.B. bei der Installation der propriäteren Treiber (GraKa) oder bei der Nutzung von Thunderbird (trotz Proxy-Konfig innerhalb von TB). Auch sind z.B. Streaming-Angebote nicht erreichbar (trotz globaler Proxy-Nutzung von oben). Und wahrscheinlich funktionieren auch andere Sachen die eine I-Verbindung benötigen (und bei denen keine Proxy-Konfig möglich ist) nicht.

Vllt. hat jemand eine Idee woran es liegen könnte, dass ich trotz Proxy nicht "komplett" mit dem Host ins I-Net komme. Am liebsten wäre es mir ohne Proxy-Zwangsvorgabe.
Welche Conf-Dateien könnten da noch mitreinspielen? Evtl. auch IP-Tables (da kenn ich mich leider null aus).

Wäre für jede Idee mehr als dankbar.

VG, mike175de

Member
Beiträge: 16
Registriert: 05.03.2006, 00:50

Beitragvon mmuessig » 20.08.2011, 13:53

Hallo Mike,
ich verstehe deinen grundsätzlichen Ansatz nicht so ganz.

Du sagst, das Host System nutzt drei Netzwerk Karten, die jeweils ein Netz für unterschiedliche Zwecke bereitstellen sollen (WLAN, INET, INTERN).
Das klingt eigentlich danach, als wolltest du drei unterschiedliche Netze abbilden. Du sagst aber auch, dass die Karten gebridged sind...
Bridging ist ein Layer 2 Mechanismus, der voraussetzt, dass alle Netzwerk Interfaces innerhalb einer Bridge, auch im selben Layer 3 Netz sind (IP Adressen aus dem selben Segement haben).

Z.B. Intern: 192.168.10.0/24, WLAN: 192.168.20.0/24, INET: 192.168.30.0/24 (Das INET Netz würde dann, neben dem Firewall Interface, z.B. noch ein internes Interface deines DSL Routers, oder welches Device auch immer deinen Internet Zugang terminiert, haben).

Oder meinst du mit "bridge" die virtuellen Interfaces der Guest Systeme. Diese sind dann hoffentlich zu genau EINEM physikalischen Interface gebridged, nämlich zu dem, in dessen Netz dein Guest System hingehört.

Vielleicht kannst du bezüglich Netzwerk, Guest-Systeme, etc. noch etwas genauer werden. Denn "Troubleshooting" ohne Kenntnis des Netz Aufbaus ist nicht wirklich effizient ;-)

Grundsätzliche Tipps wären (und die funktionieren unter den auch hier gelisteten Annahmen):
-------------------------------------------------- ANNAHMEN --------------------------------------------------
- Jedes Guest System hat ein Default Gateway eingetragen
- Jedes Guest System hat eine IP (Statisch oder per DHCP)
- Ich gehe davon aus, dass Guest Systeme in WLAN oder INTERN als Default Gateway die Firewall eingetragen haben?
- Die Firewall hat drei Interfaces (virtuelle), von denen jeweils eines auf genau ein pyhsikalisches gebridged ist

-------------------------------------------------- Vorschläge zum Troubleshooting (alle von einem Guest!!!) --------------------------------------------------
- Ping von einem Guest X (z.B. aus dem internen Netzwerk Segment) auf die Default Gateway IP (wenn der geht gut, wenn nicht, siehe nächster Punkt)
- Wenn der Ping nicht geht: ARP Tabelle anschauen. Das ist die erste Stelle, an der man L2 Probleme schnell findet (wie das geht, siehe ganz unten)
- Wenn der Ping geht:Gib den Ping ins Internet auf der Firewall frei (Test des Routings!) und pinge einen Server im Internet an (z.B. ping www.heise.de)
- Auch DNS kann ein Grund sein, weshalb Ping oder andere Tests fehlschlagen. nslookup (Windows/Linux) oder host (Linux) helfen hier (z.B. nslookup www.heise.de)
- Wenn der Ping nicht geht, hast du ein Problem auf der Firewall (Regelwerk oder Routing) oder auf einem weiteren Router, der ggfs. existiert
- Wenn der Ping geht, bist du ein großes Stück weiter (Ping testet nicht die Kommunikation über den Proxy, sondern nur L3 Routing und ggfs. die Firewall Policy für ICMP)
- Dann versuche Zugriffstests, die einen Proxy benötigen (z.B. apt-get unter Linux oder eine Webseite über den Browser) (SIEHE UNTEN)
- Ping nutzt keinen Proxy!!!
- Schau dir dann die Logdateien der Firewall an. Siehst du die Pakete deiner Test Kommunikation? Werden die vielleicht verworfen?
- Vergewissere dich, dass zunächst für deine Tests, alle Regeln in deiner Firewall auch die Logging-Option aktiviert haben!!!
- Schau dir auch mit dem Traceroute (Linux) oder tracert (Windows) Kommando an, welchen Weg die Pakete nehmen (z.B. traceroute www.heise.de) (gehen die Pakete über die Firewall???)
- Tracert/Traceroute nutzt keinen Proxy


ARP Tabelle:
- Unter Windows und Linux: arp -a
--> Die ARP Tabelle sagt dir für jedes Interface des Rechners, ob zu einer IP (IPs im selben Netz!!!) auch eine MAC Adresse bekannt ist. Wenn nicht, hast du ein L2 Problem
--> Achtung: ARP Einträge findest du erst nachdem auch eine Kommunikation zu einer Zieladresse statt gefunden hat (deshalb der Ping vor dem ARP-Test)

PROXY:
Wenn du einen Proxy für alle deine Kommunikation nutzt, kannst du dir überlegen, ob du den Client Guest Systemen wirklich eine Default Route geben willst (Sicherheit!!!) und ob du auf der Firewall Quell IP Adressen, die nicht der Proxy sind, überhaupt in Richtung Internet freischaltest!
Der Proxy als Quell-IP muss in der Firewall für alle Ziel Adressen im Internet frei geschaltet sein. HTTP/HTTPS über den Proxy ist OK. Es gibt Protokolle, die will man nicht über den Proxy fahren, weil sie dafür nicht gemacht wurden (FTP ist z.B. ziemlich hässlich)
Proxy Verwendung über den Proxy Eintrag im Browser. Manche Programme schauen im Browser nach Proxy Einstellungen und verwenden diese, in manchen kann man direkt einen Proxy eintragen.
Dann gibt es die dritte Gruppe von Programmen.
- Unter Windows oder LInux lesen die z.B. eine Proxy Variable (HTTP_PROXY) aus.
- set proxy Kommando um den Proxy für WinHTTP (Windows Web Client Service)


So, das war viel. Versuche mal, damit weiterzukommen. Mit mehr Netzwerk Details kann man sicher auch noch mehr helfen...

Gruß,
Markus

Member
Beiträge: 16
Registriert: 05.03.2006, 00:50

Beitragvon mmuessig » 20.08.2011, 13:55

Kleine Anmerkung noch:

Die Troubleshooting Hinweise gelten natürlich nicht nur im VMWare Umfeld.

Die kannst du auch auf deinem Host System nutzen. Selbes gilt für die Hinweise zum Thema Bridging. Bridging ist keine VMWare Eigenheit. Das ist Netzwerk Standard Thema...

Gruß

King of the Hill
Beiträge: 13572
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 20.08.2011, 19:42

Keine Ahnung was du gemacht hast, aber die VMware-Bridge bekommt eigentlich keine IP-Adresse. Die VMware-Bridge dient auch nur dazu, um die Nic in den Promiscuous mode zu versetzen, damit die Nic auch eigentlich nicht für sie bestimmte Netzwerkpakete empfängt. Die Nic wird also entgegen der VMware-Aussage eines Switches in ein Hub umgewandelt.


PS: Wie hast du überhaupt den VMserver2 unter *buntu10.4 mit welcher Kernel-Version installiert bekommen?
Ohne Nachhilfe kommt auch der VMserver2.02 ja nicht über die Kernel-Version 2.6.27 hinaus...

Member
Beiträge: 14
Registriert: 28.11.2009, 20:25

gelöst: Default-Route gesetzt

Beitragvon mike175de » 21.08.2011, 08:56

Hallo,

besten Dank für eure Anmerkungen. Konnte zwischenzeitlich den Fehle beheben indem ich meiner internen Karte eine Default-Route auf meinen IPFire-Router gesetzt habe.

Für alle mit einem ähnlichen Problem:

Code: Alles auswählen

sudo route add default gw 192.168.x.xx


@Dayworker:
Mit dieser Anleitung bringst du den VMWare-Server 2 mit aktuellem Kernel 2.6.32-33 zum Laufen:

Code: Alles auswählen

http://hmontoliu.blogspot.com/2010/04/installing-vmware-server-202-in-ubuntu.html


VG, mike175de

King of the Hill
Beiträge: 13572
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: gelöst: Default-Route gesetzt

Beitragvon Dayworker » 21.08.2011, 20:44

mike175de hat geschrieben:Mit dieser Anleitung bringst du den VMWare-Server 2 unter Ubuntu10.4 mit aktuellem Kernel 2.6.32-33 zum Laufen:

Code: Alles auswählen

http://hmontoliu.blogspot.com/2010/04/installing-vmware-server-202-in-ubuntu.html


VG, mike175de

Danke für den Hinweis. Das nehm ich so mit in den Sticky-Thread Probleme mit VMware Server2? - erst lesen - dann posten auf.


Zurück zu „VMserver 2“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 8 Gäste