11
Entwurf für Web-Server und Netzwerkdesign
Hallo an alle.
Ich fange am besten erst einmal mit den Informationen zur Situation an
Wir haben eine Web basierte Software entwickelt.
Wird die Software von einem Kunden erworben, richten wir dort einen Server ein.
Meistens wird dies ein HP DL380 G10 mit ausreichend Ressourcen.
Auf dem Server wird HyperV installiert.
Es wird eine VM angelegt und auf dieser Windows Server installiert.
Es werden der IIS und eine MySQL Datenbank installiert und eingerichtet.
Die Applikation wird über die interne IP des Servers, oder über eine URL aufgerufen.
Die Applikation besteht aus der eigentlichen Benutzer-Oberfläche, einer Datenbank und einer API.
Oberfläche, Datenbank und API sind über verschiedene Ports erreichbar. Klar soweit!
Die ganze Software wurde auf .Net Core umgestellt. Relevant? Ich denke nicht.
Manche Kunden haben eine statische Public IP, andere nur eine dynamische, wieder andere haben das Pech, und haben nur eine Carrier Grade NAT IP. Was das bedeutet muss ich ja nicht näher erläutern.
Es gibt folgende URL's:
app.kunde.meinsoftware.de
api.kunde.meinesoftware.de
Diese Domänen liegen bei unseren Developern.
Diese haben irgendwo einen vServer mit einem ReverseProxy am laufen, der alle Anfragen an die Zielserver leitet.
Zum Problem:
Auf manchen Kunden-Servern ist zusätzlich noch ein Ngninx installiert, der an andere Ports weiterleitet.
Dann gibt es scheinbar noch einen SSH Tunnel der Ports umleitet. Durchblicken tu ich da mal überhaupt nicht mehr.
Rufe ich die Applikation über die URL: app.kunde.meinesoftware.de auf, und navigiere durch das Programm,
ändert sich die URL zu: core1.meinesoftware.de und andere.
Das erschwert es mir unheimlich ein DNS Forwarding für die internen Clients einzurichten.
Ich habe einen Design erstellt, wie das ganze Setup nach meinem Verständnis nach auszusehen hat.
Dieses Entwurf möchte ich euch jetzt zeigen, um eure Meinungen dazu zu hören.
Entwurf:
Mein Entwurf
Ich möchte mich so gut wie es nur geht, dabei an best practice halten.
Ich fange am besten erst einmal mit den Informationen zur Situation an
Wir haben eine Web basierte Software entwickelt.
Wird die Software von einem Kunden erworben, richten wir dort einen Server ein.
Meistens wird dies ein HP DL380 G10 mit ausreichend Ressourcen.
Auf dem Server wird HyperV installiert.
Es wird eine VM angelegt und auf dieser Windows Server installiert.
Es werden der IIS und eine MySQL Datenbank installiert und eingerichtet.
Die Applikation wird über die interne IP des Servers, oder über eine URL aufgerufen.
Die Applikation besteht aus der eigentlichen Benutzer-Oberfläche, einer Datenbank und einer API.
Oberfläche, Datenbank und API sind über verschiedene Ports erreichbar. Klar soweit!
Die ganze Software wurde auf .Net Core umgestellt. Relevant? Ich denke nicht.
Manche Kunden haben eine statische Public IP, andere nur eine dynamische, wieder andere haben das Pech, und haben nur eine Carrier Grade NAT IP. Was das bedeutet muss ich ja nicht näher erläutern.
Es gibt folgende URL's:
app.kunde.meinsoftware.de
api.kunde.meinesoftware.de
Diese Domänen liegen bei unseren Developern.
Diese haben irgendwo einen vServer mit einem ReverseProxy am laufen, der alle Anfragen an die Zielserver leitet.
Zum Problem:
Auf manchen Kunden-Servern ist zusätzlich noch ein Ngninx installiert, der an andere Ports weiterleitet.
Dann gibt es scheinbar noch einen SSH Tunnel der Ports umleitet. Durchblicken tu ich da mal überhaupt nicht mehr.
Rufe ich die Applikation über die URL: app.kunde.meinesoftware.de auf, und navigiere durch das Programm,
ändert sich die URL zu: core1.meinesoftware.de und andere.
Das erschwert es mir unheimlich ein DNS Forwarding für die internen Clients einzurichten.
Ich habe einen Design erstellt, wie das ganze Setup nach meinem Verständnis nach auszusehen hat.
Dieses Entwurf möchte ich euch jetzt zeigen, um eure Meinungen dazu zu hören.
Entwurf:
Mein Entwurf
Ich möchte mich so gut wie es nur geht, dabei an best practice halten.
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: 92405677220
Url: https://administrator.de/contentid/92405677220
Printed on: April 27, 2024 at 23:04 o'clock
11 Comments
Latest comment
Moin,
das klingt nach ziemlich Gemurkse mit Portweiterleitungen und Proxys.
Wenn Du keinen Plan hast wie das funktioniert wer dann?
Am besten ist es wenn man auf die Kunden IT gar nicht angewiesen ist.
Ausgehende VPN/SSH/Irgendwas Verbindung die von deren IT erlaubt ist.
Fertig.
Stefan
PS: Dein Link geht nicht
das klingt nach ziemlich Gemurkse mit Portweiterleitungen und Proxys.
Wenn Du keinen Plan hast wie das funktioniert wer dann?
Am besten ist es wenn man auf die Kunden IT gar nicht angewiesen ist.
Ausgehende VPN/SSH/Irgendwas Verbindung die von deren IT erlaubt ist.
Fertig.
Stefan
PS: Dein Link geht nicht
Das mit den Portumleitungen usw. ist nicht auf meinen Mist gewachsen.
Ich hab mich der Problematik angenommen und möchte der Geschäftsleitung
aufzeigen, wie es richtig umzusetzen ist.
Auf die IT vom Kunden sind wir leider angewiesen. Ein Rechenzentrum besitzen wir nicht, naja, noch nicht.
Hier noch mal ein anderer Link, der alte war abgelaufen.
Mein Entwurf
Ich hab mich der Problematik angenommen und möchte der Geschäftsleitung
aufzeigen, wie es richtig umzusetzen ist.
Auf die IT vom Kunden sind wir leider angewiesen. Ein Rechenzentrum besitzen wir nicht, naja, noch nicht.
Hier noch mal ein anderer Link, der alte war abgelaufen.
Mein Entwurf
Moin,
ohne auf deinen dubiosen Link geklickt zu haben... hast du dich schon mal mit Cloudflare auseinander gesetzt?
lg,
Slainte
ohne auf deinen dubiosen Link geklickt zu haben... hast du dich schon mal mit Cloudflare auseinander gesetzt?
lg,
Slainte
Das sagen sie All. Inklusive mir 
Alle 3 Versionen von Dir kann man machen.
Wobei ich die 1. und 3. vorziehen würde, denn in Deiner Ansicht fehlt eine WAF.
Jeder Form von Webanwendung wird früher oder später, eher früher, angegriffe und mit Brute-Force und Scannern belegt. Bei der 2. Variante bräuchte man bei jedem Kunden eine WAF.
Die Variante mit dem ausgehenden VPN wäre meine Empfehlung.
Aber auch die Variante mit dem Proxy funktioniert solange die Strecken per SSL gesichert sind.
Portweiterleitungen sind technisch simpel und Fehler lassen sich einfacher finden als VPN-Fehler (KISS).
Wir haben selber eine WAF für Exchange-Server entwickelt weil die meisten UTM Firewalls sehr wenig in Petto haben um interne Server vor Externe Webzugriffe zu schützen.
Stefan
Ich hab mich der Problematik angenommen und möchte der Geschäftsleitung
aufzeigen, wie es richtig umzusetzen ist.
Lobenswertaufzeigen, wie es richtig umzusetzen ist.
Auf die IT vom Kunden sind wir leider angewiesen.
Das ist ja auch kein Problem.Ein Rechenzentrum besitzen wir nicht, naja, noch nicht.
Das tun die meisten anderen Firmen die es behaupten auch nicht.Alle 3 Versionen von Dir kann man machen.
Wobei ich die 1. und 3. vorziehen würde, denn in Deiner Ansicht fehlt eine WAF.
Jeder Form von Webanwendung wird früher oder später, eher früher, angegriffe und mit Brute-Force und Scannern belegt. Bei der 2. Variante bräuchte man bei jedem Kunden eine WAF.
Die Variante mit dem ausgehenden VPN wäre meine Empfehlung.
Aber auch die Variante mit dem Proxy funktioniert solange die Strecken per SSL gesichert sind.
Portweiterleitungen sind technisch simpel und Fehler lassen sich einfacher finden als VPN-Fehler (KISS).
Wir haben selber eine WAF für Exchange-Server entwickelt weil die meisten UTM Firewalls sehr wenig in Petto haben um interne Server vor Externe Webzugriffe zu schützen.
Stefan
hast du dich schon mal mit Cloudflare auseinander gesetzt?
Von Cloudflare habe ich schon gehört, ja. Habe ich mich schon einmal damit auseinandergesetzt. Nein
Das sagen sie All. Inklusive mir
In diesem Fall ist es tatsächlich so. Ich hab damit nichts zu tun.Alle 3 Versionen von Dir kann man machen.
Wobei ich die 1. und 3. vorziehen würde, denn in Deiner Ansicht fehlt eine WAF.
Ist eine WAF denn nicht unbedingt bei 1 und 3 notwendig?Wobei ich die 1. und 3. vorziehen würde, denn in Deiner Ansicht fehlt eine WAF.
Auf dem zentralen Reverse Proxy sollte dann doch eine WAF sein?
Auch bei 3 müsste dann auf dem zentralen Proxy eine WAF sein.
Bei 2 verstehe ich es. Da sollte dann bei jedem Kunden eine WAF sein.
Jeder Form von Webanwendung wird früher oder später, eher früher, angegriffe und mit Brute-Force und Scannern >belegt. Bei der 2. Variante bräuchte man bei jedem Kunden eine WAF.
Ist mir absolut bewusst.Aber auch die Variante mit dem Proxy funktioniert solange die Strecken per SSL gesichert sind.
Richtig. Es wird in diesem Fall mit LetsEncrypt Zertifikaten gearbeitet. Also ist die Verbindung SSLverschlüsselt.
Deine Antwort bestätigt mir ja schonmal das ich auf dem richtigen Weg bin.
Danke an der Stelle für deinen Beitrag.
Ich hoffe noch mehr Meinungen dazu lesen zu dürfen.
Zitat von @Ueba3ba:
Ist eine WAF denn nicht unbedingt bei 1 und 3 notwendig?
Auf dem zentralen Reverse Proxy sollte dann doch eine WAF sein?
Auch bei 3 müsste dann auf dem zentralen Proxy eine WAF sein.
Bei 2 verstehe ich es. Da sollte dann bei jedem Kunden eine WAF sein.
Ist eine WAF denn nicht unbedingt bei 1 und 3 notwendig?
Auf dem zentralen Reverse Proxy sollte dann doch eine WAF sein?
Auch bei 3 müsste dann auf dem zentralen Proxy eine WAF sein.
Bei 2 verstehe ich es. Da sollte dann bei jedem Kunden eine WAF sein.
Eine WAF sollte man immer haben sobald es wichtige Software oder Daten geht.
Bei 2 brauchte man ganz viele WAFs die man pflegen und überwachen muss.
Bei 1 und 3 gibt es einen zentralen Proxy.
Das braucht man dann nur eine WAF.
Stefan
Bei 1 und 3 gibt es einen zentralen Proxy.
Das braucht man dann nur eine WAF.
Das braucht man dann nur eine WAF.
Verstehe, der administrative Aufwand reduziert sich natürlich bei nur einer WAF.
Würde ich ebenso so bevorzugen.
hast du dich schon mal mit Cloudflare auseinander gesetzt?
Schau ich mir eben an. Liest sich erst einmal vielversprechend, Cloudflare als ReverseProxy einzusetzen.Danke dafür.
Moin,
meine unmaßgebliche Meinung:
Für mich wäre best practice, erst einmal in der Entwicklungsabteilung nachzufragen, von wo nach wo Euer Programm Verbindungen aufbaut. Denn da stellst Du ja im Wesentlichen Vermutungen an. Als Hersteller aber müsst Ihr es wissen. Und Umschaltungen auf core1 etc. werden ja irgendwo in der Programmlogik gemacht, ebenso wie irgendwelche zusätzlichen SSH Tunnel. Das sollte wohl erst einmal konsolidiert werden, alleine schon aus Sicherheitsgründen, um möglichst wenige "Eingänge" und damit möglichst wenige Angriffspunkte zu bieten.
In diesem Sinne verstehe ich auch das nicht:
Ich gehe doch davon aus, dass die Benutzer-Oberfläche eine WebApp ist, die auf dem IIS läuft. Wozu muss dann die Datenbank über Ports von außen (oder auch nur aus dem LAN) erreichbar sein? Es reicht doch vollkommen aus, wenn die WebApp auf dem Server lokal die Datenbank ansprechen kann. Wenn das wirklich so ist, dass die Datenbank von einem Punkt außerhalb des Servers zu erreichen ist, würde ich das ganz schnell deaktivieren.
verschlüsselt.
Das z.B. ist ein Trugschluss. Nur weil irgendwo Zertifikate installiert sind, bedeutet das ganz sicher nicht, dass überhaupt SSL benutzt und vor allem durchgängig, von A bis Z, eine verschlüsselte Verbindung genutzt wird. Das aber ist natürlich unabdingbar.
Wenn klar ist, welche Verbindungen wirklich genutzt werden müssen, dann solltet Ihr Euch auf 2 Varianten einstellen:
a) der Kunde will alles in seinem Zugriff haben
Bedeutet: kein fremder (=Euer) Proxy, keine fremden Zertifikate und Domains (also solche, auf die - nur - Ihr Zugriff habt, sondern Terminierung direkt auf der Firewall des Kunden. Da dann mit den Vorschlägen von @StefanKittel.
b) dem Kunden ist das egal
Dann könnt Ihr die vorgelagerten Sachen von Euch nutzen, dann aber idealerweise auch direkt mit VPNs abgesichert.
Gruß
DivideByZero
meine unmaßgebliche Meinung:
Zitat von @Ueba3ba:
Es gibt folgende URL's:
app.kunde.meinsoftware.de
api.kunde.meinesoftware.de
Diese Domänen liegen bei unseren Developern.
Diese haben irgendwo einen vServer mit einem ReverseProxy am laufen, der alle Anfragen an die Zielserver leitet.
Dann gibt es scheinbar noch einen SSH Tunnel der Ports umleitet. Durchblicken tu ich da mal überhaupt nicht mehr.
Rufe ich die Applikation über die URL: app.kunde.meinesoftware.de auf, und navigiere durch das Programm,
ändert sich die URL zu: core1.meinesoftware.de und andere.
Ich möchte mich so gut wie es nur geht, dabei an best practice halten.
Es gibt folgende URL's:
app.kunde.meinsoftware.de
api.kunde.meinesoftware.de
Diese Domänen liegen bei unseren Developern.
Diese haben irgendwo einen vServer mit einem ReverseProxy am laufen, der alle Anfragen an die Zielserver leitet.
Dann gibt es scheinbar noch einen SSH Tunnel der Ports umleitet. Durchblicken tu ich da mal überhaupt nicht mehr.
Rufe ich die Applikation über die URL: app.kunde.meinesoftware.de auf, und navigiere durch das Programm,
ändert sich die URL zu: core1.meinesoftware.de und andere.
Ich möchte mich so gut wie es nur geht, dabei an best practice halten.
Für mich wäre best practice, erst einmal in der Entwicklungsabteilung nachzufragen, von wo nach wo Euer Programm Verbindungen aufbaut. Denn da stellst Du ja im Wesentlichen Vermutungen an. Als Hersteller aber müsst Ihr es wissen. Und Umschaltungen auf core1 etc. werden ja irgendwo in der Programmlogik gemacht, ebenso wie irgendwelche zusätzlichen SSH Tunnel. Das sollte wohl erst einmal konsolidiert werden, alleine schon aus Sicherheitsgründen, um möglichst wenige "Eingänge" und damit möglichst wenige Angriffspunkte zu bieten.
In diesem Sinne verstehe ich auch das nicht:
Die Applikation besteht aus der eigentlichen Benutzer-Oberfläche, einer Datenbank und einer API.
Oberfläche, Datenbank und API sind über verschiedene Ports erreichbar. Klar soweit!
Oberfläche, Datenbank und API sind über verschiedene Ports erreichbar. Klar soweit!
Ich gehe doch davon aus, dass die Benutzer-Oberfläche eine WebApp ist, die auf dem IIS läuft. Wozu muss dann die Datenbank über Ports von außen (oder auch nur aus dem LAN) erreichbar sein? Es reicht doch vollkommen aus, wenn die WebApp auf dem Server lokal die Datenbank ansprechen kann. Wenn das wirklich so ist, dass die Datenbank von einem Punkt außerhalb des Servers zu erreichen ist, würde ich das ganz schnell deaktivieren.
Aber auch die Variante mit dem Proxy funktioniert solange die Strecken per SSL gesichert sind.
Richtig. Es wird in diesem Fall mit LetsEncrypt Zertifikaten gearbeitet. Also ist die Verbindung SSLverschlüsselt.
Das z.B. ist ein Trugschluss. Nur weil irgendwo Zertifikate installiert sind, bedeutet das ganz sicher nicht, dass überhaupt SSL benutzt und vor allem durchgängig, von A bis Z, eine verschlüsselte Verbindung genutzt wird. Das aber ist natürlich unabdingbar.
Wenn klar ist, welche Verbindungen wirklich genutzt werden müssen, dann solltet Ihr Euch auf 2 Varianten einstellen:
a) der Kunde will alles in seinem Zugriff haben
Bedeutet: kein fremder (=Euer) Proxy, keine fremden Zertifikate und Domains (also solche, auf die - nur - Ihr Zugriff habt, sondern Terminierung direkt auf der Firewall des Kunden. Da dann mit den Vorschlägen von @StefanKittel.
b) dem Kunden ist das egal
Dann könnt Ihr die vorgelagerten Sachen von Euch nutzen, dann aber idealerweise auch direkt mit VPNs abgesichert.
Gruß
DivideByZero
Zitat von @Ueba3ba:
Wird die Software von einem Kunden erworben, richten wir dort einen Server ein.
Meistens wird dies ein HP DL380 G10 mit ausreichend Ressourcen.
Auf dem Server wird HyperV installiert.
Es wird eine VM angelegt und auf dieser Windows Server installiert.
Es werden der IIS und eine MySQL Datenbank installiert und eingerichtet.
Die Applikation wird über die interne IP des Servers, oder über eine URL aufgerufen.
Die Applikation besteht aus der eigentlichen Benutzer-Oberfläche, einer Datenbank und einer API.
Oberfläche, Datenbank und API sind über verschiedene Ports erreichbar. Klar soweit!
Die ganze Software wurde auf .Net Core umgestellt. Relevant? Ich denke nicht.
Manche Kunden haben eine statische Public IP, andere nur eine dynamische, wieder andere haben das Pech, und haben nur eine Carrier Grade NAT IP. Was das bedeutet muss ich ja nicht näher erläutern.
Es gibt folgende URL's:
app.kunde.meinsoftware.de
api.kunde.meinesoftware.de
Diese Domänen liegen bei unseren Developern.
Diese haben irgendwo einen vServer mit einem ReverseProxy am laufen, der alle Anfragen an die Zielserver leitet.
Meistens wird dies ein HP DL380 G10 mit ausreichend Ressourcen.
Auf dem Server wird HyperV installiert.
Es wird eine VM angelegt und auf dieser Windows Server installiert.
Es werden der IIS und eine MySQL Datenbank installiert und eingerichtet.
Die Applikation wird über die interne IP des Servers, oder über eine URL aufgerufen.
Die Applikation besteht aus der eigentlichen Benutzer-Oberfläche, einer Datenbank und einer API.
Oberfläche, Datenbank und API sind über verschiedene Ports erreichbar. Klar soweit!
Die ganze Software wurde auf .Net Core umgestellt. Relevant? Ich denke nicht.
Manche Kunden haben eine statische Public IP, andere nur eine dynamische, wieder andere haben das Pech, und haben nur eine Carrier Grade NAT IP. Was das bedeutet muss ich ja nicht näher erläutern.
Es gibt folgende URL's:
app.kunde.meinsoftware.de
api.kunde.meinesoftware.de
Diese Domänen liegen bei unseren Developern.
Diese haben irgendwo einen vServer mit einem ReverseProxy am laufen, der alle Anfragen an die Zielserver leitet.
Als Kunde würde ich mich Fragen, warum überhaupt ein Zugriff vom Hersteller von extern notwendig sein sollte, wo doch alles schon im Haus steht (Hardware, Windows Systeme inkl. Lizenzen, DB inkl. Lizenzen, Applikation inkl. Lizenz).
Irgendwie erschließt sich mir der Sinn überhaupt nicht, warum ein so komplizierter Zugriffsweg implementiert werden muss.
Es hört sich eher nach SaaS an. Dann braucht man doch aber nichts beim Kunden direkt zu implementieren.
Moin,
ich würde erst einmal hinterfragen, warum überhaupt differenziert wird - von Kunde zu Kunde. Weil das macht die Fehlersuche und die Dokumentation jeder Installation nicht einfacher. Sowas muss aus aus meiner Sicht standardisiert sein, egal wie klein wie groß der Kunde ist, welche Modul er (nicht) nutzt, etc. Das was ihr da habt ist ein Zoo...
Gruß,
Dani
Auf manchen Kunden-Servern ist zusätzlich noch ein Ngninx installiert, der an andere Ports weiterleitet.
Dann gibt es scheinbar noch einen SSH Tunnel der Ports umleitet. Durchblicken tu ich da mal überhaupt nicht mehr.
Rufe ich die Applikation über die URL: app.kunde.meinesoftware.de auf, und navigiere durch das Programm,
ändert sich die URL zu: core1.meinesoftware.de und andere.Dann gibt es scheinbar noch einen SSH Tunnel der Ports umleitet. Durchblicken tu ich da mal überhaupt nicht mehr.
Rufe ich die Applikation über die URL: app.kunde.meinesoftware.de auf, und navigiere durch das Programm,
ich würde erst einmal hinterfragen, warum überhaupt differenziert wird - von Kunde zu Kunde. Weil das macht die Fehlersuche und die Dokumentation jeder Installation nicht einfacher. Sowas muss aus aus meiner Sicht standardisiert sein, egal wie klein wie groß der Kunde ist, welche Modul er (nicht) nutzt, etc. Das was ihr da habt ist ein Zoo...
Das erschwert es mir unheimlich ein DNS Forwarding für die internen Clients einzurichten.
Beim Kunden oder bei euch?Gruß,
Dani
@DivideByZero
Danke für deinen Beitrag.
Richtig. Wird geklärt.
Die Datenbank ist von außen natürlich nicht zu erreichen.
In der Tat, so einen Kunden haben wir bereits.
In einem solchen Fall wäre dann "Option 2" meines Entwurfs bei dem Kunden anzuwenden.
Natürlich mit den Kunden-Domänen und nicht unsere.
@mbehrens
Es geht nicht um den Zugriff für uns.
Es geht darum, das der Kunde auch aus dem Internet heraus Zugriff auf die Software hat.
VPN wäre da sicherlich die beste Option. Aber nicht jeder Kunde/Mitarbeiter möchte erst eine VPN Verbindung aufbauen um auf die Software zuzugreifen.
@Dani
danke an alle für die Beiträge.
Es wurden einige Punkte genannt, die sehr wichtig sind und die ich ansprechen werde.
Da muss in naher Zukunft etwas passieren.
Es ist ja eigentlich auch nicht meine Aufgabe mich darum zu kümmern. Ich bin nur der Netzwerk-Admin.
Oder sagen wir so, mit wurde es nicht zur Aufgabe gemacht. Darum kümmern sich schon immer die Developer.
Danke für deinen Beitrag.
Für mich wäre best practice, erst einmal in der Entwicklungsabteilung nachzufragen, von wo nach wo Euer Programm Verbindungen aufbaut.
Richtig. Wird geklärt.
ch gehe doch davon aus, dass die Benutzer-Oberfläche eine WebApp ist, die auf dem IIS läuft. Wozu muss dann die Datenbank über Ports von außen (oder auch nur aus dem LAN) erreichbar sein?
Die Datenbank ist von außen natürlich nicht zu erreichen.
Es reicht doch vollkommen aus, wenn die WebApp auf dem Server lokal die Datenbank ansprechen kann.
Genau so ist es auch. Nur der IIS hat Zugriff auf die DB.a) der Kunde will alles in seinem Zugriff haben
Bedeutet: kein fremder (=Euer) Proxy, keine fremden Zertifikate und Domains (also solche, auf die - nur - Ihr Zugriff >habt, sondern Terminierung direkt auf der Firewall des Kunden. Da dann mit den Vorschlägen von @StefanKittel.
Bedeutet: kein fremder (=Euer) Proxy, keine fremden Zertifikate und Domains (also solche, auf die - nur - Ihr Zugriff >habt, sondern Terminierung direkt auf der Firewall des Kunden. Da dann mit den Vorschlägen von @StefanKittel.
In der Tat, so einen Kunden haben wir bereits.
In einem solchen Fall wäre dann "Option 2" meines Entwurfs bei dem Kunden anzuwenden.
Natürlich mit den Kunden-Domänen und nicht unsere.
@mbehrens
Es geht nicht um den Zugriff für uns.
Es geht darum, das der Kunde auch aus dem Internet heraus Zugriff auf die Software hat.
VPN wäre da sicherlich die beste Option. Aber nicht jeder Kunde/Mitarbeiter möchte erst eine VPN Verbindung aufbauen um auf die Software zuzugreifen.
@Dani
Weil das macht die Fehlersuche und die Dokumentation jeder Installation nicht einfacher. Sowas muss aus aus meiner >Sicht standardisiert sein, egal wie klein wie groß der Kunde ist, welche Modul er (nicht) nutzt, etc. Das was ihr da habt >ist ein Zoo...
Absolut richtig.Beim Kunden oder bei euch?
Im internen Netzwerk des Kundendanke an alle für die Beiträge.
Es wurden einige Punkte genannt, die sehr wichtig sind und die ich ansprechen werde.
Da muss in naher Zukunft etwas passieren.
Es ist ja eigentlich auch nicht meine Aufgabe mich darum zu kümmern. Ich bin nur der Netzwerk-Admin.
Oder sagen wir so, mit wurde es nicht zur Aufgabe gemacht. Darum kümmern sich schon immer die Developer.