"Christmas - the time to fix the computers of your loved ones" « Lord Wyrm

Interne IP, Proxy

Gräflicher 15.11.2012 - 21:29 3356 24
Posts

Gräflicher

Here to stay
Registered: Dec 2001
Location: Baden bei Wien
Posts: 976
Sorry für den unbeholfenen Titel, probier das Problem mal genauer zu beschreiben.

Ich entwickle auf Ubuntu eine Chat-App (node.js, express MongoDB), bei welcher die User über ihre IP Adresse identifiziert werden. Soweit so gut. Ich entwickle lokal und push es dann von Zeit zu Zeit auf einen Server.

Das Problem: um lokal ordentlich entwickeln zu können möchte ich einfach und schnell verschiedene Benutzer simulieren können. Wenn die App jedoch lokal läuft und ich mit dem lokalen Browser zugreife haben alle "Besucher" die IP 127.0.0.1 Klar. Um einen zweiten "Besucher" simulieren zu können bräuchte ich aber ne andere IP als die 127.0.0.1

Wo kriege ich die nun her? Mein erster Gedanke war einen zweiten Browser via Proxy zu verbinden, dann hätte zB Firefox 127.0.0.1 und Opera eben die IP vom Proxy und ich könnte meine 2 Besucher simulieren.

Gäbe da grundsätzlich auch andere, bessere Möglichkeit in der Linux-Welt? Falls die Proxy-Lösung der richtige Weg wäre - wie könnte ich das in Ubuntu möglichst problemlos hinkriegen?

Wenn da wer eine Idee hätte, wär mir wirklich geholfen. Vielen Dank :)
Bearbeitet von Gräflicher am 17.11.2012, 12:38

mr.nice.

endlich fertig
Avatar
Registered: Jun 2004
Location: Wien
Posts: 6296
Also ich würde mir mit Virtual Box die benötigte Anzahl an virtuellen Maschinen erstellen, z.B. für jede wichtige Browser/OS Kombination eine. In den Netzwerkeinstellungen ein internes Netzwerk mit statischen IP-Adressen einrichten, das ermöglicht die Kommunikation der VM's untereinander und verhindert, dass ungewollt irgendwas nach Außen dringt. Jede VM braucht eine eigene IP- und MAC-Adresse ;)

Um das ganze möglichst übersichtlich zu halten und IP-Konflikte zu vermeiden, solltest du einen anderen IP-Bereich verwenden als außerhalb der VM's, wenn du selbst z.B. ein Klasse C (192.168..) Netz verwendest, könntest du für die Testerei ein Klasse B (172.16..) Netz verwenden. Diese Netzklassen werden sowieso nicht geroutet, also das "nach Außen dringen" wäre in dem Fall maximal in dein Netzwerk.

Aber so kannst du schön den Traffic monitoren, es erleichtert das Troubleshooting und du musst dich nicht mit Netzwerkzeugs herumschlagen -> mehr Zeit für eine bessere Applikation.

Gräflicher

Here to stay
Registered: Dec 2001
Location: Baden bei Wien
Posts: 976
Ahhh! Vielen Dank! Daran hatte ich nicht gedacht. War eigentlich immer der Meinung das der Webserver über die 192.168.0.x nicht erreichbar wäre sondern lediglich über die 127.0.0.1.
Siehe da, er ist über beide erreichbar! Das ist schon praktisch. Auf einem Tab die 127.0.0.1 öffnen, in einem anderen Tab die 192.168.0.x öffnen und schon kann man 2 Benutzer simulieren ohne den Browser oder die VM wechseln zu müssen.

Danke :)

Ringding

Pilot
Avatar
Registered: Jan 2002
Location: Perchtoldsdorf/W..
Posts: 4300
Wieso soll es überhaupt pro IP-Adresse nur einen User geben können? Du wirst vermutlich bald bemerken, dass das eine sinnlose Einschränkung ist.

Denne

Here to stay
Avatar
Registered: Jan 2005
Location: Germany
Posts: 2801
Richtig.
Wenn 2 User über die selbe dsl-Leitung ins Netz gehen, haben sie nach außen die selbe IP-Adresse, nur im Heimnetzwerk unterschiedliche.

