IvkovicD

tjö, ich denke das reicht, um mit 300 im Hof rumzufahren ;) Dejan

das hört sich an, als ob jemand Zuhause einen Ferrari F1 stehen hat und die Hofeinfahrt unbedingt renntauglich asphaltiert werden muss ;)....kaskadierte GB Switche für SoHo....was solls... Dann solltest du auch deine Rechner überprüfen....falls du die angeschlossenen Gbics über einen 32bit@33MHz PCI Bus anfährst, wirst du nicht viel davon haben von deinem GB-Netz...und dann auch noch 30-40% CPU-Auslastung des Rechners (je nach CPU). Es reicht nicht aus, nur das Netz zu tweaken, die angeschlossenen Geräte müssen mitmachen...also: - PCI-X 64bit@33MHz PCI, 32bit@66MHz PCI oder 64bit@66MHz PCI - MoBos mit schnellem Chipsatz - PCI-Express (32 Lines) MoBos - TOE Nics (TCP offload Engines) ...das ist wie beim Tunen von Autos...reicht halt nicht immer aus, nur den Chip zu tunen, das Fahrwerk muss das mitmachen... Gruß Dejan

Hi Bandit18, das ist korrekt so, wobei das keine klassisch p2p verbindung ist, mit zwei IPs und einem Transfernetz, sondern eine virtuelle Weiterleitung an den Server. Rein technisch kann hier jede Netzmaske stehen. Unser POP-RAS verteilt eine 255.0.0.0 und es klappt ohne Probleme. Das echte routing macht der RRAS, bei ihm entscheidet die Netzmaske, wo es lang geht, oder nicht... zu IpSec stöberst du am besten hier im Board oder Google. Kleiner Tip, versuch IPSec zu verstehen, nicht nur irgendwo abzuschreiben... Gruß Dejan

...indem du beiden Karten ein Default-Gateway gibst, wobei die Metrik so zu setzen ist, das die 10/100 Karte die Metrik 0 und die andere irgendwas über 0(also 1 oder mehr) bekommt. Wenn du nicht die LAN Karte aktiviert hast (also Kabel gezogen) ist die Nic deaktiviert und die Route greift über die andere Karte. Ist die Karte aktiv, sorgt die Metrik dafür, über das LAN zu routen utd nicht über die Metrik 1 Karte. Gruß Dejan

Ein Schelm, wer dabei böses denkt...

hör auf grizzly999, dein Ansatz, das Pferd von hinten aufzuzäumen bringt dir nur doppelte Arbeit (erst einmal konfigurieren, dann nochmal), und wenn du was änderst, hast du die Kollegen doch am Hals, weil die nicht wissen, warum du was änderst...woher auch my2cent Dejan

tja, oft sieht man den Wald vor lauter Bäumen nicht....der Designer wird sicher mal dahinter kommen, was damit gemeint ist hehehe dejan

@Dr. Melzer: nicht doch, so war das nicht gemeint.... :shock: zum Thema: VPN ist mal nur ein Wort ohne Bedeutung in diesem Fall. Nachdem es etliche Formen von VPNs gibt, müssen wir feststellen, welche dein Router unterstützt. Eine pauschale Antwort, das der Router das nicht kann, ist erst mal zu belegen ;) Kurz zur Basis: So wie du unter TCP und UDP Ports definierst, die auf Anfragen hören oder Anfragen senden (25 SMTP, 80 HTTP, usw.) (siehe dazu %systemroot%\system32\drivers\etc\services) hast du für die Netzwerkschicht (hier IP) ebenfalls eine Definition, welche Transportkommunikation im IP-Paket verwendet wird: (siehe dazu %systemroot%\system32\drivers\etc\protocol und http://www.faqs.org/rfcs/rfc1700.html) Die bekanntesten vertreter sind: 1 ICMP Internet Control Message [RFC792,JBP] 2 IGMP Internet Group Management [RFC1112,JBP] 6 TCP Transmission Control [RFC793,JBP] 17 UDP User Datagram [RFC768,JBP] und dann kommen wir schon zu den oben genannten Protokollen, die ebenfalls geöffnet werden müssen (hier nur IP/47 GRE - 50/51 nur als Beispiel für IPSec) 47 GRE General Routing Encapsulation [Tony Li] 50 SIPP-ESP SIPP Encap Security Payload [steve Deering] 51 SIPP-AH SIPP Authentication Header [steve Deering] Vom Werk aus ist ein SoHo-IP-Router so eingestellt, dass er mind. die IP-Protokolle 1, 6 und 17 (ICMP, TCP und UDP) "erkennt" und entsprechend verarbeitet. Für PPTP muss jetzt noch IP/47 geöffnet werden. Dazu musst du auf deinem Router irgendwo die Möglichkeit finden, Protokolle zu aktivieren (falls schon vorhanden) oder zu definieren/aktivieren. Wenn du das nicht kannst, weil das dein Router nicht hergibt, dann kannst du diese Art von VPN nicht verwenden. Naja, mann kann immer noch über SSL irgend etwas zaubern, aber ein neuer Router ist da wohl "schneller am Ziel" Gruß Dejan

ich darf ergänzen PPTP: tcp/1723 -- PPTP-Tunnel IP/GRE (47) - PPTP L2TP/IPSec: udp/500 -- ISAKMP/IPSec-Tunnel udp/1701 -- L2TP-Tunnel IP/50 (ESP) IP/51 (AH) IPSec über NAT (NAT-T) UDP/4500 Gruß Dejan

Hi persiay, :D, kommen wir zu deinem Problem zurück, schauen wir mal, ob wir helfen können. Du schreibst, dass du TCP1723 geöffnet hast, also klingt das nach PPTP. Hast du auch Protokoll 47 (GRE - nicht Port), auf deinem Router geöffnet? Dann sollte PPTP, auch zwischen Client (XP) und Client (W2K) funktionieren. Nach MS funktioniert PPTP mit MPPE (Microsoft point-to-point ecryption ab RC4 RSA 40 Bit aufwärts). Das kannst du nicht deaktivieren. Du kannst höchstens manipulieren (indem Fall die Schlüssellänge - hmmm, beim Client??? nicht sicher). Wenn du wirklich eine unverschlüsselte (natürlich empfehle ich das nicht) VPN-Anbindung über Internet machen willst, dann benutze L2TP, das kann nicht verschlüsseln. (Der letzte Hinweis ist rein hypothetisch, ich empfehlen natürlich nur L2TP mit IPSec in Verbindung :D) Aber dafür benötigst du ebenfalls einen RRAS-Server, dein LCient kann das als Server nicht, nur PPTP/PPP. Gruß Dejan

Sorry persiay, hier findet gerade ein OT statt :D Jetz bin ich aber erstaunt über diese recht skurrile Erklärung! VPN definiert, wie du sagst, ein virtuelles privates Netzwerk, aber in dem Sinn, dass du eine WAN-Verbindung zwischen deinem und einem externen Standort (was auch immer das ist, LAN, DFÜ-Klient,etc.) schaffst, und diese Verbindung als dein quasi privates Netzwerk ansiehst, d.h. deine Daten laufen über deine Netze (deine IP-Struktur, deine Gateways). Dass es so nicht ist, zeigt ja die Tatsache, dass die dazwischen liegenden Netze eben nicht dir gehören, sondern einen Provider (Internet-ISP, einem MPLS-Provider. einem Frame-Relay-Provider), der so ziehmlich alles benutzen kann und wird, deine Daten von A nach B zu schaffen (also auch Medienwechsel, Protokollwechsel). Du kannst das nicht beeinflussen, und sollst es ja auch nicht, du benutzt deine zwei Netze, dein Transfernetz, und fühlst dich wie zu Hause. Dein "Virtuelles privates Netzwerk". Früher hast du dir auch keine großen Gedanken gemacht wegen Verschlüsselung, wer sollte denn schon ein packetiertes Framerelay absniffen, wo du quasi nicht weisst, welchen Weg diese Pakete nehmen. Leider geht dieses Gedankenansatz schief im Internet, also musste eine Weg gefunden werden die Pakete zu schützen (Veränderung, Integrität, Abhörsicherheit). Und jetzt kommt erst der Faktor Verschlüsselung ins Spiel, und nicht vorher. VPNs sind deutlich älter als z.B. IPSec oder die Verbindung zweier Standorte über Internet. Alles was du verbindest, und in dieser Verbindung tunnelst, ohne auf die äußere Transportform einzugehen ist ein VPN, ein virtuelles privates Netzwerk, zwischen Dir und deinem Ziel. Schau dir mal L2TP an, das schafft einen VPN Zugang über Medienwechsel, kann aber nicht verschlüsseln.... Das heutzutage VPN automatisch Verschlüsselung impliziert, heisst noch lange nicht, dass VPN nur mit Verschlüselung funktioniert. Oder VPN Verschlüsselung bedeutet. DVD heisst ja auch nicht Digital Video Disk (auch wenn es viele glauben) :D Gruß Dejan

Mit dieser Aussage stimme ich nicht überein, ein VPN ist erstmal eine Abtrennung/Verkapselung von IP-Paketen gemeint, der Faktor Verschlüsselung ist ein Addon auf diese Methode. Wobei VPN erstmal gar nichts definiert, ausser einer Verbindung zwischen Quelle und Ziel, wobei das darunter liegende Medium als Transportebene benutzt wird, und die Pakete eine besondere Behandlung erfahren (tunneln/verschlüsseln/versiegeln/etc) Heutzutge wird immer von einer Verschlüsselung ausgegangen, wenn man VPN sagt (wird wohl das ’V’ sein)... Eine ’Ausschaltung’ ist vom eingesetzten Kommunikations-Protokoll abhängig, welches im Zuge einer VPN-Bildung benutzt wird... Gruß Dejan

Hi, was definierst du mit "Material"? bei Amazon gibts für den Anfang genug "Material", welchse sich mit 70-298 und 70-299 befasst.... ich habe mir die beiden MS Press bestellt, sollten die Woche kommen, und dann gehts los mit den beiden 98/99 Gruß Dejan

:D ...beide Server haben also DNS, wissen das die Clients? Ansonsten wie ist den der GC konfiguriert (log dich mal in so einer Situation (DC vom Netz) mit dem Domänen-Admin an; gehts?) Gruß Dejan

gar nicht, Netzmasken und Ip-Adressen(bereiche) werden (theoretisch) vorher festgelegt, und haben durch diese Zusammenlegung die "Verbindung" erhalten, die man so kennt. Eine umgekehrte Logik aus beiden Angaben zu erreichen, ist nicht möglich, wenn du nicht weiss, warum gerade diese Netzmaske dieser Ip zugewiesen wurde (und da bist du schon wieder am Startpunkt, den du erreichen willst...circle-around). Wenn du nur beide Werte hast, dann kannst du herzlich wenig damit anfangen... Es gibt zwar ein paar Hinweise, woran du erkennst, dass die Maske definitiv nicht zur IP-Adresse passt (z.B. letze mögliche IP-Adresse des Netzmaskenbereiches = Broadcast des Subnetzes -> sollte keine gültige IP-Adresse sein...), aber einen Umkehrschluss daraus zu ziehen ist nicht möglich. Die Erklärungen hier sind zwar gut und auch nötig, um die Methode der Netzmaskenvergabe zu verstehen, aber das geht meistens nur in einer Richtung... Du hast HOSTs vorgegeben, welche Maske nehme ich....oder du hast ne Maske, wieviel HOSTS habe ich maximal. Aber du hast ne IP-Adresse und eine Maske, passen die zusammen? ....Meistens JA :D my2cents Dejan

Hi BlueIcE, guckst du: http://www.danish-company.com/dcwcm/page/{4D40EC77-0788-48E7-9FB6-B81A51F70CD2}.html http://www.twaddlesoftware.com/password/features.html oder http://support.microsoft.com/default.aspx?scid=kb;EN-US;272530 Gruß Dejan

Hallo Nimo, erzähl mal was über deine WINS-Struktur und deine Clients (OS)? Gruß Dejan

...hast du auch versucht, die fehlenden Einträge im DNS (alter DNS) manuell eizutragen? http://support.microsoft.com/default.aspx?scid=kb;EN-US;241515 ansonsten weisst du ja sicher, wenn du die FSMOs mit ntdsutil ’hart’ übernimmst, darf dein alter DC so nicht mehr ins Netz (offline-demote oder fdisk sind da angesagt). Das würde ich an letzter Stelle machen (klappt aber auch nur, wenn dein neuer DC die AD schon gesynct hat, sonst heißt es auch hier: alles neu bringt der April - reimt nicht, ich weiss) gruß Dejan

Hi, das liegt nicht direkt an deinen fehlenden Privilegien (eigentlich schon, aber nicht-Admin reicht halt hier nicht), eher daran, welche Informationen du (oder net send) vom Server (und vor allem wie) abfragt. net send ist ein einfacher Client, der einen Namen (+Dienstkennung) von WINS aufgelöst haben will, netsh ist ein Admintool, das mehr Infos abgreift (oder abgreifen will). Der WINS blockt das leider ab, da du nicht mit einem Adminkonto arbeitest. Du wirst aber diese Rechte benötigen, sonst ist der direkte Zugriff zumindest mit netsh nicht möglich. Irgendwo im Internet habe ich mal ein Perlmodul gesehen, das auf einfacher Basis diese Namensauflösung-zu-IP paktiziert, um rauszufinden, wo der Benutzer ist (das was du vorhast). Allerdings ist das wieder eine Erweiterung, da kannst du gleich das oben genannte Tool nehmen... Wenn du kein Admin bist, dann musst du skripten, um die Funktion des Net Send zu emulieren. Könnte ja sein, das mit VBS sowas geht... Gruß Dejan Ich würde das mit dem WINSDMP machen, für unseren Benutzerservice recht das aus, die haben auch nicht Domänen-Adminrechte...

du solltest den IP Bereich für deine VPN-Clients wieder zurückstellen, was mit dem neuen IP Bereich (192.168.25.x) passiert ist, ist folgendes: dein 192.168.18.x Netz kennt dieses Netz nicht, also werden die Pakete von den internen Systemen zum Default-GW geschickt nicht zum VPN-Server. Eine Überschneidung zwischen VPNs und lokale Adressen (DHCP) macht nichts aus, du verlierst höchstens den Überblick wer woher kommt... Wenn du das gemacht hast, probier mal eine Namensauflösung mittels nslookup auf den VPN-Clients (nslookup client.domäne.suffix), um zu differenzieren, ob es ein NetBios oder DNS Prob ist (tippe auf Netbios). ich bin nicht der Meinung, das WINS/DNS auf den Einwahlserver zeigen muß, der löst keine Namen auf; so wie es jetzt ist, stimmen deine WINS/DNS Einträge noch schnell eine Verständnissfrage: mit \\client meinst du LAN-Clients... Gruß Dejan

...für jeden Hotfix eins...

Hi Marc, ja, zwei Teile, gleiche Inhalte, zwei Zeiteinheiten, wenn du mit dem ersten Block fertig bist, ist die Zeit vom ersten Block weg...der zweite Block fängt wieder bei Null an... Gruß Dejan

hi Philipp, jetzt mal was anderes, welche Namensdienste (WINS/DNS/lmhost/Buschtrommeln) sind deinen Clients zugewiesen (ipconfig /all) ??? Gruß Dejan

Hi Dau-Jones, d.h. du bist kein Admin... nicht gut, in irgendeiner Form benötigst du schon die Recht auf die WINS-DB zugreifen zu können... Es gibt zwar noch ein Tool (Winscl), damit sollte eine Query auch möglich sein, aber ich gehe davon aus, das du an der Berechtigung scheiterst... Teil den ersten Vorschlag auf, lass einen Admin das Winsdmp.exe regelmäßig ausführen (Scheduler mit Adminrechte) und stell die Datei (könnt ja erst filtern nach 03) irgendwo hin, wo ihr Rechte habt zu lesen... tja...DNS und DHCP hat unterstützende Sicherheitsgruppen (read), WINS leider nicht... Gruß Dejan

...golden boys...