21
Fernadministration über VPN
Hallo zusammen,
ich habe ein Aufgabenstellung bei einem Firmenkunden, bei der ich leider nicht wirklich weiterkomme. Das Firmennetzwerk ist Teil einer größeren Händlerstruktur welche hierarchisch durchstrukturiert ist. Ich skizziere mal mit geänderten Daten:
Netzwerk:
10.53.150.0 /24
255.255.255.0
Gateway: 10.53.150.1
PDC/DNS/DHCP: 10.53.150.2
Als Gateway fungiert ein Cisco Router über MPLS von der Firmenzentrale. An dem bestehen leider keine Konfigurationsmöglichkeiten, der ist dicht. Die verschiedenen Server sind alle virtuell auf Esxi mit festen IP inhouse. In der Firma existiert ein Dömänennetzwerk und zwei Arbeitsgruppennetzwerke die vorgegeben sind. Alle Server, NAS, USV etc mit fester IP, alle Clients laufen über DHCP.
Der Internetzugang über den PDC und das Gateway ermöglicht primär Zugang auf das Händler Intranet und die dort bereitgestellten Funktionen und Applikationen im übergeordneten Datencenter. Will man in das normale Internet hinaus muss man sich erst an einem weiteren übergeordneten Proxy anmelden und durch Websense Webfilter hindurch.
Leider werden nicht alle Dienste und Ports durchgeleitet. So geht etwa kein Zugriff auf Dyndns Dienste und auch Windowsupdates werden geblockt. Diverses andere auch. An und für sich ein stimmiges System und weltweit funktionierend aber eben unflexibel. Was die Firmenzentrale nicht haben will, das ermöglicht Sie eben nicht. Man muss sich eigene Lösungen bauen. Verboten ist dies nicht. Sicher sollte es natürlich sein.
Für die Realisierung des Inhouse Mailservers wurde z.B. ein Lancom 1781VA mit eigener Leitung und fester IP angeschafft und in das Netzwerk als 10.53.150.150 intergriert. DNS Record wurde inhouse angelegt, MX Record vom Mailprovider zeigt extern auf die feste IP von außen. Das funktioniert von innen und außen prima.
Für die Realisierung der Netzwerkadministration von außen wurde eine weitere DSL Leitung geschaltet mit einer Fritzbox 7390 momentan. 10.53.150.160. Inhouse steht ein extra Server für die Administration, welcher als Gateway diese Fritzbox verwendet aber intern den 10.53.150.2 als WINS und primären DNS verwendet. So ist er intern in das Netz integriert, auffindbar und kann dennoch ungehindert nach draußen telefonieren. Von außen schalte ich mich per Remote Zugang auf den Server und mache meinen Job.
Dieser Fernwartungsserver macht z.B. das Monitoring über SNMP, ist Syslog Forwarder, dient als WSUS Replikationsserver von mir und auch als zentrale Antiviren Management Konsole. Auch Softwaredeployment kann darüber erledigt werden.
Nun zur Aufgabenstellung:
Die Aufgaben des Fernwartungsservers sollen nun nach Möglichkeit schrittweise ausgelagert werden in meine kleine Serverfarm und über VPN dem Kunden zur Verfügung stehen. So könnten mehrere gleichartige Kunden von den Diensten profitieren und ich habe alles in meiner Firma unter Kontrolle. Wartung, Backups und Pflege eben. Bei mir liegen 3 DSL Leitungen und ein Kabelanschluss auf einem Lancom 1781VA. Weitere Leitungen sind in Aussicht evtl. auch Glasfaser. Bandbreite ist kein Problem.
LAN / LAN VPN Verbindungen kann ich problemlos zu beiden Leitungen des Kunden aufbauen. Sowohl Lancom als auch Fritzbox.
Aber wie kann ich nun eine VPN Konfiguration basteln, daß bei mir ein Server steht und sich exakt so verhält als wäre er wie zuvor dort im Netzwerk?
Bei einer VPN Verbindung komme ich nur auf die Server welche jeweils den Inhouse Lancom oder eben die Fritzbox als Gateway verwenden. In der Firma findet die DHCP Arbeitsstation logischerweise den externen Server nicht, weil Sie nur über ihr Standardgateway geht.
Könnte man am primären Gateway eine Route eingeben, wäre alles easy, aber das geht leider nicht.
Ich bin für jede Idee dankbar wie man das hinbiegen könnte.
Vielen Dank,
MacLeod
ich habe ein Aufgabenstellung bei einem Firmenkunden, bei der ich leider nicht wirklich weiterkomme. Das Firmennetzwerk ist Teil einer größeren Händlerstruktur welche hierarchisch durchstrukturiert ist. Ich skizziere mal mit geänderten Daten:
Netzwerk:
10.53.150.0 /24
255.255.255.0
Gateway: 10.53.150.1
PDC/DNS/DHCP: 10.53.150.2
Als Gateway fungiert ein Cisco Router über MPLS von der Firmenzentrale. An dem bestehen leider keine Konfigurationsmöglichkeiten, der ist dicht. Die verschiedenen Server sind alle virtuell auf Esxi mit festen IP inhouse. In der Firma existiert ein Dömänennetzwerk und zwei Arbeitsgruppennetzwerke die vorgegeben sind. Alle Server, NAS, USV etc mit fester IP, alle Clients laufen über DHCP.
Der Internetzugang über den PDC und das Gateway ermöglicht primär Zugang auf das Händler Intranet und die dort bereitgestellten Funktionen und Applikationen im übergeordneten Datencenter. Will man in das normale Internet hinaus muss man sich erst an einem weiteren übergeordneten Proxy anmelden und durch Websense Webfilter hindurch.
Leider werden nicht alle Dienste und Ports durchgeleitet. So geht etwa kein Zugriff auf Dyndns Dienste und auch Windowsupdates werden geblockt. Diverses andere auch. An und für sich ein stimmiges System und weltweit funktionierend aber eben unflexibel. Was die Firmenzentrale nicht haben will, das ermöglicht Sie eben nicht. Man muss sich eigene Lösungen bauen. Verboten ist dies nicht. Sicher sollte es natürlich sein.
Für die Realisierung des Inhouse Mailservers wurde z.B. ein Lancom 1781VA mit eigener Leitung und fester IP angeschafft und in das Netzwerk als 10.53.150.150 intergriert. DNS Record wurde inhouse angelegt, MX Record vom Mailprovider zeigt extern auf die feste IP von außen. Das funktioniert von innen und außen prima.
Für die Realisierung der Netzwerkadministration von außen wurde eine weitere DSL Leitung geschaltet mit einer Fritzbox 7390 momentan. 10.53.150.160. Inhouse steht ein extra Server für die Administration, welcher als Gateway diese Fritzbox verwendet aber intern den 10.53.150.2 als WINS und primären DNS verwendet. So ist er intern in das Netz integriert, auffindbar und kann dennoch ungehindert nach draußen telefonieren. Von außen schalte ich mich per Remote Zugang auf den Server und mache meinen Job.
Dieser Fernwartungsserver macht z.B. das Monitoring über SNMP, ist Syslog Forwarder, dient als WSUS Replikationsserver von mir und auch als zentrale Antiviren Management Konsole. Auch Softwaredeployment kann darüber erledigt werden.
Nun zur Aufgabenstellung:
Die Aufgaben des Fernwartungsservers sollen nun nach Möglichkeit schrittweise ausgelagert werden in meine kleine Serverfarm und über VPN dem Kunden zur Verfügung stehen. So könnten mehrere gleichartige Kunden von den Diensten profitieren und ich habe alles in meiner Firma unter Kontrolle. Wartung, Backups und Pflege eben. Bei mir liegen 3 DSL Leitungen und ein Kabelanschluss auf einem Lancom 1781VA. Weitere Leitungen sind in Aussicht evtl. auch Glasfaser. Bandbreite ist kein Problem.
LAN / LAN VPN Verbindungen kann ich problemlos zu beiden Leitungen des Kunden aufbauen. Sowohl Lancom als auch Fritzbox.
Aber wie kann ich nun eine VPN Konfiguration basteln, daß bei mir ein Server steht und sich exakt so verhält als wäre er wie zuvor dort im Netzwerk?
Bei einer VPN Verbindung komme ich nur auf die Server welche jeweils den Inhouse Lancom oder eben die Fritzbox als Gateway verwenden. In der Firma findet die DHCP Arbeitsstation logischerweise den externen Server nicht, weil Sie nur über ihr Standardgateway geht.
Könnte man am primären Gateway eine Route eingeben, wäre alles easy, aber das geht leider nicht.
Ich bin für jede Idee dankbar wie man das hinbiegen könnte.
Vielen Dank,
MacLeod
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 321733
Url: https://administrator.de/contentid/321733
Printed on: April 23, 2024 at 10:04 o'clock
21 Comments
Latest comment
Servus,
vielleicht mit einem Layer 2 Tunnel. Als Verlängerung des bestehenden Netzes.
Have fun
vielleicht mit einem Layer 2 Tunnel. Als Verlängerung des bestehenden Netzes.
Have fun
N' Abend,
Also wenn du Zugang zum DHCP-Server hast, kannst du doch z.B. das GW des Lancom eintragen (anstelle des Ciscos) und verteilen lassen.
Auf dem Lancom setzt du dann die Routen.
Alles was dein eigenes Netz betrifft, geht über den Lancom (und somit den VPN) in dein LAN, alles andere verweist auf das Cisco-Gateway, welches für MPLS genutzt wird.
Du müsstest dann aber auch das GW in allen Servern abändern...
Andere alternativen: per Route add in den Windows-Clients und -Servern die Routen in dein Netz setzen. Das halte ich aber für weniger Optimal und zu aufwendig...
Gruß
em-pie
Also wenn du Zugang zum DHCP-Server hast, kannst du doch z.B. das GW des Lancom eintragen (anstelle des Ciscos) und verteilen lassen.
Auf dem Lancom setzt du dann die Routen.
Alles was dein eigenes Netz betrifft, geht über den Lancom (und somit den VPN) in dein LAN, alles andere verweist auf das Cisco-Gateway, welches für MPLS genutzt wird.
Du müsstest dann aber auch das GW in allen Servern abändern...
Andere alternativen: per Route add in den Windows-Clients und -Servern die Routen in dein Netz setzen. Das halte ich aber für weniger Optimal und zu aufwendig...
Gruß
em-pie
Hallo
Das wäre möglich, aber sehr riskant für mich. Würde bekannt, daß ich wichtige Firmenkommunikation DURCH mein eigenes Gateway leite wäre der Teufel los. Ein Defekt am Lancom würde alles lahmlegen, auch das ist nicht akzeptabel. Es sind auch Hardwaregeräte anderer Anbieter in der Firma vorhanden, welche zwingend die 1 als Gateway verwenden.
Wäre eine Lösung über eine minimalistische Hardware/Software denkbar, die als Vermittler fungiert? Die also nach innen wie der Fernwartungsserver wie bisher erscheint, aber die Anfragen entsprechend über das VPN weiterleitet und empfängt? Bin gerne bereit in solide Technik zu investieren.
MfG,
MacLeod
Das wäre möglich, aber sehr riskant für mich. Würde bekannt, daß ich wichtige Firmenkommunikation DURCH mein eigenes Gateway leite wäre der Teufel los. Ein Defekt am Lancom würde alles lahmlegen, auch das ist nicht akzeptabel. Es sind auch Hardwaregeräte anderer Anbieter in der Firma vorhanden, welche zwingend die 1 als Gateway verwenden.
Wäre eine Lösung über eine minimalistische Hardware/Software denkbar, die als Vermittler fungiert? Die also nach innen wie der Fernwartungsserver wie bisher erscheint, aber die Anfragen entsprechend über das VPN weiterleitet und empfängt? Bin gerne bereit in solide Technik zu investieren.
MfG,
MacLeod
Servus,
auf beiden Seiten jeweils einen Mikrotik, darüber EOIP Tunnel und gut ist - das ganze kostet keine 100€ und ist in 10 Minuten konfiguriert.
LG,
Stefan
auf beiden Seiten jeweils einen Mikrotik, darüber EOIP Tunnel und gut ist - das ganze kostet keine 100€ und ist in 10 Minuten konfiguriert.
LG,
Stefan
Aber wie kann ich nun eine VPN Konfiguration basteln, daß bei mir ein Server steht und sich exakt so verhält als wäre er wie zuvor dort im Netzwerk?
LAN zu LAN VPN mit entsprechenden ACLs. Wo ist dein Problem ?Genau DAS ist doch der tiefere Sinn einer LAN zu LAN VPN Lösung.
Ein simpler Klassiker....
Ob du MT, FB, Cisco oder deine Lancom Gurke dazu nimmst ist völlig egal.
Grundlagen zu dem Thema findest du wie immer hier:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Denn VPN-Tunnel hat er ja wohl schon stehen.
Ich glaube sein Problem ist, dass er nicht weiss, wie er den Systemen mitteilen soll, wie diese "seine" Server finden.
Das DAS Gateway wird vom übergerodneten Verband administriert und lässt keine änderungen an den Routing-Einträgen zu. Folglich wollen die Systeme das Cisco-Gateway ansteuern um seine Systeme, die hinter dem Lancom hängen zu erreichen. Der Cisco-Router indes kennt den Lancom als weiteres Gateway aber nicht.
Und am DHCP-Server darf er auch nicht seinen Lancom als Gateway eintragen um dort dann die Routen zu verwalten 8siehe meinen Ansatz oben)
Folglich bliebe ihm wohl nur die Wahl/ Qual, alle erforderlichen Routen direkt am System (z.B. via rout add) zu setzen (zumindest mit meinem brauchbaren aber nicht immer tiefgreifendem Wissensstand)...
Ich glaube sein Problem ist, dass er nicht weiss, wie er den Systemen mitteilen soll, wie diese "seine" Server finden.
Das DAS Gateway wird vom übergerodneten Verband administriert und lässt keine änderungen an den Routing-Einträgen zu. Folglich wollen die Systeme das Cisco-Gateway ansteuern um seine Systeme, die hinter dem Lancom hängen zu erreichen. Der Cisco-Router indes kennt den Lancom als weiteres Gateway aber nicht.
Und am DHCP-Server darf er auch nicht seinen Lancom als Gateway eintragen um dort dann die Routen zu verwalten 8siehe meinen Ansatz oben)
Folglich bliebe ihm wohl nur die Wahl/ Qual, alle erforderlichen Routen direkt am System (z.B. via rout add) zu setzen (zumindest mit meinem brauchbaren aber nicht immer tiefgreifendem Wissensstand)...
Ich glaube sein Problem ist, dass er nicht weiss, wie er den Systemen mitteilen soll, wie diese "seine" Server finden.
Das könnte natürlich so sein aber es ist ja nicht davon auszugehen das sein Firmenkunde so dumm war oder ist, das Routing, sprich Default Gateway, auf ein Infrastruktur System zu legen was er selber nicht administrieren kann.Sowas würde kein nur halbwegs mitdenkender Netzwerker machen. Den Grund dafür muss man wohl nicht weiter erklären.
Nehmen wir also mal an das das IP Adressdesign so gemacht wurde das das Routing auf einem lokalen vom Kunden administrieten Gerät passiert wie einem VLAN L3 Switch, dem Lancom oder auch nur der FB.
Dann ist es ja ein Leichtes dort entsprechende Routen in sein VPN Netzwerk zu implementieren und den Management Server damit sauber zu integrieren.
@ aqui
Und genau das ist aber der Fall.
Steht direkt zu Beginn seines Eröffnungsposts:
Das ist vermutlich das Problem, wenn du ein Einzelhändler bist und einem übergerondetem Dachverband angehörst; manchmal vermutlich sogar als Franchiser am Markt aktiv bist...
Und genau das ist aber der Fall.
Steht direkt zu Beginn seines Eröffnungsposts:
ich habe ein Aufgabenstellung bei einem Firmenkunden, bei der ich leider nicht wirklich weiterkomme. Das Firmennetzwerk ist Teil einer größeren Händlerstruktur welche hierarchisch durchstrukturiert ist. Ich skizziere mal mit geänderten Daten:
Netzwerk:
10.53.150.0 /24
255.255.255.0
Gateway: 10.53.150.1
PDC/DNS/DHCP: 10.53.150.2
Als Gateway fungiert ein Cisco Router über MPLS von der Firmenzentrale. An dem bestehen leider keine Konfigurationsmöglichkeiten, der ist dicht. Die verschiedenen Server sind alle virtuell auf Esxi mit festen IP inhouse. In der Firma existiert ein Dömänennetzwerk und zwei Arbeitsgruppennetzwerke die vorgegeben sind. Alle Server, NAS, USV etc mit fester IP, alle Clients laufen über DHCP.
Der Internetzugang über den PDC und das Gateway ermöglicht primär Zugang auf das Händler Intranet und die dort bereitgestellten Funktionen und Applikationen im übergeordneten Datencenter. Will man in das normale Internet hinaus muss man sich erst an einem weiteren übergeordneten Proxy anmelden und durch Websense Webfilter hindurch.
Leider werden nicht alle Dienste und Ports durchgeleitet. So geht etwa kein Zugriff auf Dyndns Dienste und auch Windowsupdates werden geblockt. Diverses andere auch. An und für sich ein stimmiges System und weltweit funktionierend aber eben unflexibel. Was die Firmenzentrale nicht haben will, das ermöglicht Sie eben nicht. Man muss sich eigene Lösungen bauen. Verboten ist dies nicht. Sicher sollte es natürlich sein.
Netzwerk:
10.53.150.0 /24
255.255.255.0
Gateway: 10.53.150.1
PDC/DNS/DHCP: 10.53.150.2
Als Gateway fungiert ein Cisco Router über MPLS von der Firmenzentrale. An dem bestehen leider keine Konfigurationsmöglichkeiten, der ist dicht. Die verschiedenen Server sind alle virtuell auf Esxi mit festen IP inhouse. In der Firma existiert ein Dömänennetzwerk und zwei Arbeitsgruppennetzwerke die vorgegeben sind. Alle Server, NAS, USV etc mit fester IP, alle Clients laufen über DHCP.
Der Internetzugang über den PDC und das Gateway ermöglicht primär Zugang auf das Händler Intranet und die dort bereitgestellten Funktionen und Applikationen im übergeordneten Datencenter. Will man in das normale Internet hinaus muss man sich erst an einem weiteren übergeordneten Proxy anmelden und durch Websense Webfilter hindurch.
Leider werden nicht alle Dienste und Ports durchgeleitet. So geht etwa kein Zugriff auf Dyndns Dienste und auch Windowsupdates werden geblockt. Diverses andere auch. An und für sich ein stimmiges System und weltweit funktionierend aber eben unflexibel. Was die Firmenzentrale nicht haben will, das ermöglicht Sie eben nicht. Man muss sich eigene Lösungen bauen. Verboten ist dies nicht. Sicher sollte es natürlich sein.
Das ist vermutlich das Problem, wenn du ein Einzelhändler bist und einem übergerondetem Dachverband angehörst; manchmal vermutlich sogar als Franchiser am Markt aktiv bist...
Und genau das ist aber der Fall.
Dann hast du aber erstmal ein ganz anderes Problem, nämlich Dummheit oder besser die fachliche Inkompetenz beim Kunden bzw. in dessen Netz zu eliminieren.Aber auch wenn das nun dummerweise so falsch gemacht wurde ist das Problem ganz schnell und unkompliziert zu fixen wenn der Kunde DHCP am werkeln hat im Netz.
Dort legt man dann im DHCP Server einfach mal nach Feierabend das Default Gateway statt auf den MPLS Router dann auf den Lancom Router oder noch besser auf ein L3 Switch mit VRRP und gut iss.
Der Lancom Router hat natürlich VORHER eine Default Route auf den MPLS Router bekommen wenn er diese nicht so oder so schon hatte.
So hat man das Problem in 5 Minuten gefixt, keiner merkt was in den Anwendungen und der TO kann am Lancom ganz bequem seine Route in sein VPN Management Netz konfigurieren.
In der Firma existiert ein Dömänennetzwerk
Aha...also ein Kunde aus Sachsen 
Zitat von @aqui:
Stimme ich dir bedingt zu:Und genau das ist aber der Fall.
Dann hast du aber erstmal ein ganz anderes Problem, nämlich Dummheit oder besser die fachliche Inkompetenz beim Kunden bzw. in dessen Netz zu eliminieren.Wenn ich einem Verband angehören will und daher die Vorgaben im Bereich der Netzanbindung ohne Einschränkungen zustimmen muss, bleibt mir ja nichts übrig. Ist dann "Friss oder stirb". Und wenn die unternehmerischen Vorteile diesem nachteiligen Aspekt überwiegen, wäre das zumindest nachvollziehbar...
Aber auch wenn das nun dummerweise so falsch gemacht wurde ist das Problem ganz schnell und unkompliziert zu fixen wenn der Kunde DHCP am werkeln hat im Netz.
Dort legt man dann im DHCP Server einfach mal nach Feierabend das Default Gateway statt auf den MPLS Router dann auf den Lancom Router oder noch besser auf ein L3 Switch mit VRRP und gut iss.
Der Lancom Router hat natürlich VORHER eine Default Route auf den MPLS Router bekommen wenn er diese nicht so oder so schon hatte.
So hat man das Problem in 5 Minuten gefixt, keiner merkt was in den Anwendungen und der TO kann am Lancom ganz bequem seine Route in sein VPN Management Netz konfigurieren.
Dort legt man dann im DHCP Server einfach mal nach Feierabend das Default Gateway statt auf den MPLS Router dann auf den Lancom Router oder noch besser auf ein L3 Switch mit VRRP und gut iss.
Der Lancom Router hat natürlich VORHER eine Default Route auf den MPLS Router bekommen wenn er diese nicht so oder so schon hatte.
So hat man das Problem in 5 Minuten gefixt, keiner merkt was in den Anwendungen und der TO kann am Lancom ganz bequem seine Route in sein VPN Management Netz konfigurieren.
In der Firma existiert ein Dömänennetzwerk
Aha...also ein Kunde aus Sachsen Das war ja auch mein Ansatz:
N' Abend,
Also wenn du Zugang zum DHCP-Server hast, kannst du doch z.B. das GW des Lancom eintragen (anstelle des Ciscos) und verteilen lassen.
Auf dem Lancom setzt du dann die Routen.
Alles was dein eigenes Netz betrifft, geht über den Lancom (und somit den VPN) in dein LAN, alles andere verweist auf das Cisco-Gateway, welches für MPLS genutzt wird.
Gruß
em-pie
Also wenn du Zugang zum DHCP-Server hast, kannst du doch z.B. das GW des Lancom eintragen (anstelle des Ciscos) und verteilen lassen.
Auf dem Lancom setzt du dann die Routen.
Alles was dein eigenes Netz betrifft, geht über den Lancom (und somit den VPN) in dein LAN, alles andere verweist auf das Cisco-Gateway, welches für MPLS genutzt wird.
Gruß
em-pie
Seine Antwort:
Hallo
Das wäre möglich, aber sehr riskant für mich. Würde bekannt, daß ich wichtige Firmenkommunikation DURCH mein eigenes Gateway leite wäre der Teufel los. Ein Defekt am Lancom würde alles lahmlegen, auch das ist nicht akzeptabel. Es sind auch Hardwaregeräte anderer Anbieter in der Firma vorhanden, welche zwingend die 1 als Gateway verwenden.
Das wäre möglich, aber sehr riskant für mich. Würde bekannt, daß ich wichtige Firmenkommunikation DURCH mein eigenes Gateway leite wäre der Teufel los. Ein Defekt am Lancom würde alles lahmlegen, auch das ist nicht akzeptabel. Es sind auch Hardwaregeräte anderer Anbieter in der Firma vorhanden, welche zwingend die 1 als Gateway verwenden.
Wenn ich einem Verband angehören will und daher die Vorgaben im Bereich der Netzanbindung ohne Einschränkungen zustimmen muss, bleibt mir ja nichts übrig. Ist dann "Friss oder stirb".
Sorry, aber dieser Punkt ist in Bezug auf das Default Gateway Blödsinn !Niemand kann mich doch zwingen ob Verband oder wer auch immer das ich das Default Gateway meines eigenen Netzwerkes zwingend auf diesen von mir nicht administrierbaren Fremdrouter legen MUSS !
Allein aus Sicherheit schon ein absolutes Unding.
Meine eigene Infrastruktur, die ja wohl noch meiner Hoheit unterliegt, da ich dafür bezahle, richte ich auch nach meinen Vorgaben ein und dazu gehört ja wohl ganz klar das ich sowas Wesentliches wie das Default Gateway meines lokalen Netzwerkes eben NICHT auf ein Fremdgerät lege. Ganz besonders wenn mein Netzwerk auch noch sinnvoll in VLANs segmentiert ist !
Seine Antwort...:
Die ist kindisch und zeigt von wenig Fachkompetenz. Von Managementkompetenz und Lösungswillen mal gar nicht zu reden...Sein Gateway würde ja ein ICMP Redirect schicken so das dann alle Endgeräte so oder so dann alles wieder direkt und eben NICHT über sein Gateway schicken.
Aber bei solchen inkompetenten Waldheinis erübrigt sich dann wohl auch jeglicher Erklärungsversuch auf sachlicher Basis...egal. Das ist Wasch' mich aber mach mich nicht nass.
Unter solchen Bedingungen ist eine technisch sinnvolle Kooperation ja gar nicht möglich.
Will man es dennoch auslagern bleibt in der Tat nichts weiteres als an allen Endgeräten einzeln diese Management Route statisch Gerät für Gerät zu definieren.
IT technische Steinzeit durch Inkompetenz. Da fehlen einem eigentlich die Worte....
Zitat von @aqui:
Niemand kann mich doch zwingen ob Verband oder wer auch immer das ich das Default Gateway meines eigenen Netzwerkes zwingend auf diesen von mir nicht administrierbaren Fremdrouter legen MUSS !
Allein aus Sicherheit schon ein absolutes Unding.
Meine eigene Infrastruktur, die ja wohl noch meiner Hoheit unterliegt, da ich dafür bezahle, richte ich auch nach meinen Vorgaben ein und dazu gehört ja wohl ganz klar das ich sowas Wesentliches wie das Default Gateway meines lokalen Netzwerkes eben NICHT auf ein Fremdgerät lege. Ganz besonders wenn mein Netzwerk auch noch sinnvoll in VLANs segmentiert ist !
Wenn ich einem Verband angehören will und daher die Vorgaben im Bereich der Netzanbindung ohne Einschränkungen zustimmen muss, bleibt mir ja nichts übrig. Ist dann "Friss oder stirb".
Sorry, aber dieser Punkt ist in Bezug auf das Default Gateway Blödsinn !Niemand kann mich doch zwingen ob Verband oder wer auch immer das ich das Default Gateway meines eigenen Netzwerkes zwingend auf diesen von mir nicht administrierbaren Fremdrouter legen MUSS !
Allein aus Sicherheit schon ein absolutes Unding.
Meine eigene Infrastruktur, die ja wohl noch meiner Hoheit unterliegt, da ich dafür bezahle, richte ich auch nach meinen Vorgaben ein und dazu gehört ja wohl ganz klar das ich sowas Wesentliches wie das Default Gateway meines lokalen Netzwerkes eben NICHT auf ein Fremdgerät lege. Ganz besonders wenn mein Netzwerk auch noch sinnvoll in VLANs segmentiert ist !
Und das ist der Punkt, wo ich dir uneingeschränkt zustimme.. Ich würde zwar den "fremden" Router annehmen, aber in ein Transfer-VLAN stecken und den CoreSwitch oder meine eigene FW das Routing überlassen. Aber nungut... denke, dazu kennen wir zuwenig die Unternehmen um hier die BEweggründe für diese Details zu erörtern...
Es könnte aber auch sein, dass die Infrastruktur vom Verband/ Mutterkonzern stammt und die Server selbst durch den TO betreut wird. Aber das wäre ein Fall der Kristallkugel
Seine Antwort...:
Die ist kindisch und zeigt von wenig Fachkompetenz. Von Managementkompetenz und Lösungswillen mal gar nicht zu reden...Sein Gateway würde ja ein ICMP Redirect schicken so das dann alle Endgeräte so oder so dann alles wieder direkt und eben NICHT über sein Gateway schicken.
Will man es dennoch auslagern bleibt in der Tat nichts weiteres als an allen Endgeräten einzeln diese Management Route statisch Gerät für Gerät zu definieren.
IT technische Steinzeit durch Inkompetenz. Da fehlen einem eigentlich die Worte....
Jopp...Will man es dennoch auslagern bleibt in der Tat nichts weiteres als an allen Endgeräten einzeln diese Management Route statisch Gerät für Gerät zu definieren.
IT technische Steinzeit durch Inkompetenz. Da fehlen einem eigentlich die Worte....
Denke, sollten zurück zum eigentlichen Problem kommen:
wenn du, lieber TO an den Gateways nichts ändern darfst, wird es sehr aufwendig....
Ich würde zwar den "fremden" Router annehmen, aber in ein Transfer-VLAN stecken und den CoreSwitch oder meine eigene FW das Routing überlassen.
Bingo ! Genau richtig in so einem Umfeld.Das wäre die Königsklasse in Bezug auf eine sinnvolle Lösung !
Kurzer Exkurs für eine Verständnisfrage meinerseits in diesem Zusammenhang (und vermutlich auch für den TO von Interesse):
Angenommen ich bin der Verband und einer meiner Mitglieder, bei dem ich einen Router platziert habe, setzt exakt dies (also ein Transfer-VLAN) ein. Hinter meinem Router (also auf Seiten des Mitglieds) hängt ein anderes L3-Device (L3-Switch, Router, Firewall, ...) und alle Clients und Server sind aufgrund der etablierten VLANs in einem anderen IP-Kreis, z.B. 172.17.1.0/24 (Server) und 172.17.2.0/24 (Clients). Will nun ein Client in mein Netz (zwecks Intranetzugriff), welche IPs melden sich dann bei mir? Nach meinem Verständnis (welches nicht richtig sein muss) würde das eine IP 172.17.2.xxx sein, richtig?
Wenn ich an meinem MPLS-Router das LAN mit dem Netz 10.10.10.0/24 zuweise und erwarte, dass auch nur aus diesem Netz IPs mit mir spreche (und somit nichts anderes zulasse), auch dann läuft doch das vorhaben des Verbandmitglieds (hier das Netz mit den VLANS) vor die Wand, richtig?
Außer, ich verwenden einen Router/ Firewall mit NAT, was allerdings bedeutet, dass u.U. ich (als Verband) nicht mehr in das Netzwerk meines Mitglieds komme. Richtig
Angenommen ich bin der Verband und einer meiner Mitglieder, bei dem ich einen Router platziert habe, setzt exakt dies (also ein Transfer-VLAN) ein. Hinter meinem Router (also auf Seiten des Mitglieds) hängt ein anderes L3-Device (L3-Switch, Router, Firewall, ...) und alle Clients und Server sind aufgrund der etablierten VLANs in einem anderen IP-Kreis, z.B. 172.17.1.0/24 (Server) und 172.17.2.0/24 (Clients). Will nun ein Client in mein Netz (zwecks Intranetzugriff), welche IPs melden sich dann bei mir? Nach meinem Verständnis (welches nicht richtig sein muss) würde das eine IP 172.17.2.xxx sein, richtig?
Wenn ich an meinem MPLS-Router das LAN mit dem Netz 10.10.10.0/24 zuweise und erwarte, dass auch nur aus diesem Netz IPs mit mir spreche (und somit nichts anderes zulasse), auch dann läuft doch das vorhaben des Verbandmitglieds (hier das Netz mit den VLANS) vor die Wand, richtig?
Außer, ich verwenden einen Router/ Firewall mit NAT, was allerdings bedeutet, dass u.U. ich (als Verband) nicht mehr in das Netzwerk meines Mitglieds komme. Richtig
welche IPs melden sich dann bei mir?
Du meinst einen Client der aus deinem eigenen Client Segment kommt ?Ja, richtig, der hat dann logischerweise eine 172.17.2.x Absender IP.
Wenn das ein Client von einem anderen Mitglied ist der über das WAN kommt ist das eine Absender IP aus dessen Netz je nachdem was da für IP netze konfiguriert sind.
läuft doch das vorhaben des Verbandmitglieds (hier das Netz mit den VLANS) vor die Wand, richtig?
Per se ja, wenn es durch den MPLS Backbone Betreiber tatsächlich so restriktiv gehandhabt wird.Das wird es aber nicht, da das Business Lösungen sind und der Provider hier sich in der lokalen IP Adressierung voll nach dem Kunden und dessen Struktur richten muss und auch tut.
So gut wie alle Provider mit MPLS Dienstleistungen passen das also an.
Wenn nicht dann gibt es aber einen Trick.
Du aktivierst einfach NAT (IP Adress Translation) am Transfer VLAN IP Interface und übersetzt per NAT alle IP Adressen des lokalen Netzes die das Verbandsnetz nutzen auf die 10.10.10.er Adressen.
Damit gaukelst du dann per NAT dieses netzwerk vor und die Welt ist wieder in Ordnung.
In der Regel ist das bei MPLS Business Netzen aber nicht nötig.
was allerdings bedeutet, dass u.U. ich (als Verband) nicht mehr in das Netzwerk meines Mitglieds komme. Richtig
Richtig. Ist ja aber auch gewollt.Wer will denn bitte sehr das Fremdnutzer ohne jegliche Schranken in meinem Unternehmensnetz sich bewegen können.
Für normale Unternehmen ist das der SuperGAU.
Sollte es dennoch nötig sein kann man immer Ausnahmen für einzelne Hosts oder Breiche im NAT schaffen.
Alles klar. Danke dir!
Dann war ich gedanklich ja auf dem richtigen Weg
Dann war ich gedanklich ja auf dem richtigen Weg
Hallo.
genauso ist es. Von "Dummheit" des Kunden möchte ich nicht sprechen. Aber vom Dachverband gibt es Knebelverträge die zu erfüllen sind. Wenn z.B. Ein BMW Händler an eine solche Infrastruktur angebunden wird heißt es Friss oder Stirb. Man ist Teil einer mehrstufigen Hierarchie bis hoch zur Konzernspitze. Entweder man spielt mit oder man lässt es. Das System an sich funktioniert und ist eben wasserdicht. Und man muss es akzeptieren. Man bekommt die Netzsegmente und IP Ranges freigeschaltet und muss sich daran halten. Sonst geht kein SAP, keine Bestellung, keine Gewährleistung, keine Steuergeräteupdates, keine Wegfahrsperrenfreischaltung und all das Drumherum. Es ist durchstrukturiertes Teamwork auf weltweiter Basis. Man ist eben keine freie Werkstatt sondern Vertragshändler oder gar Werksniederlassung.
Dennoch sind die Firmen autonom und die Chefs haben Spezialwünsche. Fernarbeitsplätze zuhause, einen eigenen Mailserver, Videoüberwachung. Alarmanlagenanbindung, IP Telefonie, Kunden Hotspots etc.
Die firmeneigene IT von oben ist da oft recht hölzern. Die haben Scheuklappen auf. Dort wird z.B. eine einzige gehostete Maiserverlösung angeboten und das muss reichen. Keine Groupwarefunktionen und all den Merhrwert eines Exchanges. Keine Anbindung von Mobilgeräten über das normale Internet möglich. Punkt. Und da kommen dann Fremdanbieter ins Spiel.
Als IT Fremdleister muss man da mit etwas Feingefühl herangehen und ich kann zu 90 Prozent alle Wünsche erfüllen. Kompatibel und flexibel muss ich als Fremdanbieter sein. Wenn ich etwas nicht kann, hole ich Spezialfirmen hinzu, etwa für IP Telefonie und Funknetze die mehrere Gebäude fließend überdecken. Alleine so eine Administration ist ja schon ein Halbtagsjob wenn da 4 Panasonic Anlagen im Verbund betrieben und administriert werden.
Nur bei Erfahrung mit dem Routing hapert es etwas bei mir und ich würde es gerne selbst machen, weil es um meinen eigenen Server geht. Mir wird klar, daß ich hier noch viel lernen muss und mir Basiswissen in diesem Bereich fehlt. Ich danke euch allen jedenfalls ganz herzlich für jeden Kommentar und Denkanstoß. Ich lerne aus jedem Kommentar enorm dazu.
genauso ist es. Von "Dummheit" des Kunden möchte ich nicht sprechen. Aber vom Dachverband gibt es Knebelverträge die zu erfüllen sind. Wenn z.B. Ein BMW Händler an eine solche Infrastruktur angebunden wird heißt es Friss oder Stirb. Man ist Teil einer mehrstufigen Hierarchie bis hoch zur Konzernspitze. Entweder man spielt mit oder man lässt es. Das System an sich funktioniert und ist eben wasserdicht. Und man muss es akzeptieren. Man bekommt die Netzsegmente und IP Ranges freigeschaltet und muss sich daran halten. Sonst geht kein SAP, keine Bestellung, keine Gewährleistung, keine Steuergeräteupdates, keine Wegfahrsperrenfreischaltung und all das Drumherum. Es ist durchstrukturiertes Teamwork auf weltweiter Basis. Man ist eben keine freie Werkstatt sondern Vertragshändler oder gar Werksniederlassung.
Dennoch sind die Firmen autonom und die Chefs haben Spezialwünsche. Fernarbeitsplätze zuhause, einen eigenen Mailserver, Videoüberwachung. Alarmanlagenanbindung, IP Telefonie, Kunden Hotspots etc.
Die firmeneigene IT von oben ist da oft recht hölzern. Die haben Scheuklappen auf. Dort wird z.B. eine einzige gehostete Maiserverlösung angeboten und das muss reichen. Keine Groupwarefunktionen und all den Merhrwert eines Exchanges. Keine Anbindung von Mobilgeräten über das normale Internet möglich. Punkt. Und da kommen dann Fremdanbieter ins Spiel.
Als IT Fremdleister muss man da mit etwas Feingefühl herangehen und ich kann zu 90 Prozent alle Wünsche erfüllen. Kompatibel und flexibel muss ich als Fremdanbieter sein. Wenn ich etwas nicht kann, hole ich Spezialfirmen hinzu, etwa für IP Telefonie und Funknetze die mehrere Gebäude fließend überdecken. Alleine so eine Administration ist ja schon ein Halbtagsjob wenn da 4 Panasonic Anlagen im Verbund betrieben und administriert werden.
Nur bei Erfahrung mit dem Routing hapert es etwas bei mir und ich würde es gerne selbst machen, weil es um meinen eigenen Server geht. Mir wird klar, daß ich hier noch viel lernen muss und mir Basiswissen in diesem Bereich fehlt. Ich danke euch allen jedenfalls ganz herzlich für jeden Kommentar und Denkanstoß. Ich lerne aus jedem Kommentar enorm dazu.
Noch ein kleiner Nachtrag.
Ich kann verstehen wenn viele hier heißblütig kommentieren über Hoheitsrechte oder über meine mangelnde Kompetenz. Ist ja alles legitim.
Aber nur ein weiterer kleiner Exkurs in solche Händlerstrukturen. Ich nenne hier nur BMW als Beispiel weil ich dort eben auch aktiv bin. Konkret geht es aber um eine andere Händlerstruktur die ähnlich aufgebaut ist.
So gibt die Firmenzentrale z. B. vor welche Server der Kunde nutzen darf. Entweder HP oder Fujitsu. Fertig. Kaufen muss er sie selbst. Sogar die Raid Struktur ist vorgegeben. Raid 5 ohne Hotspare. Will der Kunde mit Hotspare wird das Ding einfach nicht zertifiziert von oben und man wird nicht freigeschaltet. Als Backuplösung darf nur Acronis hergenommen werden. Will man mit Veeam arbeiten hat man verloren. Ein Irrwitz, aber es ist eben so.
Man bekommt z.B. von T-Systems zwei virtuelle Maschinen auf dem eigenen VMware Cluster installiert, zu denen man keinen Zugang bekommt! Dort laufen wichtige RSA Verschlüsselungen ab. Monitoring der Maschinen geht direkt an die Firmenzentrale. Jeder Versuch sich dort einzuloggen gibt richtig Ärger! Überwachung und Kontrolle total. Aber es geht um Patente, Datenschutz, Sicherheitssysteme.
Jeder Apple-Jünger der ein Iphone nutzt macht das gleiche im Kleinen. Entweder man akzeptiert die Nutzungsbedingungen oder das Teil wird niemals telefonieren.
Ich kann verstehen wenn viele hier heißblütig kommentieren über Hoheitsrechte oder über meine mangelnde Kompetenz. Ist ja alles legitim.
Aber nur ein weiterer kleiner Exkurs in solche Händlerstrukturen. Ich nenne hier nur BMW als Beispiel weil ich dort eben auch aktiv bin. Konkret geht es aber um eine andere Händlerstruktur die ähnlich aufgebaut ist.
So gibt die Firmenzentrale z. B. vor welche Server der Kunde nutzen darf. Entweder HP oder Fujitsu. Fertig. Kaufen muss er sie selbst. Sogar die Raid Struktur ist vorgegeben. Raid 5 ohne Hotspare. Will der Kunde mit Hotspare wird das Ding einfach nicht zertifiziert von oben und man wird nicht freigeschaltet. Als Backuplösung darf nur Acronis hergenommen werden. Will man mit Veeam arbeiten hat man verloren. Ein Irrwitz, aber es ist eben so.
Man bekommt z.B. von T-Systems zwei virtuelle Maschinen auf dem eigenen VMware Cluster installiert, zu denen man keinen Zugang bekommt! Dort laufen wichtige RSA Verschlüsselungen ab. Monitoring der Maschinen geht direkt an die Firmenzentrale. Jeder Versuch sich dort einzuloggen gibt richtig Ärger! Überwachung und Kontrolle total. Aber es geht um Patente, Datenschutz, Sicherheitssysteme.
Jeder Apple-Jünger der ein Iphone nutzt macht das gleiche im Kleinen. Entweder man akzeptiert die Nutzungsbedingungen oder das Teil wird niemals telefonieren.
Entweder man spielt mit oder man lässt es.
Na ja das klingt aber alles ein bischen nach Fatalismus der vermutlich aus dem Unwissen und etwas begrenzten Netzwerk Horizont resultiert.Es nimmt einem ja keiner die Freiheit sein eigenes Client Netzwerk an dieses starre vorgegeben Netzwerk mit einem kleinen 35 Euro Mikrotik Router anzukopplent.
So erhalte ich mir die Freiheit in meinem Netz selber nach meinen Vorgaben zu schalten und zu walten und über den kleinen Router gehe ich dann in die Knebelwelt.
Das hat den Vorteil das man sich vollkommen frei macht von diesen Zwängen dieser Welt.
Mir wird klar, daß ich hier noch viel lernen muss und mir Basiswissen in diesem Bereich fehlt.
Das mekrt man leider aber wenn wir mit diesem Forum dazu beitragen können das sich das ändert und du dich nicht allen Zwängen kampflos hingeben musst ist das ja schon mal ein erster Schritt in die richtige Richting, oder ??Jeder Apple-Jünger der ein Iphone nutzt macht das gleiche im Kleinen.
Jeder Androide und Winblows Jünger übrigens auch. Bei Android ist es noch umso schlimmer durch die Bedrohung eines halboffenen Systems mit all den Nachteilen.Auch deine Schlussfolgerung ist falsch. Mit Jailbreak und Cyanogenmod gibt es ja Optionen auch ohne solche Zwänge frei zu sein. Identisch ist das oben bei BMW und allen anderen. Wenn man pfiffig ist erschafft man sich immer seine Freiheiten. So ist das immer im Leben !
Hallo
Das Problem wurde mittlerweise wie folgt gelöst bzw. umgangen: Lan/Lan VPN steht, IP Zugriffslisten wurden auf die wirklich notwendigen Server bei mir begrenzt. Firewall aktiv, spezielle Ports nur für gewisse Dienste und Computer.
Als kleinsten gemeinsamen Nenner im Kundennetzwerk habe ich zumindest die Hoheit über das WSUS. Also ein Installationspaket gebastelt welche die notwendigen statischen Routen beinhaltet. Im Wsus hängen nämlich alle Computer der Domäne und der Arbeitsgruppen. So finden alle Computer zumindest meine Zielserver.
Ganz ohne Standbein im Kundennetz geht es noch nicht, aber das ist im Endeffekt nur noch ein kleiner MINI ITX von welchem aus die Fernwartung und das übrige Software Deployment läuft. SMTP Relay und Syslog ebenfalls.
Mit diesem Setup kann ich alle vorhandenen Computer so umkonfigurieren wie ich es möchte und Dienste wie z.B. Antivirus Enterprise Lösungen zentral bei mir über VPN überwachen.
Nächstes Ziel ist es den kleinen ITX beim Kunden von einem Windows zu einem stabilen Linux System zu portieren.
Vielen Dank von meiner Seite an die Community. Ich lerne fleissig weiter.
Frohes Fest
Das Problem wurde mittlerweise wie folgt gelöst bzw. umgangen: Lan/Lan VPN steht, IP Zugriffslisten wurden auf die wirklich notwendigen Server bei mir begrenzt. Firewall aktiv, spezielle Ports nur für gewisse Dienste und Computer.
Als kleinsten gemeinsamen Nenner im Kundennetzwerk habe ich zumindest die Hoheit über das WSUS. Also ein Installationspaket gebastelt welche die notwendigen statischen Routen beinhaltet. Im Wsus hängen nämlich alle Computer der Domäne und der Arbeitsgruppen.
So finden alle Computer zumindest meine Zielserver.Ganz ohne Standbein im Kundennetz geht es noch nicht, aber das ist im Endeffekt nur noch ein kleiner MINI ITX von welchem aus die Fernwartung und das übrige Software Deployment läuft. SMTP Relay und Syslog ebenfalls.
Mit diesem Setup kann ich alle vorhandenen Computer so umkonfigurieren wie ich es möchte und Dienste wie z.B. Antivirus Enterprise Lösungen zentral bei mir über VPN überwachen.
Nächstes Ziel ist es den kleinen ITX beim Kunden von einem Windows zu einem stabilen Linux System zu portieren.
Vielen Dank von meiner Seite an die Community. Ich lerne fleissig weiter.
Frohes Fest
Ganz ohne Standbein im Kundennetz geht es noch nicht,
Wäre mit entsprechenden statischen Hostrouten aber auch kein Problem 
Nächstes Ziel ist es den kleinen ITX beim Kunden von einem Windows zu einem stabilen Linux System zu portieren.
Ein sehr löblicher Schritt...!
