-uLtrA-

Ich meinte 1.0.6 (sorry!)

Hallo admins, ich habe einen Windows Server 2008 aufgesetzt. (Noch keine Rollen / Features installiert) es läuft bisher nur RemoteDesktop. Nun hatte ich Vmware Server 1.0.5 (aktuellste) installiert und wollte mich verbinden. Allerdings meckert Windows, er konnte die Dienste nicht starten: Der Dienst "VMware vmx86" wurde aufgrund folgenden Fehlers nicht gestartet: Die digitale Signatur dieser Datei kann nicht überprüft werden. Bei einer vor Kurzem durchgeführten Änderung an Hardware oder Software wurde möglicherweise eine Datei installiert, die falsch signiert oder beschädigt ist. Möglicherweise handelt es sich auch um schädliche Software einer unbekannten Quelle. (So geht es auch mit allen anderen Modulen von Vmware, kein einziges konnte gestartet werden) Wenn ich etwas per Hand über "Dienste" starten möchte: Fehler 1069: Der Abhängigkeitsdienst oder die Abhängigkeitsgruppe konnte nicht gestartet werden. --------------------- Ich bin eher ein Linuxmensch und habe nicht gerade viel Windows Ahnung, ich vermute dies ist was ganz simples, irgendetwas aktivieren was "nicht signierte Dateien" ausführen lässt? Ich habe schon nach den Fehlern gegooglet aber die Antworten passen leider überhaupt nicht zu meinem Problem. Ich wurde während der Installation auch gewarnt, das der Treiber "unbekannt" ist, habe aber gesagt er solle diesen trotzdem installieren. (Deinstallation/Neuinstallation auch schon versucht) (Hardware wurde nichts geändert) Ich hoffe hier kann mir vielleicht jemand helfen. Was könnte ich den noch probieren? Danke & Gruß Jens

ok danke für den Hinweis, dann kommt morgen noch eine Skizze! Hab mein bestes versucht beim Schreiben, ist eben immer etwas schwierig zu erklären gruß Jens

