Packete verschwinden!

[mbo]

moin moin,

Suse 6.1/2/3
Masq on
IP-Forw on
Routing on
ipchains allow

über anderthalb Jahre lief dieser rechner bestens, folgte seinem auftrag, gewissenhaft und
zuverlässig die internetanbindung zu realisieren ... bis gestern

[status]
einwahl beim provider, route wird gesetzt, masq läuft
alle clients ( unter linux & win) haben ihren eigenen dns-eintrag
vom server: kann ich alles machen
von den clients:
gehen nur pings innerhalb des netzes, extern kommen keine antworten
http und ftp sehr stark eingeschränkt -> mit namen nichts, mit IP-Addr nur die server, die
auch direkt im dns eingetragen sind (also ohne virt. server bzw. aliase), bei
portangaben wird ein connect & teilweise login verzeichnet, aber kommen nur unvollständige
packete an.

oki, im ethernet kann ich die packete ja kontrollieren. welche möglichkeiten haben ich denn,
auf einem isdn-interface zu sniffen?

ich habe gestern eigentlich alles gecheckt. fällt irgendjemand noch etwas ein?


cu/2 iae

[rbla]

> <em> oki, im ethernet kann ich die packete ja kontrollieren. welche möglichkeiten haben ich denn, auf einem isdn-interface zu sniffen?</em>

tcpdump -i ippp0

[jkaiser]

Also zunächst mal fallen mir, meiner Meinung nach geeignetere Methoden/Tools zur Fehlersuche ein:
- Logfiles (Client- und Serverseitig)
- Logging-Rules in der Firewall-Regeln!
- Testen einzelner Basiskomponenten um der Fehler einzukreisen:
+ von Hand einwählen und mittels ifconfig alle Interfaces kontrollieren
+ ping auf externe IP-Adresse (nicht Hostnamen)
+ nslookup (DNS testen)
+ Firewall-Regelwerk überprüfen (was heißt bei dir ipchains allow? Alle Default-Policies auf ACCEPT und sonst keine Regeln?)

Wenn sich der Server einwählt, dann wird das bisherige Interface ippp0 gelöscht und ein neuen (mit der neuen IP) angelegt (+ Host-Route + ggf Default-Route). Das mag tcpdump wohl nicht! Ich habe von einem Patch für tcpdump für ISDN gelesen, genaueres weiß ich jedoch nicht darüber! Während einer Online-Verbindung tcpdump starten, sollte wohl gehen!
Der Vorteil der Loggingregeln ist, dass du besser kontrollieren kannst (oder zumindest mit weniger Aufwand!) und somit deine Infos nicht zwischen so vielem Rauschen suchen mußt (in diesem Fall wohl nicht so schlimm)!
Außerdem interessiert sich ipchains nicht dafür, ob ein Interface, auf das sich eine Regel bezieht schon da ist, es zwischendurch mal verschwindet (oder für immer), ... , sollte mal ein Paket über dieses Interface gehen, so schlägt es zu!

ABER, wenns teilweise doch funktioniert, manchmal hat der ein oder andere Provider auch so seine Schwierigkeiten! Wenn euer Server keine Änderung erfahren hat und bisher tadellos funktioniert hat, dann liegt dieser Verdacht nahe! Ein bis zwei Tage später sollte es dann wieder gehen! Falls es dringend ist, erstmal telefonisch beim Provider nachhaken. Ansonsten suchst du dir einen Wolf, plötzlich geht es wieder (dank des Providers) und du bist kein bischen schlauer (allenfalls deine Maschine struwellig, wegen try-and-error!).

Viel Erfolg!
Gruß, Jens

[mbo]

lso zunächst mal fallen mir, meiner Meinung nach geeignetere Methoden/Tools zur Fehlersuche ein:
- Logfiles (Client- und Serverseitig)
- Logging-Rules in der Firewall-Regeln!
- Testen einzelner Basiskomponenten um der Fehler einzukreisen:
+ von Hand einwählen und mittels ifconfig alle Interfaces kontrollieren
+ ping auf externe IP-Adresse (nicht Hostnamen)

bis dahin ist alles erledigt, schon gestern ;-)

ja, ipchains policy sind vollständig auf accept ... das masq ist eingeschaltet.

nslookup kann ich nicht von den clients machen, da keine antwort der dns-server kommt.
deswegen wollt ich ja am ippp0 sniffen, um zu sehen, ob da überhaupt was zurückkommt. tcpdump -i ippp0 sagt er ... äh ... jedenfalls mag er das interface nicht :-(

nslookup auf die ip's von den clients aus, bringt das gleiche.

mach ich über browser ein request auf einen server per ip, geht es so lange gut, bis diese server mit aliase, virtuellen server, portforwarding etc. arbeiten ... und das sind heutzutage ja fast alle ... wie schon oben erwähnt ... schlimmer noch: alle sehen mich, wenn ich connecte, aber ich bekomme keine antworten!

ergo: alle anfragen gehen raus, aber die antworten kommen nicht an. um zu sehen, ob sie auf dem server ankommen, von dort aber nicht weitergehen, bräucht ich ein sniffer, der auf dem ippp0 horcht.

an provider dacht ich zuerst auch, aber die tatsache, das vom server alles geht, schließt diese fehlerquelle aus ;-)

einzige möglichkeit bliebe nur noch das masq, aber warum funktioniert es mal und mal net (virtuelle server etc)?

grübelt noch jemand?

cu/2 iae

ps: da ich aber sowieso n version gemisch von suse 6.1 6.2 und 6.3 und ich redhat bedeutend besser kenne und mag ;-), werd ich sowieso um-installieren ... ärgert mich nur ... schöne uptime totgemacht *hmpf*
nichts destotrotz interessiert mich die lösung brennend ... zumindest ideen dazu