Netzwerk überprüfen

[Snapy0]

Hallo zusammen,

ich habe eine Client-Server Anwendung. Falls ein Client nicht connecten kann, möchte ich ein Programm schreiben was testet, woran es liegt. Also ich suche nach einer Möglichkeit herauszufinden, ob eine Firewall den Verkehr blockiert, oder ein Proxy oder ein Content-Filter. Oder ob der Router den Rückweg blockiert. Vllt fällt euch auch noch was ein. Der User soll dann eine Rückmeldung erhalten woran es liegt, damit er es beheben kann. Ich hab schon ein paar Sachen probiert, allerdings fehlt mir die zündende Strategie wie ich das angehe. Vielleicht habt ihr ja ein paar Ideen.

Mfg Snapy

[flashpixx]

Letztendlich ist das vom eingesetzten Protokoll anhängig, wie Du das implementieren musst.

Du kannst z.B. nicht prüfen, ob eine Firewall den Verkehr blockiert, denn wenn die FW das Paket via Drop verwirft, dann wirst Du das nur merken, indem Du bei Deinem Client ein Timeout sieht, das aber eine Firewall oder Router nun dazu geführt haben, lässt sich so nicht direkt ermitteln.

Also ein nicht funktionierender Verbindungsaufbau kann nicht dazu führen, dass Du exakt weißt warum es nicht funktioniert. Du kannst letztendlich nur ausschließen, woran es nicht liegt, wobei Du dann eben anhand der Protokollspezifizierung vorgehen musst

[Snapy0]

Hallo flashpixx,

danke für die Antwort. Nehmen wir als Protokolle mal HTTP und FTP an. Man muss doch irgendwie grob einschätzen können woran es liegt. Also ob ein Port gesperrt ist (Firewall) oder sonst wie. Was wären denn Dinge die dir spontan einfallen die man checken könnte? Und könnte ich z.B. HTTP Header und Content ändern um nach Content-Filtern ausschau zu halten?

Mfg Snapy

[flashpixx]

Du kannst einen Header nur prüfen, sofern Du überhaupt einen Header zurück bekommst. Wenn eben der Server z.B. ein Drop All auf ankommende Pakete macht, denn bekommst keinen Header zurück, d.h. Dein Client sendet Pakete raus, erhält aber kein Antwortpaket, die Folge ist ein Time-Out.

HTTP selbst implementiert diverse Statuscodes, die Du, sofern Du einen Header hast prüfen kannst (siehe RFC 2616). FTP arbeitet aber nun mal anders als HTTP, nur weil eine HTTP Verbindung funktioniert, kannst Du nicht rückschießen, dass FTP funktioniert. Wie schon gesagt, wenn ein Fehler auftritt, dann kannst Du nur einzelne Quellen ausschließen, wobei Du eben anhand des OSI Referenzmodell und des konkret eingesetzten Protokolls eben alle möglichen Quellen ausschließen musst. Aber Du kannst daraus nicht ableiten, dass z.B. der Router oder die Firewall nicht richtig funktioniert.

Z.B. kann ich mit Fail2Ban (einem Unixtool) temporär bestimmte IP Adressen / Ranges bei fehlerhaften Zugriffen automatisch via IPTables sperren, d.h. aber für Dich, das Dein Client ggf einen Fehler produziert, Du aber nicht sagen kannst, das liegt an Fail2Ban oder am Router oder an der Firewall.

[Snapy0]

Hmm das klingt einleuchtend. Die HTTP StatusCodes hab ich mir auch schon angeguckt und auch die von ICMP. Kann ich denn nicht durch eine Art traceroute herausfinden wer blockiert (Adresse) und dann auf irgend eine Art mit dem kommunizieren und herausfinden was ihm nicht gefällt ?

[flashpixx]

Kann ich denn nicht durch eine Art traceroute herausfinden wer blockiert (Adresse) [..]

Nein, denn ein Trace sendet immer an den nächsten Hop ein ICMP Paket so dass es der Hop anhand des TTL Feldes verwirft. Die daraus resultierende Antwort wertet das Trace aus. Weiterhin in der Weg, den ein Paket nimmt, nicht deterministisch bestimmbar, jedes Paket kann unterschiedliche Wege durch das INet nehmen um von der Quelle zum Ziel zu kommen.

[..] und dann auf irgend eine Art mit dem kommunizieren und herausfinden was ihm nicht gefällt ?

Nein, denn dafür musst Du wissen welcher Knoten bzw welche Komponente Probleme macht und diese Informationen hast Du allenfalls in den Netzen, auf die Du direkt Zugriff hast. Wenn Pakete, aus welchen Gründen auch immer, einfach gedropped werden, dann wird kein Antwortpaket generiert, d.h. Dein Client sendet Pakete raus, aber Du bekommst keine Antwort. Wo willst Du nun ansetzen, um eine Analyse zu machen. Du kannst maximal in Deinem Netz schauen, bis wohin das Paket läuft, sobald es Dein Netz verlässt, hast Du keine Chance mehr irgendetwas zu prüfen.

Z.B. wie willst Du herausfinden, ob die IP des Zielserver korrekt ist, wenn sie nur über einen Namen im Client eingegeben wird. Wenn Du einen Server hast, der mehrere IPs besitzt und die Pakete via RoundRobin auf die einzelnen Knoten verteilt werden, dann kann theoretisch ein Knoten ausfallen und somit würde der Client einen Fehler produzieren. Durch das RoundRobin Verfahren, wäre aber beim nächsten Version kein Fehler mehr auffindbar, weil durch das Verfahren eine andere und damit funktionierende Node, des Serververbundes gewählt wird.

Wie willst Du ebenfalls überprüfen ob die Zuordnung Name zu IP korrekt ist!? Der Client kennt meist genau einen DNS Server, ist dort aber der Eintrag falsch, läuft Deine Verbindung zu einer IP, die z.B. nicht existiert oder zu einem anderen Server, d.h. nur weil damit der Verbindungsaufbau nicht klappt, was die Konsequenz ist, kannst Du daraus nicht schließen, dass der Fehler in Deinem verwendeten DNS ist bzw umgekehrt ein Verbindungsabbruch impliziert nicht zwingend einen Fehler im DNS

[Snapy0]

Nein, denn ein Trace sendet immer an den nächsten Hop ein ICMP Paket so dass es der Hop anhand des TTL Feldes verwirft. Die daraus resultierende Antwort wertet das Trace aus. Weiterhin in der Weg, den ein Paket nimmt, nicht deterministisch bestimmbar, jedes Paket kann unterschiedliche Wege durch das INet nehmen um von der Quelle zum Ziel zu kommen.

Genau das mein ich ja Das soll unterschiedliche Wege nehmen und wenn dann bei mehreren Wegen der gleiche Knoten Probleme macht, dann weiß ich, dass er der Bösewicht ist.

Die IP des Servers ist statisch. Da sollte also nicht das Problem liegen. Und Fehler sollen auch nur in dem lokalen Netz des Clienten gesucht werden. Da muss sich doch was machen lassen. Wenn ich z.B. nen HTTP Paket losschicke ohne Proxy-Einstellungen dann müsste ich ein 407 zurückbekommen und weiß, dass ein Proxy vorhanden ist. Ähnlich müssten sich doch viele Sachen prüfen lassen.

[flashpixx]

Genau das mein ich ja Das soll unterschiedliche Wege nehmen und wenn dann bei mehreren Wegen der gleiche Knoten Probleme macht, dann weiß ich, dass er der Bösewicht ist.

Nein, Du arbeitest nicht paketorientiert, sondern protokollorientiert. Um diese die Aussage treffen zu können, müsstest Du alle möglichen Wege zwischen Dir und dem Empfänger prüfen, das sind exponentiell viele zu den möglichen Knoten innerhalb des Graphen, der das Netz darstellt. Praktisch ist es unmöglich alle Wege zu prüfen.

Die IP des Servers ist statisch. Da sollte also nicht das Problem liegen. Und Fehler sollen auch nur in dem lokalen Netz des Clienten gesucht werden.

Was nützt Dir eine statische IP !? Zwischen Dir und dieser IP gibt es mehrere Netze, in denen Fehler auftreten können.

Da muss sich doch was machen lassen. Wenn ich z.B. nen HTTP Paket losschicke ohne Proxy-Einstellungen dann müsste ich ein 407 zurückbekommen und weiß, dass ein Proxy vorhanden ist. Ähnlich müssten sich doch viele Sachen prüfen lassen.

Du wirst aber unter Umständen gar keine Antwort erhalten. Welchen Rückschluss kannst Du dann ziehen!?

Du kannst nicht aufgrund eines bestimmten Fehlers sagen, dass er nach Schema X zu beheben ist.