[Gelöst] LAN-LAN-Koppelung mit nur 1 öffentlichen IP

[Riverhopper]

Capture auf der Box in Datei auf USB-Speicher:

QUERY_STRING=sid=sid\&capture=Start\&snaplen=1600\&minor=minor REMOTE_ADDR=127.0.0.1 REQUEST_METHOD=GET /usr/www/cgi-bin/capture_notimeout >/var/media/ftp/path/capture.pcap

Hallo PeterPawn,
ich habe gerade den capture-Befehl aus #48 auf FB7490-06.36-31540 testen wollen, leider hat dies irgendwie nicht funktioniert.

# msgsend ctlmgr sessions
# sleep 2
# sed -ne "s/^\([a-f0-9]*\) *\([0-9]*\) *\([0-9]*\) *\([A-Za-z0-9]\)* \([0-9.]*\) *\([^ ]*\) .*BoxAdmin:RW.*$/sid=\1 valid=\2 uid=\3 source=\4 ip=\5 user=\6/p" /var/tmp/sessions.txt
sid=92a927d3966bd617 valid=2264 uid=13 source=t ip=192.168.1.109 user=admin
#



# QUERY_STRING=sid=92a927d3966bd617&capture=Start&snaplen=1600&ifaceorminor=1-lan REMOTE_ADDR=127.0.0.1 REQUEST_METHOD=GET /usr/www/cgi-bin/capture_notimeout
[3]+  Done                       ▒* ▒\(▒[0▒-9.▒]▒*▒\) ▒*▒\(▒[^ ▒]▒*▒\) .L
[2]+  Done                       ▒* ▒\(▒[0▒-9.▒]▒*▒\) ▒*▒\(▒[^ ▒]▒*▒\) .L
[1]+  Done                       ▒* ▒\(▒[0▒-9.▒]▒*▒\) ▒*▒\(▒[^ ▒]▒*▒\) .L
#

# QUERY_STRING=sid=92a927d3966bd617&capture=Start&snaplen=1600&ifaceorminor=1-lan REMOTE_ADDR=127.0.0.1 REQUEST_METHOD=GET /usr/www/cgi-bin/capture_notimeout > /var/media/ftp/capture.pcap
[3]+  Done                       /usr/www/cgi-bin/capture_notimeout
[2]+  Done                       /usr/www/cgi-bin/capture_notimeout
[1]+  Done                       /usr/www/cgi-bin/capture_notimeout
#

# ls -la /var/media/ftp/capture.pcap
-rw-r--r--    1 root     root             0 Oct 18 11:38 /var/media/ftp/capture.pcap
#

Auch habe ich Probleme mit queries.lua:

