Site-to-Site mit Rechnerzentrum und die Netz-Erreichbarkeit

[Koppelfeld]

Es handelt sich hier um einen der größten deutschen IT-Unternehmen

Das wird das Problem sein. Die stellen Studis ein, die nach dem Druckbetankungsprinzip gezielt auf eine Klausur gepaukt und nach vier Wochen alles wieder vergessen haben.
Die kriegen aber gar nicht mit, was zum Beispiel der Unterschied zwischen einem Repeater, einer Bridge oder einem Router ist.
Schließlich haben sie vom Sakrament des Gottes Pezehdos gekostet und wissen daher, daß die Unterschichtflundern sich mit "Bonjour" und "NetBIOS" sich automatisch vernetzen.

Ich würde dem Dienstleister eine schriftliche Begründung abnötigen und dann einmal richtig Ärger machen.

[Kosta]

Würde(n) ich(wir) tun, wäre das nicht unser Mutterkonzern. Wir sind zwar GmbH in .at, jedoch obliegen wir zum Teil dem MK, auch wenn wir was für das Hosting dort zahlen müssen. Auch dann ist es schwer sich groß aufzuspielen.

Ich habe grundlegend beschlossen, dass wenn die NAT nicht umgegangen werden kann, den lokalen DC nicht machen werde - da setze ich meine Grenze durch. Je mehr ich davon gelesen habe oder überlegt habe wieviele Komplikationen das bringen kann (und noch dazu von MS nicht supportet ist), desto mehr habe ich beschlossen sich an gewisse Regeln zu halten.

Ich werde die DCs nur in RZ halten, DHCP wird DNS vom DC in DNS verteilen und fertig.

Apropos DHCP... wie sieht es da mit NAT? Probleme? Ich kann DHCP auch im LANCOM machen, aber lieber wäre mir im DC (geht ja prima mit dem Relay im LANCOM).

[PappaBaer]

Hi,

das Problem, warum das Rechenzentrum auf das N:N-NAT besteht, wird mit Sicherheit sein, dass euer lokal verwendetes Subnet 10.146.32.0/24 im RZ bereits verwendet wird oder auch nur ein Teil eines dort bereits verwendeten Subnetzes ist. Daher dann die N:N-Maskierung im RZ um die Eindeutigkeit und damit Routebarkeit (geiles Wort...) zu wahren.
Das ist der einzige für mich schlüssige Grund, warum das so sein sollte.

Grüße,
Torsten

[Kosta]

Aha, und sie können einfach nicht erlauben dass auf irgendeine Weise ins RZ mit 10.146.32.0 reinkommen, auch indirekt.
Und es bringt mir auch nichts wenn DC lokal auch im RZ-Netz wäre, da die Clients zwingend im 10.146.32.0 sein müssen.

An schas, wie man schön hier sagt.

Danke.

[PappaBaer]

Hi,

wenn es so ist, wie ich vermute, würden sich euer Subnetz und ein Subnetz im Rechenzentrum oder evtl. auch von einem anderen Kunden, der auch über VPN am RZ angeschlossen ist, überschneiden. Somit wären dann keine eindeutigen Routingentscheidungen mehr möglich. Somit sehe ich keine Chance, dass ihr da im RZ irgendwie mit IP-Paketen ankommt, in denen eine Adresse aus eurem LAN als Quelle steht.
Wie gesagt: immer vorausgesetzt, das Szenario ist so, wie ich es vermute.
Kannst natürlich nachfragen, ob das so ist und ob die ne Möglichkeit sehen, dass das andere Subnetz, welches mit eurem in Konflikt stehen würde, geändert werden kann bzw. dort N:N genattet werden könnte, aber ganz ehrlich: da würde ich mir nicht allzu viele Chancen ausrechnen.

Ob ein N:N-NAT bezüglich der DCs die gleichen Probleme verursacht wie ein 1:N-NAT kann ich nicht beurteilen. Hier wird ja ein komplettes Subnetz 1:1 umgesetzt und nicht x Rechner hinter einer IP-Adresse versteckt.

Grüße,
Torsten

[Kosta]

Ich glaube du vermutest richtig. Mir wurde auch noch am Anfang der Sache gesagt, dass die nicht erlauben können dass die Nutzer die IP-Ranges bestimmen, da die VPN-Terminierungs-Punkte geteilt sind, und hier müssen die Netze eindeutig sind (also vom RZ vorgegeben).
Daher macht Sinn was du sagst - jetzt habe ich geschnallt was das bedeutet.

Ich habe auch noch überlegt was ich tun müsste um NAT umzugehen... es gäbe eine Möglichkeit, und zwar unsere DC und die Clients in das 10.241.56.0 zu setzen, jedoch dann müsste ich ins 10.146.32.0 NATen, da unser Terminal Server Router, der im 10.146.32.0 Netz ist, nur die Adressen aus dem 10.146.32.0 akzeptiert, und das ist auch nicht änderbar.

Wir sind grundsätzlich von zwei Seiten sozusagen gesperrt, und NATen können wir nicht vermeiden, wenn ich es richtig verstehe, aber die Möglichkeit gäbe das obere zu machen.

Befürchte aber das wäre sehr gefährlich zu tun, da ich die Konsequenzen nicht kenne, und ob das überhaupt verlässlich funktionieren würde - vor allem weil der TS-Router unserseits auch nicht konfigurierbar ist.

Es läuft langsam darauf hinaus dass wir DCs NUR im RZ haben werden, und DHCP lokal auf dem Router (sofern DHCP im RZ mit Relay am Router nicht funktioniert - muss ich testen). DHCP am 2012R2 ist um einiges leichter zu managen, übersichtlicher und eigentlich einfacher.