Hallo Community, (Sorry für den Doppelpost, ich kann leider nicht meinen Thread weiter unten editieren?) Da ich auf neue Erkenntnisse stoß, möchte ich es hier nochmal versuchen: ich hänge im Moment an einem sehr bescheidenem Routing Problem bei Linux. Mein Szenario schaut so aus: - Firewall Appliance - Webserver Das Problem derzeit ist, das wir in Performance Engpässe an der Firewall Appliance haben und uns aus Kostengründen dazu entschieden haben den Webserver mit einem Uplink direkt von der DMZ in das Internet zu hängen. (Natürlich später mit IPTable Firewall versehen das nur http Traffic erlaubt ist) Nun hat also die Firewall mehrere öffentliche Adressen an sich gebunden, ebenso die in Betrieb genommene (eth1) Schnittstelle des Webservers. Weiterhin besteht am Server (eth0) die Schnittstelle in das interne Netzwerk (172.16.32.2) worüber Datenbanktraffic und weiterhin ein FTP-Server über die Firewall laufen soll. Da liegt das Problem, aufgrund der externen Anbindung musste ich auf eth1 den öffentlichen Gateway als default Gateway definieren. Um mein internes Netzwerk zu erreichen habe ich natürlich einfach eine entsprechende Route geaddet. Nun passiert leider folgendes Der FTP-Server ist voll funktionstüchtig, intern ohne Probleme verbindungsbereit. Nun, wenn ich aber den Weg über die Firewall (dort habe ich eine neue öffentliche Adresse genommen und diese lasse ich es in die DMZ NAT’n) kommt keine Antwort zurück. Das NAT etc. funktioniert 100% korrekt. Ich hatte einen tcpdump gemacht und festgestellt dass der FTP-Server einfach nicht mehr antwortet! Er empfängt drei Pakete, tut nichts und mein Client bringt einen Fehler. 20:11:53.200870 IP (tos 0x0, ttl 122, id 32519, offset 0, flags [DF], proto: TCP (6), length: 48) p57B0698B.dip.t-dialin.net.2292 > 172.16.32.2.ftp: S, cksum 0x8891 (correct), 2721759840:2721759840(0) win 65535 <mss 1360,nop,nop,sackOK> Es liegt sehr Nahe bzw. das Problem muss daran liegen das er denkt er müsste die eth1 (öffentliche Schnittstelle) zum antworten benutzen. Macht er auch nicht laut tcpdump, er macht einfach gar nichts. Was ja so oder so falsch wäre. Ich habe also weiterprobiert und mich entschlossen, spaßeshalber mal folgendes einzutragen: route add -host 87.176.87.46 gw 172.16.32.1 Das war zu dem damaligen Zeitpunkt meine IP-Adresse (sieht man schön im tcpdumplog). Was passierte? Natürlich konnte ich mich verbinden! Das ganze half also, es funktionierte. So einfach ist es ja leider doch nicht, da der Webserver noch da ist wo über die andere Schnittstelle geht, ich bin ja nicht der einzige der sich verbinden will. Ich habe also weitergesucht, Stichwort: „Portbasiertes Routing Linux“ Ich stoß auf eine Netfilter Anleitung http://lartc.org/lartc.html#LARTC.NETFILTER Das schien für mich genau das richtige zu sein! Nämlich das man entscheiden kann welche Schnittstelle welches Protokoll benutzen darf. Das Problem ist, es funktioniert nicht, was auch darin liegen könnte das der dort beschriebene IPTables Befehl eine Fehlermeldung bringt iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 21 -j MARK --set-mark 1 –v Dieser Output: MARK tcp opt -- in eth0 out * 0.0.0.0/0 -> 0.0.0.0/0 tcp dpt:21 MARK set 0x1 iptables: Invalid argument Leider bin ich kein IPTables-Guru und kann den Fehler „Invalid Argument“ einfach nicht lösen. Ich nutze Debian 4.0 Etch. Spasseshalber auf einem meiner Debian 3.1 System ausprobiert. Dort bekomme ich kein „Invalid Argument“ zurück. Ich habe also trotz dieser Fehlermeldung alles weitere getan um die Pakete „zu markieren“ und darauf gehofft das es funktionieren würde. Negativ! Jedenfalls bin ich mittlerweile am Ende meines „Latein’s“ Ich würde mich sehr freuen wenn jemand Lösungsvorschläge für mich hätte. gruß, Jens

