PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,224
- Punkte für Reaktionen
- 1,726
- Punkte
- 113
Wie bereits geschrieben ... die gezeigte Konfiguration setzt so viele Sachen voraus (angefangen mit der Tatsache, daß der Client auch tatsächlich die .20 verwendet, was man ja auch mit einem Paketmitschnitt und/oder den Support-Daten der 7390 erst einmal prüfen kann - von allen anderen Umständen (DHCP mit "immer dieselbe vergeben" oder statisch, usw.) weiß man bisher ja auch nichts), daß da so ziemlich überall der Wurm drin sein kann und nur eine systematische Fehlersuche wirklich erfolgsversprechend (fast fühle ich mich versucht, von "erfolgsgarantierend" zu schreiben, wenn nicht noch weitere "no-go"-Punkte ans Licht kommen) wäre.
Außerdem stand ja in #8 bereits (beim Zurückblättern habe ich #12 gerade das erste Mal zu Gesicht bekommen ... danke für die "Diagnose", meine Replik folgt später, wenn ich mehr Zeit habe, denn die steht gar nicht so im Überfluß zur Verfügung, wie in #12 gemutmaßt wird), daß man besser erst mal damit startet, tatsächlich sämtlichen Traffic der .20 durch den Tunnel zu schieben und dann kann man die Einträge immer noch "verfeinern".
Man kann beim Paketmitschnitt in der FRITZ!Box auf der "1. Internet-Verbindung" alles das sehen, was die Box tatsächlich in Richtung WAN verläßt und das muß dann ja irgendwie mit dem korrelieren, was den WAN-Stack der FRITZ!Box (das ist ja bekanntlich nicht der "normale" Linux-Stack) über die "Routing-Schnittstelle" betritt.
Wenn da auf der LAN-Seite tatsächlich Traffic mit passender Source-IP (und passendem Protokoll/Port, solange das auf TCP 80 und TCP 443 beschränkt ist ... was wäre eigentlich TCP 433 genau?) in den WAN-Stack kommt und ihn auf der anderen Seite auch unverschlüsselt wieder verläßt, stimmen die Selektoren wohl doch nicht ... aber das steht auch wieder alles (inkl. der SAs für die VPN-Verbindung) in den Support-Daten irgendwo bei der VPN-Diagnose und der Hinweis darauf steht wieder in den bereits erwähnten Threads, die ausführlich darauf eingehen, was man zur Diagnose bei Problemen alles bräuchte und was ein Fragesteller dazu selbst beitragen muß, denn nur er kommt i.d.R. an diese Protokolle und an dem notwendigen Mitschnitt.
Außerdem stand ja in #8 bereits (beim Zurückblättern habe ich #12 gerade das erste Mal zu Gesicht bekommen ... danke für die "Diagnose", meine Replik folgt später, wenn ich mehr Zeit habe, denn die steht gar nicht so im Überfluß zur Verfügung, wie in #12 gemutmaßt wird), daß man besser erst mal damit startet, tatsächlich sämtlichen Traffic der .20 durch den Tunnel zu schieben und dann kann man die Einträge immer noch "verfeinern".
Man kann beim Paketmitschnitt in der FRITZ!Box auf der "1. Internet-Verbindung" alles das sehen, was die Box tatsächlich in Richtung WAN verläßt und das muß dann ja irgendwie mit dem korrelieren, was den WAN-Stack der FRITZ!Box (das ist ja bekanntlich nicht der "normale" Linux-Stack) über die "Routing-Schnittstelle" betritt.
Wenn da auf der LAN-Seite tatsächlich Traffic mit passender Source-IP (und passendem Protokoll/Port, solange das auf TCP 80 und TCP 443 beschränkt ist ... was wäre eigentlich TCP 433 genau?) in den WAN-Stack kommt und ihn auf der anderen Seite auch unverschlüsselt wieder verläßt, stimmen die Selektoren wohl doch nicht ... aber das steht auch wieder alles (inkl. der SAs für die VPN-Verbindung) in den Support-Daten irgendwo bei der VPN-Diagnose und der Hinweis darauf steht wieder in den bereits erwähnten Threads, die ausführlich darauf eingehen, was man zur Diagnose bei Problemen alles bräuchte und was ein Fragesteller dazu selbst beitragen muß, denn nur er kommt i.d.R. an diese Protokolle und an dem notwendigen Mitschnitt.