COLOSSUS

Administrator
Frickler
Avatar
Registered: Dec 2000
Location: ~
Posts: 11899
Also wenn du schon ausschl. Layer 3 und 4 zur Identifikation der Clients verwenden willst, dann musst du mindestens Client-IP + Client-(Source-)Port in Betracht ziehen; alles andere ist ein Designfehler. Diese Informationen exportiert dir die Socket-API. Falls die Information auch fuer Chatteilnehmer sichtbar ist, waere Salten+Hashen auch angebracht, um die Privatsphaere der Nutzer einander gegenueber zu wahren.

Gräflicher

Here to stay
Registered: Dec 2001
Location: Baden bei Wien
Posts: 976
Vielen Dank für das rege Feedback.
Ich verwende die IP Adresse eigentlich nur um zahlende (Firmen)-Kunden von allen anderen zu unterscheiden. Die Kunden sollten also unterschiedliche IP Adressen bzw Ranges haben.
Zudem wird zwischen eigenen Mitarbeitern und Kunden unterschieden. Auch hier sollte dann die IP zur Unterscheidung reichen.

Es wird die IP vor der Chat-Verbingung mit der Datenbank abgeglichen. Wenn der Zugriff von einem zahlenden Kunden (Firma) kommt und geht es weiter zum Chat - alle anderen kommen erst gar nicht rein. Ist also als Zutrittkontrolle zum Chat gedacht und nicht um einzelne Chatpartner identifizieren zu können.

Die eigentlichen Chatverbindungen werden via Websocket (socket.io) hergestellt.
Bearbeitet von Gräflicher am 16.11.2012, 19:33

Denne

Here to stay
Avatar
Registered: Jan 2005
Location: Germany
Posts: 2801
Haben denn diese Kunden statische IP-Adressen?
Ansonsten kann ich mir nicht wirklich erklären, wie du diese mit einer Datenbank abgleichen willst.
Außerdem finde ich diese Lösung nicht sonderlich "gut", aber die Entscheidung liegt ganz bei dir.

mr.nice.

endlich fertig
Avatar
Registered: Jun 2004
Location: Wien
Posts: 6296
Ack, ich würde da z.B. eher auf Zertifikate setzen, kann man mit OpenSSL auch kostenfrei umsetzen und unbedingt SSLv2 deaktivieren ;)

Gerade wenn Firmen dort quatschen sollen erscheint mir eine sichere Authentifizierung als sehr sinnvoll.

Gräflicher

Here to stay
Registered: Dec 2001
Location: Baden bei Wien
Posts: 976
Also wenn es bessere Lösungsansätze gibt ist das natürlich schon gut :)
Die Kunden wären Firmen mit >100 Mitarbeitern, insofern geh ich mal davon aus, dass statische IPs vorhanden sind. Hab aber auch zu wenig Überblick über die technische Infrastruktur der jeweiligen Firmen, also ist das eher eine Vermutung. Momentan wäre im Konzept der Austausch eines Secrets vorgesehen, falls es keine statische IP ist.


Kann nicht zu genau auf das Konzept eingehen, aber ich versuch mal die Rahmenbedingungen zu schildern:

Die Authentifizierung darf auf keinen Fall via Login/Passwort geschehen und sollte möglichst wenig Aufwand auf Seiten des Kunden bedeuten. Auf meiner Seite wäre ein Zertifikat vorhanden, was für Möglichkeiten/Rahmenbedingungen auf Seiten der Kunden vorhanden ist kann ich noch nicht sagen. Daher wären Fallback-Varianten interessant. Die Version mit der IP Authentifizierung war fürs erste relativ einfach umzusetzen. Wenn die Lösung nicht optimal ist freu ich mich natürlich über bessere :) Welche Vorteile würden da etwa Zertifikate bringen?

Der Chat soll über das Intranet erreichbar sein, jedoch auf einem externen Server ablaufen. Die Verbindung muss also verschlüsselt und sicher sein. Zudem sollte ausschließlich der Webbrowser zum Einsatz kommen. Authentifiziert wird nur die jeweilige Firma, nicht der einzelne Teilnehmer/Benutzer

