Ok, dazu hätte ich eine Idee:
Ich gehe davon aus, dass der Terminalserver in Firma A ist.
Lass mal für den Anfang den Gedanken an VM weg, sondern stell Dir das wie getrentte Hardware vor:
Die beiden Netze sind genau so in Ordnung, Firma B hat fast ausschließlich Clients, arbeitet also fast komplett für sich alleine, auch der Internetzugang ist hier kein Problem, Drucker, alles ins 192.168.2er Netz. Firma B arbeitet ebenfalls für sich. Nur
der Terminalserver muss von Firma B bedient werden können.
Baue also zwei logisch komplett getrennt Netze auf und setze einen Router dazwischen. Ob Du das über einen Windows-Server löst oder über ein "Stück Blech", was natürlich ebenfalls virtuell sein darf (z.B. pfsense), ist da mal egal. Ich bin kein
Freund von Widows-Rechnern als Router, denn für das, was die können, ist mir die Lizenz zu teuer. Dem Router erklärst Du nun folgendes:
- Firma B darf auf den TS von Firma A zugreifen.
- Die DCs der beiden Firmen dürfen sich untereinander unterhalten.
- Der TS darf die Drucker der Firma B ansteuern (falls nötig).
- Der TS darf mit dem Exchange der Firma B kommunizieren (falls nötig). Kann auch auf OWA beschränkt werden, wenn es nur gelegentliche Anwendung ist.
Zwischen den beiden DCs muss nun eine Vertrauensstellung hergestellt werden. Auf dem DC von Firma A muss ggf. für die User von Firma B für die Verwendung des TS eine gesonderte GPO erstllt werden, z.B. wenn die den Internetzugang von Firma A nicht nutzen
sollen.
Was den Exchange der Firma B und deren Internetzugang angeht: Leistung kostet Geld. Leitung auch. Wenn Firma A damit einverstnaden ist und sich der Aufwand lohnt (weil die Mails so groß sind, weil es so viele Mails gibt...), könntest Du den Router noch mit
bedingtem Routing beauftragen: "If source = Exchange B then Gateway = SecurepointFaA". Beide Exchange direkt ins Internet veröffentlichen klappt so über einen einzigen Zugang nicht, was ich aber in der Konstellation ohnehin dringend NICHT tun würde.
Also auch nicht nur einen davon. In der Konstellation würde ich immer mit einem externen Mailserver arbeiten, also Postfach bei xyz und dann die Exchange davon abrufen und darüber versenden lassen. Weil sich das aber auch wunderbar timen lässt und man auch
die Bandbreite regulieren kann, kann der Exchange B auch über die eigene, schmale Leitung arbeiten. Dauert halt vielleicht hier und da eine Minute länger. Wenn denen das zu langsam ist: für etwas mehr Geld wird es sicherlich auch etwas mehr Lei(s)tung geben.
Nun zu der Virtualisierungsgeschichte: Ist weiter kein Problem, Du musst nur auf die saubere Trennung achten. Ich würde auch hier nicht nur, weil es gerade da ist, das Routing über Windows-Rechner machen, sondern ein weiteres Gerät (gerne auch virtuell)
einsetzen. Ich kenne mich mit Hyper-V nicht weiter aus, nur so die Basics von vor fünf Jahren oder so, wir arbeiten mit VMware. Das Routing, wie in dem MSDN-Blgo beschrieben, verbindet die beiden Netze komplett, d.h., da könntest Du genausogut ein einziges
Netz nehmen, 192.168.0.1-99 für Firma A, .101-199 für Firma B, .100 das Gateway, ab .201 Drucker usw., hätte den gleichen Effekt, wäre nur einfacher.
Was das Multipath-Routing über mehrere Internetanschlüsse angeht: Ja. Bin ich immer dabei. Wenn es die Verantwortlichen der beiden Firmen zulassen. Schwierig wird es nämlich dann, wenn illegale Dinge passieren und auffallen: dann wird nämlich erst einmal
beiden Firmen auf die Finger geklopft. Ich hatte so etwas mal nur bei einer Firma, da arbeitet man dann zwei, drei Tage nicht mehr wirklich. Also nur noch für den Zoll eigentlich ;-)
Technisch gesehen eine gute Lösung, Firma A zahlt die teuren Leitungen und Firma B nutzt sie mit. Genauso wie den TS. So könntest Du Szenarien wie weiter oben beschrieben weiter entwickeln: "if source = Exchange A then Line A, if source = Exchange B
then Line A, else Line A+B" oder so.
So, eine Menge Text, ich hoffe, es ist ein Gedankenanstoß dabei, der Dir weiterhilft!
Viel Erfolg dabei!
YotYot
