Scanner und Sockets

[BlackJack]

Da bekomme ich auch sofort eine Ausnahme, und zwar die die der OP auch so häufig sieht:

Code: Alles auswählen

In [9]: s.connect(('10.0.0.1', 1234))
---------------------------------------------------------------------------
error                                     Traceback (most recent call last)
<ipython-input-9-8218c8853767> in <module>()
----> 1 s.connect(('10.0.0.1', 1234))

/usr/lib/python2.7/socket.pyc in meth(name, self, *args)
    222 
    223 def meth(name,self,*args):
--> 224     return getattr(self._sock,name)(*args)
    225 
    226 for _m in _socketmethods:

error: [Errno 111] Connection refused

[miracle173]

@miracle173: Was meinst Du mit IPs für die es keinen Server gibt? Wenn ich eine nicht vergebene IP verwende, passiert das hier:

Code: Alles auswählen

(...)
error: [Errno 113] No route to host

Und zwar so ziemlich sofort und ohne eine Zeitüberschreitung gesetzt zu haben.

Na ja, wenn du diese IP nicht erreichen kannst, macht es keinen Sinn, sie mit einem Portscanner zu überprüfen. Du kommst ja offenbar nicht in das Netzwerksegment in dem der Rechner steht (bzw. stehen könnte). Ich kann dir aber nicht genau sagen, wie es zu so diser Fehlermeldung kommt und habe auch nach einigem googeln noch keine sinnvoller Erklärung gefunden. Wenn du aber mit deinem Portscanner in das entsprechende Neztwerk kommst, z.b. weil der Rechner, wo der Portscanner läuft, in diesem Neztwerk steht, dann gibt es dort nichts, was dir sagt, das eine Adresse nicht benutzt ist, sondern es kommt einfach nichts zurück, wenn du an diese Adresse etwas sendest. Und nach einiger Zeit (timeout) nimmst du an, da gibt es keinen Rechner mit dieser Adresse.

[BlackJack]

@miracle173: Der Client befindet sich in dem Netzwerk, also komme ich da auch rein. Die IP ist halt nicht vergeben.

[miracle173]

@miracle173: Der Client befindet sich in dem Netzwerk, also komme ich da auch rein. Die IP ist halt nicht vergeben.

Nein, ich denke das ist einfach falsch. Ich habe noch einmal etwas gegoogelt und hier eine verständliche, hoffentlich richtige Beschreibung gefunden:
http://aplawrence.com/Unixart/route.html

Du hast eine Linux-Maschine 192.168.200.83

Code: Alles auswählen

# ifconfig -a
(...)
inet addr:192.168.200.83  Bcast:192.168.200.255  Mask:255.255.255.0
(...)

und eine Windows Maschine 192.168.201.35

Code: Alles auswählen

C:\> ipconfig /all
(...)
   IPv4-Adresse  . . . . . . . . . . : 192.168.201.35(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
(...)

Also wir haben zwei Netzwerke 192.168.200 und 192.168.201. Die genaue Bezeichnung lautet, da die Subnetmask 255.255.255.0 ist, 192.168.200.0/24 und 192.168.201.0/24. Jedes hat 254 IP-Adressen für Rechner zu vergeben. Die beiden restlichen Adressen nnn.nnn.nnn.0 Adresse (Netzwerkadresse) und die nnn.nnn.nnn.255 Adresse (Broadcast Adresse) können ja nicht vergeben werden.

Wenn du nun vom Windows Server ein "ping 192.168.200.83" absetzt, bekommst du ein "Destination host unreachable", wenn du vom Linux Server ein "ping 192.168.201.35" absetzt, bekommst du "No route to host". Das ist, weil kein Weg es keine Verbindung von dem einem Netz zum anderen Netz gibt.

Die gleichen Meldungen bekommst du, wenn du vom Windows Server ein "ping 192.168.200.123" absetzt und vom Linux Server ein "ping 192.168.201.123" und die 192.168.200.123 und 192.168.201.123 noch keinen Servern zugeteilt sind.

Die Fehlermeldung ist unabhängig davon, ob ein Server im anderen Netzt die IP-Adresse konfiguriert hat oder nicht. In dem einem Netz weiß man nichts über das andere Netz.

Nehmen wir nun an, dass beide Netze durch einen Router verbunden sind. Der Router hängt im Linux Server Netz mit 192.168.200.1 und im Windows Server Netz mit 192.168.201.1.

Setzt man nun die selben Kommandos ab, bekommt man noch immer die selben Fehlermeldungen.

Erst wenn man nun am Windows Server für das Netz 192.168.200.0 das Gateway 192.168.201.1 konfiguriert, kann man vom Windows Server nun den Linux Server 192.168.200.83 erreichen. Allerdings erhält man nun die Fehlermeldung "Request timed out". Warum? Weil der Windows Server zwar nun weiß, wie Pakete an den Linux Server 192.168.200.83 geschickt werden. Aber er erhält keine Antworten auf seine Pakete. Der Linux Server weiß noch nicht, wie er die Antworten zurück schicken soll. Erst wenn man am Linux Server 192.168.200.1 ls Gateway für 192.168.200.0 einträgt, können auch Pakete zurückgeschickt werden und die Kommunikation zwischen beiden Server funktioniert. Die Adresse 192.168.200.123 ist aber weiterhin noch keinem Server zugeordnet und deshalb erhält man hier weiterhin "Request timed out".

Natürlich wird die Situation im Allgemeinen komplizierter sein, da zwei Netzwerke meistens nur indirekt, also über Zwischennetzwerke, verbunden sind. Das Prinzip bleibt aber das gleiche.