TCP/IP Verbidung/Port und Firewalls?



  • Morgen Freunde,

    nehmen wir an ich würde eine Server/client anwendung programmieren, und würde den Client als Fernwartungswerkzeug verwenden um den Server zu überwachen bzw. Datenlesen etc. . Der Server steht später vll. hinter eine Firewall, dann hab ich wahrscheinlich schlechte Karten mit dem Client ne verbindung aufzubauen, wenn ich über nene x-beliebigen Port zugreife.
    Wie sind den die meisten firewall konfiguriert, welche Port sind std. mässig ehr offen? bspw. Port 80 für http, oder 21 für ftp etc. ? Ohne die Firewall konfigurieren zu müssen, kann hab ich da keine change oder? Port 80 kann ich für meine zwecke nich nehmen oder vll. doch? Anderes Protokoll?
    Ich möchte gewährleisten wenn ich so ein Fernwartungswerkzeug mache, das man auch in den meisten fällen damit auf den Server kommt. Was meint ihr?

    P.S.: Ich kenn mich mit dem ganzen Netzwerkgedöns nich so aus, falls ich was falschen geschrieben habe etc. berichtigt mich.

    Grüße



  • doch, HTTP kannste auch nehmen. das schimpft sich dann 'HTTP tunneling'. ansonsten haste recht, wenn 'ne firewall irgendwas blockt, dann hast du (mit normalen sockets jedenfalls) keine chance. also der, der dein progrämmchen betreiben soll, muss seine firewall so konfigurieren, dass dein programm vernünftig arbeiten kann.
    🙂



  • nehm ich den HTTP port, hat das sonstige auswirkungen ?? stört sich das nicht mit dem http gedöns,internet usw.?



  • Firewalls sind so konfiguriert, dass genau die Ports durchgelassen werden, auf denen auf dem Server auch Dienste angeboten werden (wenn der Firewall-Admin auch nur ein wenig Ahnung von dem hat, was er tut).

    Es sind also nur die Ports offen, die du nicht benutzen kannst, weil darauf schon ein anderer Dienst läuft.



  • BorisDieKlinge schrieb:

    nehm ich den HTTP port, hat das sonstige auswirkungen ?? stört sich das nicht mit dem http gedöns,internet usw.?

    du kannst z.b. keine zwei server auf dem gleichen port an einem netzwerk-interface (bzw. auf der gleichen ip-adresse) lauschen lassen. also, falls du port 80 für deinen server nimmts, beisst sich das mit einem apachen o.ä, der auf der gleichen kiste an port 80 horcht.
    🙂



  • für den ganzen kram tcp/IP netwerk firewall service etc. gibts da ein gutes buch, oder e-book, pdf zum nachlesen?



  • BorisDieKlinge schrieb:

    für den ganzen kram tcp/IP netwerk firewall service etc. gibts da ein gutes buch, oder e-book, pdf zum nachlesen?

    das standardwerk: TCP-IP-Illustrated

    edit: Bitte keine Links zu rechtlich bedenklichen Angeboten 😡



  • In jedem Fall muss der entsprechende Port freigegeben werden. Auch HTTP sollte ohne weiteres nicht in einer Firewall freigegeben sein. Soll die Anwendung vom Administrator verborgen bleiben? Wenn nein, wo ist das Problem dem Admin zu sagen, er soll den entsprechenden Port freischalten?

    Warum nimmst du nicht auch gleich HTTP als Protokoll und machst die Systemüberwachung als (Fast)CGI?

    http://en.wikipedia.org/wiki/TCP_hole_punching



  • hey hab in nem anderen thread was con SOAP gelesen? Taugt diese Protokol was, wäre CGI besser?



  • BorisDieKlinge schrieb:

    hey hab in nem anderen thread was con SOAP gelesen? Taugt diese Protokol was, wäre CGI besser?

    Das sind zwei unterschiedliche Sachen und nach dem was ich gehört habe, taugt SOAP nicht viel.



  • rüdiger schrieb:

    nach dem was ich gehört habe, taugt SOAP nicht viel.

    Es wird halt meistens unnoetigerweise eingesetzt. REST ist sicher für 90% der Fälle wo SOAP verwendet wird soviel besser geeignet.

    Aber SOAP hat einen Vorteil: automatisierungen.
    Da alles so genau spezifiziert ist und du ja auch deinen Webservice spezifizierst können agenten kommen und das auswerten und automatische systeme implementieren die dynamisch zB neue services eingliedern, da sie verstehen was der service von ihnen will und auch verstehen was sie zurück bekommen. das ist durchaus interessant.

    nur wenn jemand einen einfachen webservice haben will, dann ist soap die falsche wahl.


Anmelden zum Antworten