Jump to content

Robi-Wan

Members
  • Gesamte Inhalte

    780
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Robi-Wan

  1. Hallo,

     

    nach langer Zeit habe ich nun das Problem beheben können:

    1. Per "netsh interface ip show address" eine Übersicht über die Interfacemetriken der VPN-Verbindungen ziehen
    2. in den IPv4-Verbindungseigenschaften der "inneren" VPN-Verbindung die Option "automatische Metrik" ausschalten und per Hand eine kleinere Metrik eingeben als bei der "äußeren" VPN-Verbindung

     

    Grüße,

    Robert

  2. Hallo nochmals,

     

    ich hatte mal die Möglichkeit, die ganze Geschichte innerhalb der Firma zu testen und siehe da: es funktioniert. Bisher hatte ich das immer von extern probiert, also Client baut VPN zur Firma auf, danach VPN zum Testnetzwerk. Da sich die Vorraussetzungen nun geändert haben, schlage ich vor, dass es hier: http://www.mcseboard.de/windows-forum-lan-wan-32/vpn-innerhalb-vpn-dns-server-reihenfolge-175963.html#post1084305 weitergeht.

     

    Danke für die bisherigen Bemühungen und Gedankenverrenkungen :)

     

    Grüße,

    Robert

  3. Hallo zusammen,

     

    dies ist der Nachfolgethread zu http://www.mcseboard.de/windows-forum-security-47/tmg2010-falscher-dns-server-vpn-clients-175786.html.

     

    Zur Ausgangslage: Client verbindet sich mit Firmennetzwerk per VPN und dann mit dem internen Testnetzwerk wieder mit VPN. Also so:

     

    Client -> Firma -> Testnetzwerk

     

    Nun bekommt der Client bei der VPN-Verbindung zum Testnetzwerk den DNS-Server vom Firmennetzwerk als ersten DNS-Server. Dies hat zur Folge, dass keine Namensauflösung innerhalb des Testnetzwerkes stattfinden kann. Wie kann ich nun entweder die Reihenfolge der DNS-Server ändern bzw. den Firmen-DNS-Server aus der VPN-Verbindung zum Testnetzwerk ganz entfernen?

     

    Bisher wurde folgendes gemacht: Auf dem VPN-Server im Testnetzwerk ist kein Hinweis mehr auf den Firmen-DNS-Server vorhanden, dort wurde der DNS-Server des Testnetzes in die VPN-Verbindungseigenschaften eingetragen (manuell), in den VPN-Eigenschaften auf dem Client wurde nur der DNS-Server des Testnetzes eingetragen.

     

    Grüße,

    Robert

  4. Hallo zusammen,

     

    wir wollen den TMG 2010 einsetzen, um ein separates Netzwerk zu erstellen.

     

    Also: Normales Netzwerk (10.x.x.x) -- TMG -- Testnetzwerk (192.168.x.x)

     

    Der Zugriff auf das Testnetzwerk soll über VPN erfolgen. Ich kann erfolgreich eine VPN-Verbindung herstellen. Nun gibt der TMG bei der IP-Vergabe an den VPN-Client DNS-Server in folgender Reihenfolge an:

     

    DNS1: 10.x.x.x

    DNS2: 192.168.x.x

    DNS3: 192.168.x.y

     

    Das hat natürlich zur Folge, dass keine DNS-Auflösung des Testnetzes am VPN-Client erfolgt. Was kann man dagegen unternehmen?

     

    Grüße,

    Robert

  5. Hallo,

     

    wieso solltest Du für einen DC zusätzliche CALs benötigen? Wie sieht denn Dein Lizenzmodell derzeit aus?

     

    Eventuell sind auch für Dich die Windows Server Data Center Lizenzen für Dich "interessanter". Schau Dir die doch mal genauer an.

     

    Grüße,

    Robert

  6. Hallo,

     

    zu Frage 2 eine kleine Korrektur: Wenn ein Client eine IP erneuern will, schickt er keinen Broadcast, da er den DHCP-Server ja bereits kennt. Er kontaktiert diesen also direkt. Erst wenn dieser nicht antwortet, wird der Broadcast geschickt.

     

    Das andere habe ich jetzt nicht so ganz verstanden. Kann sein, dass mein Kopf schon vom Mittagessen abgelenkt wird...

     

    Grüße,

    Robert

  7. Hallo,

     

    Frage 1: Laufe ich in technische Probleme, wenn ich nur einen DC habe und dieser nur als VM läuft (kein physicher DC) und welche Schwierigkeiten wären das genau?

     

    Wenn Du wie unten angesprochen einen Cluster bauen willst, kannst Du Schwierigkeiten bekommen, denn ein Cluster benötigt zum Hochfahren einen DC. Wenn der jedoch auf dem Cluster laufen soll... Ansonsten hast Du hoffentlich nicht nur einen DC...

     

    Ist es mal abgesehen von dem Lizentrechtlichen, technisch überhaupt möglich für kurze Zeit von der Enterprise Version diese 8 VMs am laufen zu halten bis der zweite Host wieder einsatzbereit ist? Oder merkt der Enterprise Host "Hopla, jetzt laufen hier 8 VMs und jetzt schalte ich mal ab"?

     

    Technisch gesehen ergeben sich keine Schwierigkeiten. Lizenztechnisch wurde auch schon einiges im Lizenzforum diskussiert zu diesem Thema.

     

    Frage 3: Kann ich ein Failover-Cluster auch später erstellen, also wenn ich zb erst einen Host habe und auf diesem die VMs für einen Zeitlang laufen lasse und zu einem späteren Zeitpunkt sich vieleicht die Anforderungen ändern, dann einen zweiten Host und ein SAN mit ins Boot nehme um einen Cluster aufzubauen?

     

    Ja, klar.

     

    Grüße,

    Robert

  8. Hallo,

     

    die User sollen ihr Kennwort in DomB ändern können. Vertrauensstellung oder ADFS sind zwar schön, aber nicht gewollt.

     

    Wie bereits gesagt, eine Applikation ist der TFS, andere sind eigene Webapplikationen, die in DomB laufen und Zugangsdaten verlangen. Es gibt keine Applikation in DomB, die von allen genutzt wird, so dass man dort eine Passwortänderung einbauen könnte.

     

    Grüße,

    Robert

  9. Hallo zusammen,

     

    ich habe in unserem Netzwerk zwei Domänen: DomA und DomB. DomA ist eine Domäne für alle Nutzer, DomB sollen nur einige nutzen. Dort stehen verschiedene Services zur Verfügung, wie z.B. TFS. Bisher haben die User ein Kennwort zugewiesen bekommen. Nun möchte ich ihnen die Möglichkeit geben, ihre eigenen Kennwörter zu ändern.

     

    Im Internet wird auf OWA oder IISADMPWD verwiesen, beides ist aber nicht verfügbar. Meine Idee ist es nun, einen Windows 7 Client einzurichten, auf dem sich die User per RDP anmelden können, sofort den Bildschirm zur Kennwortänderung sehen und nach erfolgreicher Änderung wieder abgemeldet werden.

     

    Meine Frage ist nun: Wie rufe ich diese Windows-Funktion auf?

     

    Grüße,

    Robert

  10. Joern Engmann für Rainer Sokoll

     

    Der Erlrouter

     

    Wer routet so spät durch Nacht und Wind?

    Es ist der Router, er routet geschwind!

    Bald routet er hier, bald routet er dort

    Jedoch die Pakete, sie kommen nicht fort.

     

    Sie sammeln und drängeln sich, warten recht lange

    in einer zu niedrig priorisierten Schlange.

    Die Schlangen sind voll, der Router im Streß,

    da meldet sich vorlaut der Routingprozeß

    und ruft: "All Ihr Päckchen, Ihr sorgt Euch zu viel,

    nicht der IP-Host, nein, der Weg ist das Ziel!"

     

    Es komme gar bald einem jeden zu Gute

    eine sorgsam geplante und loopfreie Route.

    Des Netzes verschlungene Topologie

    entwirr' ich mit Dijkstras Zeremonie.

    Der Lohn, eine herrliche Routingtabelle,

    dort steh'n sogar Routen zu Himmel und Hölle.

     

    Vergiftet der Rückweg, das Blickfeld gespalten,

    mit RIP wird die Welt nur zum Narren gehalten.

    Doch OSPF durchsucht schnell und bequem

    mein ganz und gar autonomes System.

    Für kunstvolle Routen, das vergesst bitte nie,

    benötigt man Kenntnis der Topologie.

     

    Zu Überraschungs- und Managementzwecken

    durchsuch' ich mit RMON die hintersten Ecken.

    Kein Winkel des Netzes bleibt vor mir verborgen,

    mit SNMP kann ich alles besorgen.

     

    Wohlan nun, Ihr Päckchen, die Reise beginnt,

    Mit jeder Station Eure Lebenszeit rinnt.

    Doch halt, Ihr Päckchen, bevor ich's vergesse:

    "Besorgt euch mit NAT eine neue Adresse!"

     

    "Mein Router, mein Router, was wird mir so bang!

    Der Weg durch das WAN ist gefährlich und lang."

     

    "Mein Päckchen, mein Päckchen, so fürchte Dich nicht,

    denn über Dich wacht eine Sicherungsschicht."

     

    "Mein Router, mein Router, was wird mir so flau!

    Dort draußen am LAN-Port, da wartet die MAU!"

     

    "Mein Päckchen, mein Päckchen Dir droht nicht der Tod,

    denn über Dich wacht ja der Manchester-Code.

    Doch halte dich fern von der flammenden Mauer.

    Die sorgt selbst bei mir noch für ängstliche Schauer."

     

    "Mein Router, mein Router, wie glänzt dort voll Tücke

    der schmale und schlüpfrige Weg auf der Brücke."

    "Oh weh! Das Netz ist mit Broadcasts geflutet.

    Ach hätt' ich doch niemals zur Brücke geroutet!

     

    Mein Päckchen, den Kopf hoch, Du musst nicht verzagen,

    an Dich wird sich niemals ein Bitfehler wagen."

     

    Schnell wie der Wind geht die Reise nun weiter

    durch helle und funkelnde Lichtwellenleiter.

     

    "Mein Päckchen, mein Päckchen, willst Du mit mir gehen?

    Die Wunder des Frame-Relay-Netzes ansehen?"

     

    "Mein Router, mein Router, ja hörst Du denn nicht,

    was die WAN-Wolke lockend mir leise verspricht?"

     

    "Glaub mir, mein Päckchen, im LAN, da entgeht

    Dir sowieso Lebens- und Dienstqualität.

    Reise nur weiter ganz ruhig und sacht

    Quer durchs ATM-Netz mit FRF.8 ."

     

    "Mein Router, mein Router, man hat mich verführt,

    zerlegt, verschaltet und rekombiniert!"

     

    "Mein Päckchen, das macht nichts, nun sparen wir viel,

    ein VPN-Tunnel, der bringt Dich ans Ziel.

     

    DiffSERV und TOS-Feld, merk' Dir die Worte,

    die öffnen zu jedem Router die Pforte."

     

    Finster der Tunnel, die Bandbreite knapp,

    wie schön war die Backplane im eigenen Hub.

    Am Ende des Tunnels: Das Päckchen ist weg,

    vernichtet vom Cyclic Redundancy Check.

×
×
  • Neu erstellen...