Jump to content

Velius

Expert Member
  • Gesamte Inhalte

    5.644
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Velius

  1. @Urmel

    Du scheinst dich generell ein wenig mit dem Verständnis meiner Antworten zu stossen, wa?

     

     

     

     

    2 aktive DHCP's im gleichen Bereich - von 80:20 reden wir dabei nicht, sonder 100:100 -das ist ein NoGo und verifiziert

     

    Das habe ich nicht bestritten, aber der Titel ist DHCP redundant im Netz, und das ist eine von MS vorgeschlagene Methode. Man kann diskutieren, ob das jetzt wirklich "redundant" ist oder nicht, aber werden wir mal nicht philosophisch.

     

    Wenn doch 80:20 mittels Exclude gefahren wird, dann must du beim Ausfall des einen ebenfalls

    Aktionen einleiten, die wiederum via Heartbeat zu steuern wären.

     

    Nein, hast du nicht, glaubs mir, und wenn nicht, probier's aus! Grund: Der Client versucht (zumindest Windows Clients) immer die bereits bestehende IP zu erneuern. Sollte der noch laufende DHCP mit dem für diese IP existierenden exclude kontaktiert werden gibt es einen DHCP NACK (No acknowledgement) Meldung und der Client versucht einen DHCP Request für eine neue IP.

     

    Ein Bereich der mit der mir wohl bekannten und von dir zitierten "Release DHCP...." gefahren wird, wird dennoch nicht mehr zur Verfügung stehen ist genau der Server weggebrochen.

     

    Es bricht ja nicht der Bereich weg, sondern ein Server mit einem exclude. Du hast echt die Idee dahinter nicht verstanden, sehe ich das richtig? :confused:

     

    Damit stehst du vor dem gleichen Dilemma, mehr noch da ja der verbleibende Server ja nur einen Teil bereisstellen kann.

    Also völlig egal wie man es anstellt, Heartbeat und Events / Scripting - dann gehts hoffentlich.

    Du hast zwar ein Reserverad, aber es braucht nen Moment bis es rollt - um es bildlicher auszudrücken.

     

    Nicht wenn der Bereich ordentlich gross ist. Aber diesen Nachteil hatte ich erwähnt.

     

     

    Aber nett darüber mal gesprochen zu haben. ;)

     

    Hui bist du aber näckisch :) :rolleyes:

     

    Ne echt, ich wollte den Thread mit einer funktionierenden Lösung bereichern, aber wenn du diese nicht verstehst, dann bitte ich dich in Zukunft diese nicht zu "belächeln". Ich zolle dir auch diesen Respekt.

     

     

    Gruss

    Velius

  2.  

    natürlich wird die VPN-Verbindung vom MS-Client zum D-Link hergestellt.

     

     

    Sorry, aber du konntest mir immer noch nicht klar machen, von wo. Von zu Hause? Remote ? Externe Location? Oder etwa aus einem deiner LAN's? Ich will dich nicht nerven mit Design Fragen, doch das ist relevant für die Problemlösung.

     

     

    Ich wollte im Posting #6 nur verdeutlichen das ich mir vollkommen im Klaren bin was Konfiguriert werden muß.

     

    Wenn dem so wäre, dann wäre doch alles klar, oder? :) Ist ja aber auch nicht schlimm, denn wofür sucht man denn Hilfe.

     

    Sowohl die Firewall als auch der Router sind so Konfiguriert das sie VPN Verbindungen durchlassen Port 1701 und GRE-Protokoll (47).

     

    Das ist erstmal nebensächlich. Ich hatte ja schon gefragt, ob die Rulebase i.O. ist, und wenn du das sagst, dann glaube ich das auch.

     

     

     

    Mir ist es im Grunde genommen egal ob die Inet-Verbindung lokal oder remote genutz wird. Hauptsache ist nur das beim bestehen eines VPN-Tunnels überhaupt Internet funktioniert.

     

    Mag sein, dass dir das egal ist, aber der Software nicht. Der MS Client kann, sobald der Tunnel steht, nur noch durch diesen senden (soweit ich das noch weiss, kann mich auch täuschen und bin jetzt eh gerade etwas unter Zeitruck und kann somit nicht die nötigen Artikel suchen). Nur mit einem Client von Fremdanbietern wie Checkpoint ist es möglich, auch neben der virtuellen Verbindung zum VPN Server auch noch die normale Schnittstelle zu verwenden, da dieser über eine komplette Topologie für das sich hinter dem VPN Server befindlichen Netz hat. Wie sonst soll der Client wissen, welche Pakete über VPN sollen, und welche nicht. Ausserdem macht dein von dir beobachetetes Verhalten bezüglich der Option "Standardgateway des Remote-Netzwerks verwenden" dies nochmals deutlich.

     

     

    Um auf deinen Einwand zurück zukommen:

     

    Das war kein Einwand, sondern eine informative Nachfrage, da mir erhlich gesagt dein Netzwerk Design immer noch schleierhaft ist. Möchtest du mir vielleicht ein Skizze (VISIO??) davon schicken oder hochladen (Regel für Attachments beachten!!)? Das wäre schon etwas hilfreicher.

     

    Der VPN-Server ist in seinem Netzbereich (192.168.10.x ) auch Standard Gateway in meinem Netzbereich natürlich nicht.

     

    Das der nicht Gateway in deinem Netz ist, ist vollkommen klar.

     

     

    Wenn ich Dich jetzt richtig verstanden habe dann sollte ich einfach mal eine Route zum 192.168.10.1 (ist die LAN-IP des D-Link) definieren. Hab ich auch probiert ging nicht:

     

    route add 0.0.0.0 mask 0.0.0.0 192.168.10.1 metric 2 if 5

    The route addition faild: Der Parameter stimmt nicht.

     

    Das kann nicht funktionieren, und nein, so hatte ich das nicht gemeint. ;)

     

     

     

    Gruss

    Velius

     

     

    P.S.: Ich zweifle nicht an deinen Kenntnissen, ich versuche lediglich zu helfen und die Nadel im Heuhaufen zu finden. ;)

  3. :confused::confused:

     

    Wie jetzt?

     

    Aus deinem ursprungs Post hätte ich jetzt geschlossen:

     

    MS VPN Client -----Tunnel----- "irgend 'ne Firewall/Routing device" ----- D-Link VPN Server ----- LAN

     

     

    So wie du das aber weiter in Post #6 beschreibst, verbinden sich die MS Clients zu deinem VPN Server, und gehen dann ohne Tunnel in's Internet, sind also somit nicht im internen LAN, oder baut der VPN-Server seinerseits noch einen Tunnel mit dem Velociraptor auf (du musst mir da etwas auf die Sprünge helfen - ich kenne die Produkte nicht und die Checkpoint FW-1/VPN-1 ist ein all-in-one Produkt)?

     

     

    P.S.: Dein Hauptproblem scheint, so wie ich schon erwähnte, dass dein VPN Server nicht der default Gateway(Router) deines LAN's ist. Der VPN Server kennt logischerweise die Route in's virtuelle Netz, aber dein default Gateway, welcher jeglichen Traffic nach irgendwo ausser deinem LAN (I-net beispielsweise) managed aber nicht. Dieser braucht sehr wahrscheinlich einen statischen Routing-Eintrag.

  4. access-list inside_outbound_nat0_acl permit ip any 192.168.2.0 255.255.255.0

    access-list inside_outbound_nat0_acl permit ip 192.168.0.0 255.255.255.0 host 192.168.1.2

    access-list inside_outbound_nat0_acl permit ip 192.168.0.0 255.255.255.0 host 192.168.1.3

    access-list outside_cryptomap_20 permit ip 192.168.0.0 255.255.255.0 host 192.168.1.2

    access-list outside_cryptomap_20 permit udp 192.168.0.0 255.255.255.0 host 192.168.1.2

    access-list outside_cryptomap_20 permit icmp 192.168.0.0 255.255.255.0 host 192.168.1.2

    access-list outside_cryptomap_20 permit tcp 192.168.0.0 255.255.255.0 host 192.168.1.2

    access-list outside_cryptomap_20 permit ip 192.168.0.0 255.255.255.0 host 192.168.1.3

    access-list outside_cryptomap_20 permit udp 192.168.0.0 255.255.255.0 host 192.168.1.3

    access-list outside_cryptomap_20 permit icmp 192.168.0.0 255.255.255.0 host 192.168.1.3

    access-list outside_cryptomap_20 permit tcp 192.168.0.0 255.255.255.0 host 192.168.1.3

     

    Ich hab jetzt zwar keine Pix, darum muss ich etwas raten.

    Für mich sieht das aber aus, als ob alles vom Netz 192.168.0.0/24 an deine beiden Rechner erlaubt ist, aber nicht zurück (also wenn der Rechner iniziert..) was jetzt so keinen Sinn macht von mir aus gesehen.

     

    Das "cryptomap" steht ja wahrscheinlich nur für Verschlüsselt.

     

     

    Oder interpretier ich das falsch?

     

     

    P.S.: Wie du siehst, bin ich nicht der Pix Pro, hatte das mit der Konfig auch nicht wörtlich gemeint ;) , aber vielleicht hilft dir auch dieser Artikel weiter

    Active Directory-Replikation über Firewalls

  5. Hi

     

    Das mit der dem virtuellen IP-Pool ist bei Checkpoint auch nicht anders. Dort kannst du wählen zwischen diesem und einem echten von einem DHCP aus dem Netz.

     

    Aber aus deinem Post werd ich nicht ganz schlau.

     

    Kannst du mal die IP-Config deines PC's, welcher über VPN verbunden ist posten, während die Verbindung zum VPN Server steht?

     

     

    Gruss

    Velius

  6. Das Problem liegt beim Design des Computerbrowser Dienstes:

     

     

    • It is possible on some routers to enable the forwarding of NetBIOS broadcasts. This causes Computer Browser service to work as if all computers were connected to the same subnet. However, this practice propagates broadcast traffic and can create problems with browser elections. Microsoft recommends that you do not enable the forwarding of NetBIOS (UDP port 137 and UDP port 138) broadcast packets across routers.

     

    How Computer Browser Service Works

     

     

    Also entweder die Ports forwarden oder damit leben....

    Brauchst du den Browserservice wirklich (Ich weiss das gewisse Antiviren und Backup Programme nicht ohne können, Veritas beispielsweise schon...).

     

     

    Gruss

    Velius

     

     

    P.S.: Sorry, sollte trotzdem gehen....

     

    When you use domains that are split across routers, the TCP/IP subnets function as independent browsing entities, each with its own master browse server and backup browse servers. Therefore, browser elections occur within each subnet. In contrast, workgroups do not span across an IP router.

     

    ...aber ich vermute trotzdem mal ein Problem mit den Ports. Wie sieht denn die Konfig. der PIX aus?

  7. Hi

     

    1. Nur zur Info: PDC und BDC Modelle gibts bei AD Domänen nicht mehr, dafür Rollen.

     

     

    2. NetBIOS over TCPIP oder kurz NBT genannt nützt nur dann etwas, wenn auch ein WINS läuft. Gut, man kann diskutieren, ob die Broadcast zu verkraften sind. Leider werden aber NetBIOS Braodcasts meist von Netzwerk Geräten geblockt, und bleiben auf das jeweilige Subnetz reduziert.

     

    3. Veritas hat einige Artikel dazu:

    Servers are not seen under Remote Selections of Backup Exec for Windows Servers

    How to create a User-defined Share?

     

    Beide Artikel treffen zu, wenn etwas mit NBT/WINS nicht stimmt, oder wenn diese deaktiviert sind.

     

     

    Gruss

    Velius

     

     

    P.S.: 4. Der Masterbroswer kann nur einer sein im AD, und das ist der PDC-Emulator. Ich würde das auf der Firewall disablen, oder NBT auf dem PDC-Emulator....

  8. So wie meine Vorredner schon erwähnt haben:

     

    Using Split-Scope Configurations

     

    Scope Configuration

     

    Der Trick ist der, dass ein Netz 192.168.1.1 /24 in zwei Teile geteilt werden. Auf dem einen Server macht man einen Ausschluss für den einen, auf dem anderen Server einen Ausschluss für den anderen Teil. Ob die jetzt 80/20 oder 50/50 geteilt sind hängt von der ANzahl Clients und der grösse des Pools ab.

     

    (EDIT: Sollte einer der Server ausfallen, kann man den Ausschlussbereich auf dem anderen auflösen!)

     

     

    Nun, deine Variante geht auch, nur sehe ich das Problem, dass der Ausfall des Dienstes oder Servers für die IT aus irgendwelchen Gründen unbemerkt bleibt, und sobald die meisten das maximum der Lease-Dauer erreicht haben, geht der ärger los. Wenn dann noch der DHCP Admin weg ist, geht's erst recht los.....

     

    Wen man mit zwei Servern mit gleichen Bereichen aber mit unterschiedlichen Ausschlüssen arbeietet, besteht aber IMHO weniger Gefahr. Ausserdem kann man mit der gennanten MS Option Release DHCP Lease on Shutdown und dem Herbsetzen der Lease-Dauer (IP Adressen werden schneller verfügbar, dafür etwas mehr Traffic) sich etwas Luft verschaffen, sollte der Pool etwas (zu) klein sein.

     

     

    Gruss

    Velius

     

     

    P.S.: @Das Urmel

    Deine Variante ist auch interessant. Mein Beitrag sollte als Ergänzung zu verstehen sein.

     

    P.P.S.: Ich exportiere meine Konfig auch mit Netsh.

  9. Ich habe zwar nicht so viel Erfahrung mit dem VPN Client von MS und/oder dem von dir benutzten VPN Server, aber ich vermute dass der Gateway des Remote Netzwerkes den Weg zurück zum VPN Client nicht kennt. Woher bekommt der Client seine IP Adressen? Vergibt der D-Link DI-804HV VPN Server die IP Adressen und wenn ja, was für ein Pool wird zugewiesen? Was ist der default Gateway bei euch?

     

     

    Gruss

    Velius

     

    P.S.: Wir verwenden Checkpoint VPN, und da kann man die Option "Route all traffic through Gateway" verwenden. Normalerweise klappt das auch recht gut, solange der VPN Server auch Gateway ist und kein NAT verwendet wird. Wenn doch muss man das entsprechend konfigurieren (NAT Rules und/oder auf dem Gateway eine Route zurück in's VPN Subnet erstellen).

  10. @Urmel

     

    Schlecht bei der Lösung ist nur, dass der Ausfall eventuell nicht unbemerkt bleibt, z.B. bei einem remote Standort mit unzureichendem Personal.

     

    Man kann auch beide aktiv lassen und den Netsh export/import Command verwenden um die Einstellunbgen auf den 2. Server zu nehmen, um schliesslich noch den Ausschlussbereich zu ändern.

     

     

    Gruss

    Velius

     

    P.S.: Das Problem mit der Pool grösse kann man auch mit dem Herabsetzen der Lease-Dauer und der MS Oprion "Lease freigeben beim Herunterfahren" lösen....

  11. es:

     

    P.S. wenn man übrigens während dieser Anfrage den Vorgand unterbricht mit STRG+C und den PC mit ghreboot neustartet, wird Windows geladen - allerdings in beiden Fällen (mit und ohne sysprep) nicht in die Domäne sondern in die Arbeitsgruppe eingebunden, obwohl alle Einstellungen bei Ghost richtig sind....

     

    Diese Endlosschleife scheint also irgendwas mit der Domäneneinbindung zu tun haben... :suspect:

     

     

    Also wie gesagt, mit Sysprep geht das sowieso nicht, und das ist richtig, dass es mit der Domänenanbindung zu tun hat. Nach dem Laden des Image sollte anschliessend der Ghostwalker laufen und Reboot. Dann fährt der Rechner bis zu Windows hoch (nicht einloggen, da noch nicht an der Domäne!!!) und wird der Domäne beitretten, anschliessend erneuter Reboot, alles voll automatisch. Wenn Windows weider hochfährt sollte alles in Butter sein.

     

    So läuft's wenn alles i.O. ist, habe ich sicher schon gegen die 200-300 mal gemacht.

     

     

     

    Kannst du uns vielleicht stichwortartig die Einstellungen deines Ghost Console Konfig. Päckchens posten? Mäglicherweise ist da noch ein Fehler drin, das hatte ich ganz zu beginn vermutet.

     

     

    Gruss

    Velius

  12. Gut, ich hatte tatsächlich eine etwas längere Zeit im Kopf. In wirklichkeit liegt es wohl eher zwischen 5-10 Sekunden, obwohl ich in einigen Fällen der Meinung war, es ginge länger....

     

    Ich halte das aber für vernachlässigbar, denn Performance oder Namensauflösungs Probleme würden sich auch anders äussern (Client Zugriff auf Server, Filesharing, Outlook, usw.).

  13. Hallo Leute,

     

    Was passiert wenn die DHCP leases der Clients ablaufen, und der DHCP-Server noch nicht wieder 100% läuft.

     

     

    s.weinschenck

     

    Hi

     

    Wenn der Client keinen neuen Lease nach 50% der Lease-Dauer erhält, oder nach Ende dieser, dann behält er die IP. Allerdings geht dann gar nichts mehr, wenn man den Client neu starten sollte....

     

     

    EDIT: Huups, stimmt nicht (mehr? :suspect: )

     

    Renewing a Lease

     

    The DHCP client first attempts to renew its lease when 50 percent of the original lease time, known as T1, has passed. At this point the DHCP client sends a unicast DHCPRequest message to the DHCP server that originally granted its lease. If the server is available, and the lease is still available, the server responds with a unicast DHCPAck message and the lease is renewed.

     

    If the original DHCP server is available, but the client’s current lease is no longer available, the DHCP server responds with a DHCPNack message, and the client immediately starts the process to obtain a new lease. This can happen if the client has changed subnets or if the DHCP server cannot fulfill the lease request for some other reason.

     

    If there is no response from the DHCP server, the client waits until 87.5 percent of the lease time has passed (known as T2). At T2, the client enters the rebinding state, and broadcasts a DHCPRequest message to attempt to renew the lease from any available DHCP server. If no DHCP server is available by the time the lease expires, the client immediately unbinds itself from the existing lease and starts the process to obtain a new lease, beginning with a DHCPDiscover message.

     

    How DHCP Technology Works

  14. Noch ein paar Infos dazu:

     

    X.400

     

    X.500

     

     

    x.400 hat mit LDAP soviel zu tun wie die Sonne mit Schnee.... (gut, vielleicht doch ein bsischen mehr... :D )

     

    Ausserdem:

    By default, a global catalog server listens on port 3268 for LDAP communications.

    http://www.microsoft.com/technet/prodtechnol/exchange/EXBPA/9a94d369-36f9-4bf3-b253-45a2d1955a26.mspx

     

     

    Gruss

    Velius

     

     

    Vielleicht wäre der auch interessant: RFC 2164 - Use of an X.500/LDAP directory to support MIXER address mapping

  15. Ähhhmmm, ich hab da was von Sysprep gelesen.....

     

    Also Sysprep und ein Ghost Task vertragen sich nur bedingt, soll heissen, dass du entweder mit der Sysprep.inf (oder so ähnlich, ist lange her), oder gar niocht der Domäne beitrittst. Ghost kann dich nicht der Domäne beitretten lassen wenn Sysprep verwendet wird, weil die Console schon längst ein Time-out bekommt, während der Sysprep Mini-Setup Wizzard noch am laufen ist, und noch aus anderen Gründen.

     

     

    Also entweder Image laden mit Ghost und dann mit Sysprep weiter, oder mit Ghost Laden und den Ghost Task den Rest machen lassen.

×
×
  • Neu erstellen...