Hi Leute, um es auf den Punkt zu bringen, ich komme so nicht weiter. Wie immer erkläre ich mein Szenario -> Hardware Firewall (1 Internet Uplink, DMZ Bereich, Interner Bereich) -> Webserver (http + ftp) (IP: 172.16.32.2) Im Normalfall sollte ja aller Traffic über die Hardware Firewall Appliance gehen, das Problem ist leider das diese Hardware Firewall völlig überlastet mit Verbindungen ist, daher waren wir gezwungen, eine zweite Schnittstelle des Webservers in Betrieb zu nehmen die wir mit einer öffentlichen IP versehen und direkt ohne Firewall von der DMZ ins Internet lassen. Hat Geldtechnische Gründe, daher kann ich das leider nicht ändern. Geplant war also: http Traffic über die öffentliche Schnittstelle am Server durchzulassen den Rest per IPTables komplett zu verbieten auf dieser Schnittstelle. Nun läuft aber auf der Maschine noch ein FTP-Server. Dieser sollte weiterhin über einen Application-Layer-Filter über die Hardware durch die interne Schnittstelle geschleust werden. Und da liegt der Hund begraben Webserver: eth0: 172.16.32.2 (ftp und interne Angelegenheiten wie Datenbank etc.) eth1: 193.xx.xx.xx (später nur http erlauben) Man sollte ja nur 1x defaultgateway definieren, ich musste daher das Gateway vom öffentlichen Bereich eintragen (Schnittstelle eth1) eth0 hatte nun keinen Gateway mehr um von der DMZ in meinen internen Bereich zu routen habe ich eine simple Route hinzugefügt. Die IP 172.16.32.1 ist mein eigentlicher Gateway für interne Dinge. Ok folgendes beim Thema FTP: Ich habe also an meiner Hardware Firewall mehrere öffentliche IP's gebunden die ins interne Netz geNAT'et werden. Funktion einwandfrei. Nungut ich habe also eine Regel an meiner Firewall die besagt: Alles was von 193.xx.xx.10 (FTP) reingeht an meinen Server 172.16.32.2 weitergereicht wird. Nun das Problem ist, mein Server antwortet nicht zurück. Tcpdumpmässig schaut das leider nur so aus: 20:11:53.200870 IP (tos 0x0, ttl 122, id 32519, offset 0, flags [DF], proto: TCP (6), length: 48) p57B0698B.dip.t-dialin.net.2292 > 172.16.32.2.ftp: S, cksum 0x8891 (correct), 2721759840:2721759840(0) win 65535 <mss 1360,nop,nop,sackOK> 20:11:56.102701 IP (tos 0x0, ttl 122, id 32570, offset 0, flags [DF], proto: TCP (6), length: 48) p57B0698B.dip.t-dialin.net.2292 > 172.16.32.2.ftp: S, cksum 0x8891 (correct), 2721759840:2721759840(0) win 65535 <mss 1360,nop,nop,sackOK> 20:12:02.138010 IP (tos 0x0, ttl 122, id 32680, offset 0, flags [DF], proto: TCP (6), length: 48) p57B0698B.dip.t-dialin.net.2292 > 172.16.32.2.ftp: S, cksum 0x8891 (correct), 2721759840:2721759840(0) win 65535 <mss 1360,nop,nop,sackOK> Wiegesagt die Regeln für das NAT sind 100% korrekt! Ich vermute nur sehr stark das, da eine öffentliche IP anfrägt am FTP (siehe Log, das war ich z.b. von daheim..) das dieser zwar an der eth0 (interne Schnittstelle ankommt) ABER da eine öffentliche IP anfrägt, mein blöder Server denkt er müsse die Antwort über eth1 (öffentliche Schnittstelle) rausrouten und sie verschwindet im Nirvana. Was kann ich also tun? Es handelt sich lediglich um FTP Traffic..der muss über das interne Interface wieder zurück wo er herkam

wow Danke! Haben uns nur mittlerweile für eine Appliance entschieden und ein richtigen Hardware Firewall Router bestellt. Ist mir ehrlich gesagt auch lieber gruß Jens

nein eth0 ist dicht. bzw. ausgestöpselt