mr.nice.

endlich fertig
Avatar
Registered: Jun 2004
Location: Wien
Posts: 6296
Ein Szenario wäre z.B., dass nur ein öffentlich erreichbarer Firmenserver eine SSL gesicherte Verbindung aufbaut, mit einem Zertifikat, dass auf ihn ausgestellt ist. So kann man im Notfall einzelne Zertifikate widerrufen, wenn eine Firma gehackt werden sollte, oder nicht zahlt.

Die einzelnen User connecten zu ihrem jeweiligen Chatserver in der Firma per Webinterface. Deren Anmeldung könnte man dann je nach Bedarf per LDAP, Cookies oder was auch immer machen.

Anbei eine kleine Skizze :)
click to enlarge

Der Einmalaufwand ist zwar vorhanden, aber dann muss man bis auf ordentliche Wartung nicht mehr viel machen.

Gräflicher

Here to stay
Registered: Dec 2001
Location: Baden bei Wien
Posts: 976
Nice :)
Grundsätzlich möchte ich natürlich so viele verschiedene Authentifizierungsmethoden wie möglich anbieten. Welche dann beim jeweiligen Kunden zum Einsatz kommt hängt dann eigentlich von deren IT-Abteilung ab.
Wenn ich dein Szenario richtig verstanden habe liegt der "lokale Chatserver" eigentlich innerhalb des Kunden-IT? Für mich ist es schwer abzuschätzen wie die Wünsche der IT-Abteilung konkret aussehen werden, weshalb ich versuche verschiedene Szenarien abdzudecken.

Für die einzelnen User ist keine Anmeldung vorgesehen. Der Chat soll vor allem "abhörsicher" sein im Sinne, dass keine Inhalte nach außen dringen. Ob ein Hacker mitchattet oder nicht ist eigentlich vernachlässigbar

Kann hier nicht so genau ins Detail gehen, wenn ich dir aber mal eine PM schreiben dürfte freu ich mich natürlich :) Gerade die Sache mit Zertifikaten ist für mich Neuland.

Denne

Here to stay
Avatar
Registered: Jan 2005
Location: Germany
Posts: 2801
Wenn ich die Skizze richtig verstanden habe, hätte jede Firma einen eigenen Chat-Server.

Auch wenn das Design wohl gut klappen würde, müsste jeder Kunde einen eigenen Chat-Server einrichten, diesen konfigurieren und warten.
Ich weiß nicht, ob die Firmen bereit wären, solch ein Aufwand zu betreiben.
Ich könnte mir vorstellen, dass sie etwas "einfacheres" haben möchten.

Da ich aber nicht all zu viele Details weiß, kann ich es hier nicht wirklich einschätzen.

Wenn du auf einen Chat-Server bei jeder Firma verzichten willst und keine Authentifizierung via Benutzername und Passwort haben möchtest, müsste jeder Client solch ein Zertifikat haben, anstelle dem Chat-Server, der bei den Kunden steht. Vom Prinzip her also genau das selbe, nur umgehst du den Chat-Server bei den Kunden.

Was die Zertifikate angeht: Für jeden Kunden (Firma) einen separaten ausstellen.

mr.nice.

endlich fertig
Avatar
Registered: Jun 2004
Location: Wien
Posts: 6296
Ist gut möglich mit entsprechender Hardware alles über einen einzigen Server laufen zu lassen, so wie Denne sagt. Allerdings sollten die jeweiligen Firmen dann auch Backupleitungen haben, weil sonst der Internetanschluss schnell zum single point of failure wird.

Denne

Here to stay
Avatar
Registered: Jan 2005
Location: Germany
Posts: 2801
Sonderlich hardwarehungrig dürfte die Angelegenheit an sich nicht sein.
Klar, wenn du dementsprechend viele Kunden hast, müsstest aufrüsten, aber wenn das mal so weit kommen sollte, wirds am Geld nicht mangeln ;)

@ Internetanschluss: Klar, aber einen funktionierenden Anschluss kann man imho voraussetzen. Das sollten die Kunden schon gebacken bekommen bzw. ist das ihr Zuständigkeitsbereich - das ist zumindest meine Meinung.
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz