21
Exchange auf SBS 2011 eine bestimmte Netzwerkkarte zuweisen
Hallo an alle Fachleute,
meine Herausforderung ist die folgende:
Ich würde gerne den Datenstrom vom und zum Exchange, der auf einem SBS 2011 läuft, über ein anderes physikalisches Netzwerkinterface führen wie den restlichen Netzwerkverkehr.
Geht das, und wenn ja - wie?
Bisher ist mir noch nichts sinnvolles eingefallen...
Für alle, die (sich oder mich) fragen, wozu man das braucht:
Unsere UTM kann über ein Interface den SSL-Netzwerkverkehr entweder "deep" inspizieren (also das Zertifikat "knacken") - das hat Nachteile bei den Nutzern und verschiedenen Anwendungen.
Oder sie kann bei SSL nur eine Zertifikatsinspektion vornehmen - hier gibt es keine Einschränkungen.
Allerdings lassen sich bei per POP3S/SMTPS/IMAPS übertragenen Emails nur dann Spam- und Antivirenfilter anwenden, wenn die SSL deep inspection läuft.
Beide Varianten in 2 verschiedene policies zu packen und auf dem gleichen Interface laufen zu lassen geht nach bisherigen Tests nicht.
Ergo muß ich den Verkehr trennen, damit die UTM ihre Arbeit komplett machen kann.
Ich danke allen, die mich mit Ideen überhäufen
Beste Grüße,
GN
meine Herausforderung ist die folgende:
Ich würde gerne den Datenstrom vom und zum Exchange, der auf einem SBS 2011 läuft, über ein anderes physikalisches Netzwerkinterface führen wie den restlichen Netzwerkverkehr.
Geht das, und wenn ja - wie?
Bisher ist mir noch nichts sinnvolles eingefallen...
Für alle, die (sich oder mich) fragen, wozu man das braucht:
Unsere UTM kann über ein Interface den SSL-Netzwerkverkehr entweder "deep" inspizieren (also das Zertifikat "knacken") - das hat Nachteile bei den Nutzern und verschiedenen Anwendungen.
Oder sie kann bei SSL nur eine Zertifikatsinspektion vornehmen - hier gibt es keine Einschränkungen.
Allerdings lassen sich bei per POP3S/SMTPS/IMAPS übertragenen Emails nur dann Spam- und Antivirenfilter anwenden, wenn die SSL deep inspection läuft.
Beide Varianten in 2 verschiedene policies zu packen und auf dem gleichen Interface laufen zu lassen geht nach bisherigen Tests nicht.
Ergo muß ich den Verkehr trennen, damit die UTM ihre Arbeit komplett machen kann.
Ich danke allen, die mich mit Ideen überhäufen
Beste Grüße,
GN
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 327365
Url: https://administrator.de/forum/exchange-auf-sbs-2011-eine-bestimmte-netzwerkkarte-zuweisen-327365.html
Ausgedruckt am: 23.12.2024 um 03:12 Uhr
21 Kommentare
Neuester Kommentar
Hallo,
Ja, händisch einrichten.
Gruß,
Peter
Ja, händisch einrichten.
Bisher ist mir noch nichts sinnvolles eingefallen...
Hat dein SBS denn überhaupt 2 Netzwerkkarten? dann wirst du feststellen das die Assistenten nicht genutzt werden dürfen. Die sind nämlich auf das vorhendensein von nur einer LAN Karte ausgelegt. Der SBS 2003 und dessen Assistenten konnten aber 2 LAN Karten. damit wirst du alless per hand und ohne Assistenten einrichten müssen - DNS, DHCP, (WINS), Sharepoint, Monitoring, SBS Interne SQL Instanzen, WSUS, evtl. RRAS, IIS und natürlich dein Exchange. Du hast dann einen Multihomed SBS 2011 - das ist nicht ganz trivial und eher nicht vorgesehen.Gruß,
Peter
Hallo,
- VLANs zur Trennung
- Layer3 Switch für das Routing und DHCP der VLANs
- Alle anderen NICs im BIOS deaktivieren damit die Assistenten durchklauen können
Gruß
Dobby
Ich würde gerne den Datenstrom vom und zum Exchange, der auf einem SBS 2011 läuft, über ein anderes physikalisches
Netzwerkinterface führen wie den restlichen Netzwerkverkehr.
Mit VLANs und einem Layer3 Switch ginge das.Netzwerkinterface führen wie den restlichen Netzwerkverkehr.
Geht das, und wenn ja - wie?
10 GBit/s NIC rein und dann VLANs anlegen und die anderen im BIOS deaktivieren.Bisher ist mir noch nichts sinnvolles eingefallen...
- 10 GBit/s NIC wegen des Durchsatzes- VLANs zur Trennung
- Layer3 Switch für das Routing und DHCP der VLANs
- Alle anderen NICs im BIOS deaktivieren damit die Assistenten durchklauen können
Gruß
Dobby
Hallo zusammen,
vielen Dank für die superschnellen Antworten!
- ja, der Server hat 4 Netzwerkkarten
- aber nein, wir haben keinen L3-Switch
Vielleicht kann ich das mit den VLANs auf der UTM darstellen, was mir - wenn ich das richtig interpretiere - trotzdem jede Menge händische Konfiguration auf dem SBS bescheren würde. Alles, was ich inzwischen zum Thema multihomed SBS gelesen habe, treibt mir die Tränen in die Augen
Ich dachte ursprünglich an etwas wie 2 gleichberechtigte aktive Karten auf dem System, wobei durch die Firewall den kritischen Anwendungen jeweils der Zugriff auf eine bestimmte Karte untersagt wird.
Beispiel:
Karte 1 ist konnektiert zum certificate inspection port der UTM > hier blockiere ich per Windows Firewall den Zugriff für Exchange
Karte 2 ist konnektiert zum deep inspection port der UTM > hier blockiere ich per Windows Firewall Datev und Webzugriff.
Aber vermutlich übersehe ich bei diesem Szenario was, oder?
Danke & Gruß
GN
vielen Dank für die superschnellen Antworten!
- ja, der Server hat 4 Netzwerkkarten
- aber nein, wir haben keinen L3-Switch
Vielleicht kann ich das mit den VLANs auf der UTM darstellen, was mir - wenn ich das richtig interpretiere - trotzdem jede Menge händische Konfiguration auf dem SBS bescheren würde. Alles, was ich inzwischen zum Thema multihomed SBS gelesen habe, treibt mir die Tränen in die Augen
Ich dachte ursprünglich an etwas wie 2 gleichberechtigte aktive Karten auf dem System, wobei durch die Firewall den kritischen Anwendungen jeweils der Zugriff auf eine bestimmte Karte untersagt wird.
Beispiel:
Karte 1 ist konnektiert zum certificate inspection port der UTM > hier blockiere ich per Windows Firewall den Zugriff für Exchange
Karte 2 ist konnektiert zum deep inspection port der UTM > hier blockiere ich per Windows Firewall Datev und Webzugriff.
Aber vermutlich übersehe ich bei diesem Szenario was, oder?
Danke & Gruß
GN
Aber vermutlich übersehe ich bei diesem Szenario was, oder?
Passiert dabei einmal etwas, nur einmal, dann hast Du die Probleme erst!!!! Wenn einmal etwas nicht passt unddie Software erkennt zwei NICs, dann spinnt der SBS richtig rum und versagt seinen Dienst.
Gruß
Dobby
Hi,
ich habe keine Erfahrungen mit SBS.
Aber wenn dieser tatsächlich (gewollt oder Bug) Probleme bekommt, wenn mehrere NIC, wie ist das dann bei mehreren IP-Adressen auf einer NIC?
Damit müsst man doch die verschiedenen Dienste auch "trennen" können?
E.
ich habe keine Erfahrungen mit SBS.
Aber wenn dieser tatsächlich (gewollt oder Bug) Probleme bekommt, wenn mehrere NIC, wie ist das dann bei mehreren IP-Adressen auf einer NIC?
Damit müsst man doch die verschiedenen Dienste auch "trennen" können?
E.
@emeriks
Nun, leider sind mehrere IP's je NIC keine Lösung, denn auf der UTM muß der Datenverkehr über 2 verschiedene physikalische Interfaces geführt werden, damit die unterschiedlichen SSL-Inspection-Methoden angewendet werden können.
@108012
Sowas in der Richtung befürchte ich leider auch. Ich hatte so gehofft, daß es irgendwie geht. Netze, in denen die verschiedenen Server physikalisch getrennt sind, haben das Problem nicht. Aber mit der All-in-One-Lösung SBS, so scheint es, kann ich wohl die höhere Sicherheit vergessen. Schade
Nun, leider sind mehrere IP's je NIC keine Lösung, denn auf der UTM muß der Datenverkehr über 2 verschiedene physikalische Interfaces geführt werden, damit die unterschiedlichen SSL-Inspection-Methoden angewendet werden können.
@108012
Sowas in der Richtung befürchte ich leider auch. Ich hatte so gehofft, daß es irgendwie geht. Netze, in denen die verschiedenen Server physikalisch getrennt sind, haben das Problem nicht. Aber mit der All-in-One-Lösung SBS, so scheint es, kann ich wohl die höhere Sicherheit vergessen. Schade
Nachtrag:
Im Grunde ist es nicht einmal Exchange gesamthaft, das über eine dedizierte Schnittstelle kommunizieren müsste, sondern nur der POP3-Connector.
Denn es geht ja nur um den Empfang von Mails von einem externen Mailserver im Internet, alles andere kann seine Standard-Prüfung behalten.
Sprich, ich formuliere das Problem nochmal um:
Gibt es auf dem SBS 2011 die Möglichkeit, einem Dienst wie dem POP3-Connector eine spezifische Netzwerkkarte zuzuweisen und alle anderen Dienste von dieser Karte auszuschließen?
Danke allen, die sich bisher und in Zukunft beteiligt haben
Beste Grüße,
GrandN
Im Grunde ist es nicht einmal Exchange gesamthaft, das über eine dedizierte Schnittstelle kommunizieren müsste, sondern nur der POP3-Connector.
Denn es geht ja nur um den Empfang von Mails von einem externen Mailserver im Internet, alles andere kann seine Standard-Prüfung behalten.
Sprich, ich formuliere das Problem nochmal um:
Gibt es auf dem SBS 2011 die Möglichkeit, einem Dienst wie dem POP3-Connector eine spezifische Netzwerkkarte zuzuweisen und alle anderen Dienste von dieser Karte auszuschließen?
Danke allen, die sich bisher und in Zukunft beteiligt haben
Beste Grüße,
GrandN
Nun, leider sind mehrere IP's je NIC keine Lösung, denn auf der UTM muß der Datenverkehr über 2 verschiedene physikalische Interfaces geführt werden, damit die unterschiedlichen SSL-Inspection-Methoden angewendet werden können.
Ja und? "Unsere UTM" läuft doch nicht auf dem SBS selbst, oder?Gibt es auf dem SBS 2011 die Möglichkeit, einem Dienst wie dem POP3-Connector eine spezifische Netzwerkkarte zuzuweisen und alle anderen Dienste von dieser Karte auszuschließen?
Ich denke nicht. Mit POP3-Connector ist der Conector gemeint, mit welchem von externen POP3-Mailboxen die Mails abgeholt werden?Falls ja: Dann ist das kein Server sondern eine Client-Anwendung. Und sowas bekommst Du nur über Routing auf eine bestimmte Netzkarte "geführt". Also wenn der SBS 2 NIC hat, je eine in einem anderen Subnet, dann muss der SBS die POP3-Server, welche der POP3-Connector abfragen soll, eben nur über Routen erreichen können/dürfen, welche über das Subnet der gewünschten NIC gehen.
E.
Hallo,
Beim SBS 2011 ist es per Design. Natürlich kann der darunterliegende Server 2008R2 mehr als eine NIC, aber die Asisstenten eines SBS 2011 können eben nur mit einer NIC. Wenn man komplett auf die Asisstenten verzichtet (ab sofort und für immer), kann ein Manuelles Einrichten von DNS, DHCP, (WINS), IIS, Sharepoint, SBS eigene SQL Instanzen, WSUS, Exchange usw. schon gemacht werden. Nur wer beherrscht das wenn er einen SBS einsetzt? Beim SBS 2003 konnten die Asisstenten sehr wohl mit mehrere NICs umgehen, da war ja auch ein ISA 2004 für vorgesehen (in der Premium Edition vom SBS 2003). Wurde aber mit SBS 2008 wieder auf eine NIC gebracht (und der ISA später eingestampft). Sollte aber irgenein Asisstent später mal angestossen werden, dann kann das ganze Kartenhaus zusammenfallen. Die Asisstenten kennen kein Pardon, spucken halt nur Fehler aus und nichts was vorher noch lief funktioniert dann wirklich
Gruß,
Peter
Beim SBS 2011 ist es per Design. Natürlich kann der darunterliegende Server 2008R2 mehr als eine NIC, aber die Asisstenten eines SBS 2011 können eben nur mit einer NIC. Wenn man komplett auf die Asisstenten verzichtet (ab sofort und für immer), kann ein Manuelles Einrichten von DNS, DHCP, (WINS), IIS, Sharepoint, SBS eigene SQL Instanzen, WSUS, Exchange usw. schon gemacht werden. Nur wer beherrscht das wenn er einen SBS einsetzt? Beim SBS 2003 konnten die Asisstenten sehr wohl mit mehrere NICs umgehen, da war ja auch ein ISA 2004 für vorgesehen (in der Premium Edition vom SBS 2003). Wurde aber mit SBS 2008 wieder auf eine NIC gebracht (und der ISA später eingestampft). Sollte aber irgenein Asisstent später mal angestossen werden, dann kann das ganze Kartenhaus zusammenfallen. Die Asisstenten kennen kein Pardon, spucken halt nur Fehler aus und nichts was vorher noch lief funktioniert dann wirklich
Gruß,
Peter
Aber wie ist das mit mehreren IP-Adressen auf einer NIC?
Genau das ist der Punkt. Davon werde ich die Finger lassen.
Zitat von @emeriks:
Also wenn der SBS 2 NIC hat, je eine in einem anderen Subnet, dann muss der SBS die POP3-Server, welche der POP3-Connector abfragen soll, eben nur über Routen erreichen können/dürfen, welche über das Subnet der gewünschten NIC gehen.
Also wenn der SBS 2 NIC hat, je eine in einem anderen Subnet, dann muss der SBS die POP3-Server, welche der POP3-Connector abfragen soll, eben nur über Routen erreichen können/dürfen, welche über das Subnet der gewünschten NIC gehen.
In die Richtung wollte ich...das hört sich nach einer Möglichkeit an. Nur: Wie macht man das?
Ich weiß jetzt nicht, was "Unsere UTM" ist und ob Du mit POP3-Connector das meinst, was ich annehme.
Aber im Prinzip geht das so:
A hat 2 NIC
B hat 1 NIC
alle drei kommen ins selbe Segment (VLAN).
A1 und A2 bekommen je 1 IP-Adressen aus verschiedenen IP-Subnetzen.
B1 bekommt 2 IP-Adressen, je eine aus den beiden IP-Subnetzen.
Jetzt kann man auf B für bestimmte Ziele fixe Routen festlegen, jeweils mit einer der IP-Adressen von A als Next Hop.
Somit kann man steuern, dass der Datenverkehr von B zu bestimmten Zielen entweder über IP von A1 oder über IP von A2 gesendet wird.
Nun mögen mich die Netzwerk-Spezis unter Euch bitte nicht steinigen. Das ist "nur so eine Idee" ...
Aber im Prinzip geht das so:
A hat 2 NIC
B hat 1 NIC
alle drei kommen ins selbe Segment (VLAN).
A1 und A2 bekommen je 1 IP-Adressen aus verschiedenen IP-Subnetzen.
B1 bekommt 2 IP-Adressen, je eine aus den beiden IP-Subnetzen.
Jetzt kann man auf B für bestimmte Ziele fixe Routen festlegen, jeweils mit einer der IP-Adressen von A als Next Hop.
Somit kann man steuern, dass der Datenverkehr von B zu bestimmten Zielen entweder über IP von A1 oder über IP von A2 gesendet wird.
Nun mögen mich die Netzwerk-Spezis unter Euch bitte nicht steinigen. Das ist "nur so eine Idee" ...
Hallo Emeriks,
hier wird niemand gesteinigt - schließlich wollen alle helfen
Deine Grundannahme ist falsch. Hier nochmal zum Verständnis:
Server A hat die NICs A1 und A2. Momentan ist nur A1 in Betrieb, über A2 soll zukünftig der Email-Verkehr eingehend (POP3 Connector) laufen.
UTM B (eine Fortinet Hardware Firewall) hat ebenfalls 2 NIC's: B1 macht keine SSL deep inspection, B2 führt diese jedoch durch.
Der Datenverkehr, wie ich in gern hätte, sieht so aus:
A1 <> B1 (für Dinge wie Datev, Internet & Co.)
A2 <> B2 (ausschließlich für (eingehenden) Email-Verkehr )
Wenn man nun dem POP3 Connector sagen könnte "Bitte benutze ausschließlich A2", dann wäre mein Problem gelöst
hier wird niemand gesteinigt - schließlich wollen alle helfen
Deine Grundannahme ist falsch. Hier nochmal zum Verständnis:
Server A hat die NICs A1 und A2. Momentan ist nur A1 in Betrieb, über A2 soll zukünftig der Email-Verkehr eingehend (POP3 Connector) laufen.
UTM B (eine Fortinet Hardware Firewall) hat ebenfalls 2 NIC's: B1 macht keine SSL deep inspection, B2 führt diese jedoch durch.
Der Datenverkehr, wie ich in gern hätte, sieht so aus:
A1 <> B1 (für Dinge wie Datev, Internet & Co.)
A2 <> B2 (ausschließlich für (eingehenden) Email-Verkehr )
Wenn man nun dem POP3 Connector sagen könnte "Bitte benutze ausschließlich A2", dann wäre mein Problem gelöst
Server A hat die NICs A1 und A2
Es wurde eigentlich schon mehrfach erwähnt, dass ein DC (egal ob SBS oder Standard) nur eine Netzwerkkarte habe soll. Wäre auch für deine Umgebung empfehlendswert.
Wenn man nun dem POP3 Connector sagen könnte "Bitte benutze ausschließlich A2", dann wäre mein Problem gelöst
Das ist der falsche Ansatz. Das Problem muss schon vorher gelöst werden und nicht erst am Endpunkt und dort mir dem Finger über den Ar... ins Auge.
Wobei ich mich frage ob sich für POP3 überhaupt der Aufwand lohnt, bzw. nicht sowieso fehl am Platz ist. Schließlich liegen die Daten beim Provider mit ziemlicher Sicherheit sowieso unverschlüsselt herum oder werden verschlüsselt angeleifert.
Wenn schon auf Sicherheit Wert gelegt wird, dann bitte gleich konsequent und durchgehend.
LG Günther
Zitat von @GuentherH:
Es wurde eigentlich schon mehrfach erwähnt, dass ein DC (egal ob SBS oder Standard) nur eine Netzwerkkarte habe soll. Wäre auch für deine Umgebung empfehlendswert.
Es wurde eigentlich schon mehrfach erwähnt, dass ein DC (egal ob SBS oder Standard) nur eine Netzwerkkarte habe soll. Wäre auch für deine Umgebung empfehlendswert.
Hallo Günther,
daß das mit den mehrfachen NIC's keine gute Idee ist, habe ich bereits verstanden. Die übergeordnete Antwort für mein Problem lautet daher: Es geht nicht.
Wobei ich mich frage ob sich für POP3 überhaupt der Aufwand lohnt, bzw. nicht sowieso fehl am Platz ist. Schließlich liegen die Daten beim Provider mit ziemlicher Sicherheit sowieso unverschlüsselt herum oder werden verschlüsselt angeleifert.
Wenn schon auf Sicherheit Wert gelegt wird, dann bitte gleich konsequent und durchgehend.
Wenn schon auf Sicherheit Wert gelegt wird, dann bitte gleich konsequent und durchgehend.
Hier muß ich widersprechen: Es ist sehr wohl notwendig, eingehende Emails auf Viren und Spam zu prüfen - bevor sie auf den eigenen internen Server gelangen.
Denn a) tut dies nicht jeder Provider so, wie man das vielleicht möchte (bzw. möchte man vielleicht sogar seine eigenen Spam-Parameter setzen etc.). Einfach den Provider wechseln ist halt nicht in jedem Umfeld möglich.
Und b) ist diese Notwendigkeit der Prüfung auf Spam und Viren eben nicht abhängig davon, ob die Nachrichten verschlüsselt oder unverschlüsselt übertragen werden. Auch eine verschlüsselt übertragene Nachricht kann Viren enthalten oder Spam sein.
Lediglich die Behandlung der Nachrichten auf der UTM muß für verschlüsselte und unverschlüsselte separat erfolgen (was eine Einschränkung seitens der UTM ist, aber nichts mit der eigentlichen Notwendigkeit zu tun hat).
Schlussendlich stellt sich die Frage, was denn konsequent wäre in puncto Email-Sicherheit?
Natürlich könnte ich einen Fortinet Secure-Email-Gateway mit der Fortigate verbinden und die Nachrichtenüberprüfung dorthin auslagern (diese Lösung ist in der Fortigate explizit vorgesehen) - nur gibt es dafür eben kein Budget
Deine Grundannahme ist falsch. Hier nochmal zum Verständnis:
Server A hat die NICs A1 und A2. Momentan ist nur A1 in Betrieb, über A2 soll zukünftig der Email-Verkehr eingehend (POP3 Connector) laufen.
UTM B (eine Fortinet Hardware Firewall) hat ebenfalls 2 NIC's: B1 macht keine SSL deep inspection, B2 führt diese jedoch durch.
Der Datenverkehr, wie ich in gern hätte, sieht so aus:
A1 <> B1 (für Dinge wie Datev, Internet & Co.)
A2 <> B2 (ausschließlich für (eingehenden) Email-Verkehr )
Wenn man nun dem POP3 Connector sagen könnte "Bitte benutze ausschließlich A2", dann wäre mein Problem gelöst
Ich muss gestern vergessen haben, meine Antwort abzusenden ... Server A hat die NICs A1 und A2. Momentan ist nur A1 in Betrieb, über A2 soll zukünftig der Email-Verkehr eingehend (POP3 Connector) laufen.
UTM B (eine Fortinet Hardware Firewall) hat ebenfalls 2 NIC's: B1 macht keine SSL deep inspection, B2 führt diese jedoch durch.
Der Datenverkehr, wie ich in gern hätte, sieht so aus:
A1 <> B1 (für Dinge wie Datev, Internet & Co.)
A2 <> B2 (ausschließlich für (eingehenden) Email-Verkehr )
Wenn man nun dem POP3 Connector sagen könnte "Bitte benutze ausschließlich A2", dann wäre mein Problem gelöst
Also heute noch einmal:
In meinem Bsp. war die UTM A und der SBS B.
Wenn Server Server an einer NIC 2 IP-Adressen, je eine aus einem Netz hat, dann
B-NIC1-IPnetz1
B-NIC1-IPnetz2
Und die UTM 2 NIC mit je einer Adresse aus je einem der Netze.
A-NIC1-IPnetz1
A-NIC2-IPnetz2
Und ich auf dem SBS für die POP3-Server draussen bei den Providern statische Routen festlege
route add POP3-Server-Provider1 mask 255.255.255.255 A-NIC2-IPnetz2
route add POP3-Server-Provider2 mask 255.255.255.255 A-NIC2-IPnetz2
Dann wird der POP3-Connector seine Anfragen an die externen POP3-Server immer über die 2. NIC der UTM senden.
Oder?
Der Haken dabei ist nur, dass man verhindern muss, dass sich der SBS mit beiden IP-Adressen ins DNS einträgt, da sonst die internen Clients Probleme bekommen.
Dieser Hinweis auch für "multihomed" DC: Alles kein Problem, solange man sicherstellt, dass die Clients immer eine IP-Adresse aufgelöst bekommen, über welche sie den DC erreichen können.
Es ist sehr wohl notwendig, eingehende Emails auf Viren und Spam zu prüfen - bevor sie auf den eigenen internen Server gelangen.
Dem stimme ich auch vollkommen zu. Aber die Überprüfung muss an der passenden stelle geschehen
Natürlich könnte ich einen Fortinet Secure-Email-Gateway mit der Fortigate verbinden und die
Nachrichtenüberprüfung dorthin auslagern (diese Lösung ist in der Fortigate explizit vorgesehen) - nur gibt es dafür eben kein Budget
Nachrichtenüberprüfung dorthin auslagern (diese Lösung ist in der Fortigate explizit vorgesehen) - nur gibt es dafür eben kein Budget
Und da eben liegt das Problem. Man kann nicht Sicherheit verlagen, aber dafür nichts ausgeben. Und, man kann dann nicht diese falsche Sparsamkeit mit einem Flickwerk lösen, das wahrscheinlich einige unangenehme Seiteneffekte mit sich bringt.
Schlussendlich stellt sich die Frage, was denn konsequent wäre in puncto Email-Sicherheit?
Zustellung der Nachrichten über SMTP, alles anderen macht nicht wirklich Sinn. In der DMZ kann dann ein Linux Server die notwendigen Dienste abwickeln (Spam, Viren was auch immer). Es gibt zu diesem Thema genügend HowTos hier am Board und für das nötige Budget sollte wohl auch in der sparsamten Firma vorhanden sein.
LG Günther
Hallo Günther,
auch wenn Du technisch ins Schwarze triffst, so gibt es doch Situationen, bei denen man aus den gegebenen Umständen eben das maximale herausholen muß, ohne gleich alles komplett umzukrempeln.
In solch einer Situation sind wir hier - deshalb gab es diese Frage.
Beispielsweise musste ich auf auf meinem eigenen Server auch einen Umweg machen: Weil einer von mehreren externen SMTP-Mailservern partout nicht mit meinem sprechen wollte, mußte ich auf meinem Server eine virtuelle Maschine aufsetzen, einen Freeware-Mailserver dort hineinpflanzen - und dieser übernimmt nun quasi die Vermittlerrolle zwischen meinem und dem externen.
Ganz klar: Auch das ist besagtes Flickwerk, aber es funktioniert bestens.
Happy Weekend an alle.
GrandN
auch wenn Du technisch ins Schwarze triffst, so gibt es doch Situationen, bei denen man aus den gegebenen Umständen eben das maximale herausholen muß, ohne gleich alles komplett umzukrempeln.
In solch einer Situation sind wir hier - deshalb gab es diese Frage.
Beispielsweise musste ich auf auf meinem eigenen Server auch einen Umweg machen: Weil einer von mehreren externen SMTP-Mailservern partout nicht mit meinem sprechen wollte, mußte ich auf meinem Server eine virtuelle Maschine aufsetzen, einen Freeware-Mailserver dort hineinpflanzen - und dieser übernimmt nun quasi die Vermittlerrolle zwischen meinem und dem externen.
Ganz klar: Auch das ist besagtes Flickwerk, aber es funktioniert bestens.
Happy Weekend an alle.
GrandN
Hallo Emeriks,
sorry, dann hatte ich Dich mißverstanden, was die Gerätebezeichnungen etc. angeht - Danke für's neu posten.
Das klingt...plausibel. Bis auf den Punkt, daß man doch nur für den Adapter und nicht für einzelne IP's den DNS-Eintrag abschalten kann, oder habe ich da was übersehen?
Im Grunde kommt Deine Lösung diesem hier nahe:
Probleme mit Multihomed DCs vermeiden
Ich werde mal drüber nachdenken
Dankeschön & schönes Wochenende.
Gruß
GrandN
sorry, dann hatte ich Dich mißverstanden, was die Gerätebezeichnungen etc. angeht - Danke für's neu posten.
Das klingt...plausibel. Bis auf den Punkt, daß man doch nur für den Adapter und nicht für einzelne IP's den DNS-Eintrag abschalten kann, oder habe ich da was übersehen?
Im Grunde kommt Deine Lösung diesem hier nahe:
Probleme mit Multihomed DCs vermeiden
Ich werde mal drüber nachdenken
Dankeschön & schönes Wochenende.
Gruß
GrandN
Das klingt...plausibel. Bis auf den Punkt, daß man doch nur für den Adapter und nicht für einzelne IP's den DNS-Eintrag abschalten kann, oder habe ich da was übersehen?
Schtümmt ....Dann müsstest Du es einrichten, dass die Clients den DC über beider Adressen ereichen können.