Stoppen kann man das dann auch wieder - entweder selektiv (z.B. mit
"echo sessions=capture:settings/session/list\(displayname,ifacename,minor,type\) | queries.lua"
die richtige Capture-Session finden

# msgsend ctlmgr sessions
# sleep 2
# echo sessions=capture:settings/session/list\(displayname,ifacename,minor,type\) | ./queries.lua
sessions_count=0

Frage: Mache ich hier etwas falsch ? oder liegt es an der Umstellung von webcm auf "responsive Design" seitens AVM ?

Any help welcome.

LG
Riverhopper

Edit: Text korrigiert

 

[PeterPawn]

Ich nehme mal an, die Session-Verwaltung hat AVM bei der 06.35+ ebenfalls umgekrempelt. "queries.lua" an sich sollte noch funktionieren (ggf. eben nicht mit der Session-Liste testen), probiere ich aber auch nicht mit jeder neuen Labor-Version. Da das von einem CS-Programm abhängt, könnte AVM da einen Strich durch die Rechnung machen, wäre aber m.E. nur absichtlich und nicht versehentlich möglich. Extra für einen eigenen Test auf Labor umzuschalten, habe ich gerade keinen Bock ... sorry. Den "Basistest" z.B. mit dem WLAN-Key oder irgendeinem anderen Wert aus dem Beitrag zu "queries.lua" kriegst Du sicherlich selbst hin.

Wie das mit der neuen Session-Verwaltung jetzt genau läuft, weiß ich auch noch nicht ... ich nehme mich der Untersuchung solcher Interna erst dann an, wenn es spezielle Fragen zu klären gibt oder die Firmware "stabil" ist. Beides ist hier - in meinen Augen - noch nicht der Fall.

Ob der ctlmgr immer noch mit einem "msgsend" zur Ausgabe der aktuellen Session-Liste bewegt werden kann (und viel wichtiger, ob man die immer noch "hijacken" kann), mußt Du eben durch einzelnes Ausführen der Kommandos ermitteln. Es muß ja nicht gleich das automatische Extrahieren der SID durch die Verwendung von "sed" sein, wenn Du das auch "von Hand" aus der erzeugten Ausgabedatei in /var/tmp (wenn es die überhaupt noch gibt) abschreiben kannst.

Nach der Ausgabe der queries.lua für die Session-Liste zu urteilen, verwendet AVM entweder einen anderen Mechanismus oder es gab zu diesem Zeitpunkt keine Session über das GUI oder über TR-064 ... dann wäre die Ausgabe ja wieder korrekt. Die Ermittlung der SID war auch nur ein Beispiel, man kann natürlich genauso auch eine neue Sitzung erzeugen, wenn man den "Login-Mechanismus" der FRITZ!Box für das GUI nachbildet, wozu es genug Beispiele (z.B. das PHP-API als fertige Klasse) gibt.

Wenn ich jetzt nachträglich noch einmal versuche, die Ausgabe der Befehle zu verstehen, dann drängt sich mir der Verdacht auf, daß Du da lediglich das Maskieren der "&"-Zeichen in der QueryString verbastelt hast, was dann natürlich zu einer Interpretation dieser Zeichen seitens der Shell führt ... beim ersten Anlauf findet das sed-Kommando ja offenbar noch etwas in der Datei mit den Session-Daten, wie man anhand der SID sieht. Es kann also auch sein, daß der ctlmgr die Sessions nicht mehr in der über die queries.lua abgefragten Auflistung verwaltet, aber auch das muß man testen ... es kann genauso gut sein, daß da wegen eines Aufrufs mit falschen Credentials diese Session seitens der FRITZ!Box beendet wurde und es schon war, als Du das Kommando mit der queries.lua probiert hast.

EDIT: Wie ich jetzt erst richtig realisiert habe, versuchst Du ja mit einer Session-ID für die IP-Adresse 192.168.1.109 zu arbeiten und gibst aber gleichzeitig als "REMOTE_ADDR" die 127.0.0.1 an. Das führt natürlich dazu, daß die FRITZ!Box ihrerseits der Meinung ist, da würde jemand von der 127.0.0.1 aus diese SID mißbrauchen und dann schmeißt sie alle Sitzungen für diese IP-Adresse weg (steht so sicherlich auch im Eventlog der Box).

EDIT2: Ich erspare Dir die Aufnahme in die Spaßecke für das "responistive Design" ... aber korrigiere das besser noch, sonst liest es jemand anderes und "catcht" Dich an meiner Stelle.

 

[Riverhopper]

Wie ich ... realisiert habe, versuchst Du ja mit einer Session-ID für die IP-Adresse 192.168.1.109 zu arbeiten und gibst aber gleichzeitig als "REMOTE_ADDR" die 127.0.0.1 an. Das führt natürlich dazu, daß die FRITZ!Box ihrerseits der Meinung ist, da würde jemand von der 127.0.0.1 aus diese SID mißbrauchen und dann schmeißt sie alle Sitzungen für diese IP-Adresse weg (steht so sicherlich auch im Eventlog der Box).

Hallo PeterPawn,
Du hast Recht!!!

FB-Eventlog:
18.10.15  17:13:03    Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 127.0.0.1 gescheitert (ungültige Sitzungskennung). Zur Sicherheit werden alle noch gültigen Sitzungen zur IP-Adresse 127.0.0.1 beendet. [3 Meldungen seit 18.10.15 17:09:49]

# msgsend ctlmgr sessions

# sleep 2

# cat /var/tmp/sessions.txt
sid                     valid userid source   ip              name rights
-------------------------------------------------------------
5b931da0b38fa2b4         3402 13      Homenet 192.168.1.109   admin BoxAdmin:RW App:RW NAS:RW Phone:RW Dial:RW HomeAuto:RW

# sed -ne "s/^\([a-f0-9]*\) *\([0-9]*\) *\([0-9]*\) *\([A-Za-z0-9]\)* \([0-9.]*\) *\([^ ]*\) .*BoxAdmin:RW.*$/sid=\1 valid=\2 uid=\3 source=\4 ip=\5 user=\6/p" /var/tmp/sessions.txt
sid=5b931da0b38fa2b4 valid=3402 uid=13 source=t ip=192.168.1.109 user=admin

# QUERY_STRING=sid=5b931da0b38fa2b4\&capture=Start\&snaplen=1600\&ifaceorminor=1-lan REMOTE_ADDR=192.168.1.109 REQUEST_METHOD=GET /usr/www/cgi-bin/capture_notimeout > /var/media/ftp/capture.pcap

# ps | grep -v grep | grep capture_notimeout
29128 root      4264 S <  /usr/www/cgi-bin/capture_notimeout
#

# ls -la /var/media/ftp/capture.pcap
-rw-r--r--    1 root     root        577298 Oct 18 17:19 /var/media/ftp/capture.pcap
#

Nun funktioniert es.
Vielen Dank für Deine Hilfe!!!

Riverhopper

 

[PeterPawn]

Glückwunsch ... trotzdem noch die Bemerkung, daß das NAND-FS der denkbar ungünstigste Speicherort für solche Mitschnitte ist - da ist jeder USB-Stick besser geeignet. Erstens ist der Platz im NAND sehr beschränkt (lahm ist das auch noch) und zweitens kannst Du einen durch zu häufige Schreibzugriffe "verschlissenen" USB-Stick leicht ersetzen, beim internen NAND der 7490 braucht das mindestens einen Lötkolben (und jede Menge Aufwand).

EDIT: Ich sehe gerade noch, daß da im regulären Ausdruck für das "sed" ein Fehler ist ... "Homenet" wird auf "t" verkürzt, da der Stern im vierten Ausdruck in die Klammer gehört, statt

eval $(sed -ne "s/^\([a-f0-9]*\) *\([0-9]*\) *\([0-9]*\) *\([A-Za-z0-9]\)* \([0-9.]*\) *\([^ ]*\) .*BoxAdmin:RW.*$/sid=\1 valid=\2 uid=\3 source=\4 ip=\5 user=\6/p" /var/tmp/sessions.txt)

muß es in #48 also

eval $(sed -ne "s/^\([a-f0-9]*\) *\([0-9]*\) *\([0-9]*\) *\([A-Za-z0-9][COLOR="#FF0000"]*[/COLOR]\) \([0-9.]*\) *\([^ ]*\) .*BoxAdmin:RW.*$/sid=\1 valid=\2 uid=\3 source=\4 ip=\5 user=\6/p" /var/tmp/sessions.txt)

lauten. Habe ich korrigiert ... spielte zwar keine Rolle, aber macht mich trotzdem "wuschig", wenn so etwas durchrutscht.

 

[Riverhopper]

Hallo PeterPawn,
Danke für Feedback/Erinnerung zu NAND-Feature "endlichen Anzahl an Schreibzyklen";
da es hier nur um PoC geht, sollte es kein Problem sein.

ein Punkt ist mir bzgl. capture_notimeout noch unklar:
Kann man neben den Standard-Netdevices (lan, eth0, eth1, eth2, eth3, ath0, wlan, wifi0, wifi1, wasp, tunl0, ptm_vr9)
auch andere VirtualNetDev aus AVM PacketAccelerator wie 'voip, ...' als Argument bei capture_notimeout angeben ?
im Web-IF habe ich diese nicht gefunden.

Auszug aus altem avm_pa.c
 * Examples:
 *   ATA Mode:
 *      Name      NetDev  VirtualNetDev  PID    VPID
 *      cpmac0    yes     no             yes    yes (cpmac0)
 *      eth0      yes     no             no     yes (cpmac0)
 *      ath0      yes     no             yes    yes (ath0)
 *      internet  no      yes            no     yes (cpmac0)
 *      voip      no      yes            no     yes (cpmac0)
 *   DSL Mode (one PVCs):
 *      Name      NetDev  VirtualNetDev  PID    VPID
 *      cpmac0    yes     no             yes    yes (cpmac0)
 *      eth0      yes     no             no     yes (cpmac0)
 *      ath0      yes     no             yes    yes (ath0)
 *      vcc0      no      yes            yes    yes (vcc0)
 *      internet  no      yes            no     yes (vcc0)
 *      voip      no      yes            no     yes (vcc0)

LG
Riverhopper

 

[PeterPawn]

im Web-IF habe ich diese nicht gefunden.

Wenn die vorhanden sind (Deine Box läuft nicht etwa im LAN1-Modus im Moment?), sollten diese auf nutzbar sein:
Anhang anzeigen 84137
"1. Internetverbindung" sind (ggf. "wieder", je nachdem aus welcher Richtung man draufsieht) alle gemeinsam, danach kommen dann die "funktionellen Interfaces" (bei mir "internet" und "mstv", da würde "voip" (ggf. auch als "voip+tr(0?)69" bei einigen Anbietern) auch dazugehören) und die "Routing-Schnittstelle" ist dann "dev dsl", also das "boxseitige Interface" des WAN-Stacks, was bei "acceleration" dann übergangen wird.

Ob das bei der 06.36 auch noch so ist oder ob AVM hier eine neue Schutzwand hochziehen würde (wie sollte das aber gehen, wenn es in einer Konfiguration gar kein zweites Interface - oder noch mehr - gibt), weiß ich nicht ... ich vermute mal, Deine Box ist da nicht im richtigen Modus, damit die anderen Interfaces auch existieren. Wie sehr das von Anbieter zu Anbieter differieren kann, sieht man schön in der "providers-049.tar", in der internationalen Version dann mit noch mehr Möglichkeiten. Es gibt eben auch Anbieter, wo das gesamte TR-069 sogar über ein gesondertes Interface abgewickelt wird, jedenfalls lassen entsprechende Konfigurationsschnipsel für die ar7.cfg bei solchen Providern (in der erwähnten Datei) das als wahrscheinlich erscheinen.

 

[nico2000]

Hallo,
ich stehe gerade vor dem gleichen Problem und bin auf diesen Eintrag gestoßen.
Ich habe folgende Infrastruktur:
- FritzBox 7490, 192.168.178.0/24, DSL mit öffentlicher IP (MyFritz DDNS)
- FritzBox 4020, 192.168.177.0/24, hinter NAT LTE-Router Huawei B315 (192.168.176.0/24) im Vodafone Mobilfunknetz (no-ip DDNS)
Ich würde gerne ein Site-to-Site VPN zwischen den FritzBoxen einrichten.
Ich habe mal versucht er Anleitung oben zu folgen und habe bisher folgendes gemacht:
- Über FritzFernzugang die Config-Dateien für die Router erstellt
- Config-Datei 7490: Änderung remotehostname = "";
- Config-Datei 4020: Hinzugefügt keepalive_ip = "192.168.178.1";

So wie ich das in der Anleitung hier verstanden habe sollte es eigentlich gehen... Leider bleiben die Buttons grau und es kommt keine VPN-Verbindung zu stande.

Ich würde mich sehr um eure Hilfe freuen.

 

[Shirocco88]

Ich würde mich sehr um eure Hilfe freuen.

@nico2000
siehe: https://www.ip-phone-forum.de/threa...z-boxen-eine-mit-ds-lite.283359/#post-2138398

 

[nico2000]

Danke für die schnelle Antwort.
Ich habe das gerade nochmal so wie in dem Beitrag beschrieben gemacht und die Config-Dateien geändert und neu importiert. Leider keine Veränderung.
Mir ist noch aufgefallen, dass die 4020 (Initiator) bei Adresse im Internet die 255.255.255.255 im Bereich VPN anzeigt. Kann sie den verwendeten Hostnamen von der 7490 nicht auflösen? Oder müssen ggf. im LTE-Router noch irgendwelche Ports weitergeleitet/freigegeben werden?

 

[PeterPawn]

Tja, die "accesslist" in der 4020 sieht ja auch irgendwie witzig aus, finde ich jedenfalls:

                phase2localid {
                        ipnet {
                                ipaddr = 192.168.177.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.179.0 255.255.255.0";

 

[Shirocco88]

ja, da wäre 192.168.178.0 sinnhaftiger.

FB4020_vpn.cfg

accesslist = "permit ip any 192.168.178.0 255.255.255.0"

Anmerkung: bei VPN via Mobilfunk (CGNAT) ist es wichtig, dass die Internet-Verbindung nicht durch vorgelagerten NAT-Router (HUAWEI) ins Timeout läuft, da hier der VPN-Tunnel der Fritzbox sonst in "Streß-situation" gerät, wenn die NAT-Session am Huawei-Router terminiert ist und VPN-Traffic übertragen werden soll.

 

[nico2000]

Tja, die "accesslist" in der 4020 sieht ja auch irgendwie witzig aus, finde ich jedenfalls:
... Vollzitat entfernt by stoney

Oh, ja stimmt da ist ja was total durcheinander gekommen...
Die .179 muss eigentlich durch die .178 ersetzt werden
Habe das gerade mal gemacht und neu importiert, jetzt klappt es
Vielen Dank!

 

[Shirocco88]

@nico2000
Bitte nicht vergessen, den DDNS-/MyFritz-Hostname und den Key aus der vpn.cfg #69 herauszunehmen und den Key nochmals ändern.

das Tool Fritz!Fernzugang hat die Eigenschaften im absoluten Dateinamen den DynDNS-Name zu verdrahten.

 

[nico2000]

Mach ich, danke für den Tipp @Shirocco88