Hallo nochmal, noch eine Frage, da muss es doch sicher schon was fertiges geben? Sowas wie m0n0wall (ipcop) Allerdings nicht dediziert.. Ich habe zwar einiges jetzt hinbekommen, hänge allerdings noch beim connecten von "innen" nach draußen. Beispiel: Mailserver: eth0 : öffentliche IP eth1: 192.168.0.2 ip_forward 1 (Dient auch als VPN Gateway (virtuelle Route 10.8.0.0/24) Blöhda interner DB-Server eth1: 192.168.0.4 Routingeintrag das er alle Anfragen die 10.8.0.0/24 betreffen über den gateway 192.168.0.2 schicken soll. (Funktioniert prima! Beispiel: ssh Connection mit meinem VPN-Client daheim) Da dieser Server keine Schnittstelle bzw. öffentliche IP besitzt kann er keine Anfragen nach draußen senden. Ich hatte gedacht, das es ausreicht wenn ich unter interfaces gateway 192.168.0.2 reinschreibe. Allerdings gehen trotzdem keine Pakete nach draußen. Habe ich etwas übersehen? Oder muss ich irgendwie noch eine Route eintragen? gruß Jens

Fand ich auch verwirrend....

Danke, die Erklärung klingt plausibel @lordy äh ja wieso eigentlich nicht.... Man man man... ich glaube ich brauch Urlaub o0 Hilfe... Augen auf beim Eierkauf Schönen Feierabend! Danke

Hallo, sorry, 2 Threads innerhalb von 24h ;-) Debian 4.0 Etch Bei Sarge ging das blöderweise noch problemlos. Und zwar wollte ich das mysql "generic RPM IA64" Paket installieren. (Bei anderen Paketen von mysql dasselbe Spiel) siehe Bild: RPM findet anscheinend überhaupt nichts? Aber woran liegt das, ich peil das nicht, es ist definitiv alles was er verlangt auf dem System. Die Frage warum ich genau dieses Paket zum laufen kriegen muss. - Itanium 2 Server mit X86_64 Architektur, dazu gibt es von mysql vorkompilierte Pakte die mit dem Intel Compiler kompiliert sind, wirkt sich performancetechnisch positiver aus als ein selbstkompiliertes mit dem gc++. Ich muss also unbedingt das Paket zum laufen bringen. Denn es gibt im Repository seit Etch keine 4.1er Pakete mehr (Ein Upgrade auf 5 ist mit unserer Applikation nicht möglich) Irgendwas mit Umgebungsvariablen verwurscheld? Für Hilfe wäre ich dankbar Achja, Alien konvertiert zwar in .deb aber dpkg --install tut so als ob alles erfolgreich war, hat aber im Endeffekt garnichts installiert. Früher bei meinen Sarge Systemen ging das komischerweise. gruß Jens

Danke Vork! Ja weil alles wollt ich jetzt auch nicht herrauslassen!

o0, sicher? Hab das schon an wegen VPN... mhh sicher das dass alles ist? Muss ich nochmal checken. Das wäre ja genial

Hallo Leute, ich stehe mal wieder vor einem kleinem Problemchen, ich finde keinen Ansatzpunkt, evtl kann mir wer weiterhelfen. Szenario: Alles Debian 4.0 Systeme Standort: Rechenzentrum Betrieb eines Switches, das 2x VLAN's hat. - extern (öffentliche IP-Adressen) - intern (ein intern benutzter Adressbereich) Webserver, Mailserver sind natürlich öffentlich drangeklatscht. Datenbankserver, Managment-Consolen (RSA von IBM) nur im internen VLAN, greife über VPN zu. Jetzt suche ich nach einer Möglichkeit wie ich einen Server der sowohl im internen als auch im externen VLAN einen Port hat so pimpen kann, das er als Router dient. (nein ich suche nicht sowas wie m0n0wall oder IPcop) Das Gerät soll das nur nebenbei machen, also keine dedizierte Sache. Ich würde gerne meinen Mailserver nehmen (öffentlicher Port + intern Port besitzt dieser) IP intern: 192.168.0.2 Jetzt möchte ich quasi auf meinen internen Geräten diesen Mailserver als Gateway eintragen können, das meine internen Geräte auf Wunsch nach außen kommunzieren können. Mir geht es darum, auch apt-get's bei diesen internen Geräten auszuführen, und E-Mail Alerts kann ich von den internen Managment-Consolen sonst auch nicht raus ins weite www schicken Ich wüsste jetzt nicht was ich machen soll? Was gibt es denn so für Linux? Evtl. noch bissl Port Forwarding als Funktionalität. Ich glaub nämlich ich bin zu dumm für iptables, oder ist genau das der richtige Ansatz? Danke für alle Antworten! gruß Jens

Hej Super, danke! Das ist natürlich einleuchtend, soweit hatte ich garnicht gedacht! Habe natürlich bis zum Ende durchgehalten, da ich mich so gewundert habe, musste ich hier mal meinen "Dampf" ablasen ;-) Wünsche euch noch viel Glück mit den 1000 Teilnehmern.