Skip to content

zkmlf: Architekturanpassungen vorschlagen, Altlasten von morgen verhindern

Oft stolpert man bei der Vorbereitung einer Migration auf Altlasten, deren Implementierung im neuen System zwar möglich ist, man das aber aus verschiedenen Gründen nicht möchte. Manche Kunden sind dazu bereit, im Rahmen des laufenden Projekts auch an anderen Stellen Anpassungen vorzunehmen, die ihnen in Zukunft das Leben erleichtern. Man sollte sich nicht scheuen, solche Maßnahmen vorzuschlagen - etwas Blick über den Tellerrand hat noch keinem geschadet.

So hatte ein von mir besonders gehasstes Firewallprodukt die Möglichkeit, durch einfache und für wenig erfahrene Leute verständliche Konfiguration Zugriffe auf gewisse Ports einer IP-Adresse aus dem äußeren Transfernetz durch eine ekelhafte Kombination aus Proxy-ARP und Destination NAT auf einen "innen" liegenden Server weiterzuleiten. Da dieses Feature so schön einfach zu nutzen ist (man muss nicht beim ISP um ein weiteres Netz offizieller IP-Adressen für "innen" liegende Server betteln und ihn nicht um statische Routen bitten), wurde das natürlich auch fleißig benutzt. Auf "richtigen" Firewalls muss man sich für die Nachbildung mit virtuellen IP-Adressen oder Alias-Adressen einen abbrechen und den ganzen Mist auch noch dokumentieren. Dabei wäre es doch viel einfacher, es gleich "richtig" zu machen, dem Zielserver eine offizielle IP-Adresse aus einem neuen Servicenetz zu verpassen und den Traffic einfach nach passender Filterung weiterzurouten.

Auch immer wieder gern genommen ist die Classful-Denke vieler historisch ausgebildeter Leute, für die es keine Prefixlängen zwischen /16 und /24 gibt und die für ihr 300-Client-Netz deswegen ein "flaches" /16-Netz, gerne das komplette 192.168/16 oder Standardprefixe wie 10.0/16. Wenn man dann aufgekauft wird oder aus anderen Gründen das eigene Netz mit einem Gegner verheiraten muss, der denselben Designfehler gemacht hat, darf entweder einer der beiden renumbern oder man muss sich auf beiden Seiten mit NAT einen abbrechen. Letzteres geht üblicherweise damit einher, dass man aus Gründen der "Einfachheit" nicht mit DNS arbeitet, sondern direkt IP-Adressen der Gegenseite überall einträgt, was dazu führt, dass bei weiteren Umstellungsarbeiten entweder noch mehr geNATtet wird oder man sich schwer zu debuggende Fehler oder noch aufwändigere Migration einfängt. Daraus entsteht meine Empfehlung, Netze immer noch so groß wie nötig, aber so klein wie möglich zu machen und den Prefix aus den zur Verfügung stehenden Adressräumen zusammenzuwürfeln, möglichst nicht systematisch. Denn auf Ideen wie "10.49.62/24 ist Deutschland, Rhein-Neckar", sind vor uns auch noch andere gekommen.

Und dann gibt es natürlich auch die Designfehler, die man ohne Neuinstallation der gesamten Windows-Welt niemalsnie wieder los wird. Besonders gern genommen natürlich der "example.com" als AD-Root der Example GmbH, die extern genauso benutzt wird. Wenn man sich hier vertut, hat man "innen" andere Fehler als "außen", merkt "innen" nicht, dass außen der RR für www.example.com oder gar der MX für example.com verschwunden ist, oder es steht mitten in der Migration das Marketing auf Deinem Fuß und brüllt Dich an, warum die Aktionswebseite nicht mehr aufgelöst werden kann. Ich bin übrigens kurz davor, einen Preis dafür auszuloben, dass mir jemand das Microsoft-Whitepaper beschafft, in dem der Example Ltd explizit davon abgeraten wird, für ihr AD den Root intern.example.com zu verwenden, wenn example.com "draußen" produktiv verwendet wird - denn das wäre eine Konfiguration, die aus meiner Sicht ausgesprochen sinnvoll wäre.

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

Christian on :

http://technet.microsoft.com/en-us/library/bb727085.aspx

Section "Designing the Forest Root Domain": [...] Add a prefix that is not currently in use to the registered DNS name to create a new subordinate name. For example, if your DNS root name were contoso.com then you should create an Active Directory forest root domain name such as concorp.contoso.com, where the namespace concorp.contoso.com is not already in use on the network. [...]

Marc 'Zugschlus' Haber on :

Microsoft empfiehlt also genau dasselbe was ich auch für sinnvoll halte, und die Leute mit denen ich über diese Frage aneinanderrasseln empfehlen exakt das Gegenteil von dem was Microsoft empfiehlt und berufen sich dabei auf ein MS-Whitepaper?

Das ist ja mal eine interessante Erkenntnis...

Add Comment

Markdown format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
Form options