Matrixtunnel: VirtualIP vs. ar7.cfg

[Eagle3386]

Okay, mit "nnano" gings, danke!

Neues Problem ist jetzt, dass ich :65535 angebe, der dsld das auf :443 ummünzt, was dann von MatrixTunnel genommen und nach :81 geleitet wird - nur genau das passiert nicht, ich bekomme jetzt (nach Umstellung von 0.0.0.0:81 auf 0.0.0.0:443

No route to host

Und dein "cat FLASH > RAM" ging nicht - irgendwie logisch, aber ich dachte, es könnte ja doch eventuell.. unter bestimmten Umständen..

 

[RalfFriedl]

"cat FLASH > RAM" sollte funktionieren. Nur mit bestimmten Versionen von "cp" funktioniert das nicht.

 

[hermann72pb]

Und dein "cat FLASH > RAM" ging nicht - irgendwie logisch, aber ich dachte, es könnte ja doch eventuell.. unter bestimmten Umständen..

Ok, dann ausführlich eben...

cat /var/flash/ar7.cfg > /var/tmp/ar7.cfg
mcedit (nano, vi) /var/tmp/ar7.cfg
cat /var/tmp/ar7.cfg > /var/flash/ar7.cfg
rm /var/tmp/ar7.cfg

Aber wie oben erwähnt, machen das eigentlich alle N-Wrapper automatisch.

Edit: Alexander, kannst du bitte alle diese Beiträge angefangen von #410 zu einem Thread etwa "ar7.cfg schon wieder..." umschieften? Sonst vermüllen wir damit wieder das Hauptthread.

MfG

 

[kriegaex]

ar7cfgchanged ist in diesem Fall mit Kanonen auf Spatzen geschossen. Ich habe doch extra SIGHUP erwähnt, damit werden keine Verbindungen gekillt und Dienste neu gestartet.

 

[Eagle3386]

Sorry.. Werd's beim nächsten Mal beachten!

Apropos nächstes Mal: es geht selbst mit ar7.cfg-Port-Weiterleitung nicht.. MatrixTunnel weigert sich strikt, mir SSL-Inhalte zurückzuliefern.. Da steht jetzt immer da "No route to host" (siehe 21. Beitrag in diesem Thema)..

 

[hermann72pb]

Funktioniert es denn intern? Ich meine, wenn du vom internen Netz per https://192.168.178.1 (von mir aus noch mit :443 dahinter) zugreifst.
Wenn es der Fall ist, dann stimmt mit deiner ar7.cfg etwas nicht. Funktionieren denn die anderen Sachen wie ftp, dropbear, wenn du sie in ar7.cfg an der gleichen Stelle frei gibts?
ar7.cfg ist nämlich sehr empfindlich, was Syntaxis angeht. Wenn irgendeine Zeile (Regel) davor falsch ist, kann man nicht genau vorhersagen, ob die nachfolgenden Zeilen berücksichtigt werden.
Wenn es intern geht, poste uns bitte den Abschnitt mit den Regeln, wo du deine Zeile einträgst. Am besten noch 10-20 Zeilen davor und dahinter, und am besten als Datei.

MfG

 

[Eagle3386]

Ich habe vorhin erneut ein DS-Mod-Paket gebaut (siehe VMware-Einfrier-Thema) und das auf die Box als Firmware-Update (übers DS-Mod-Interface) gespielt..

Intern funktioniert's mit SSL reibungslos - kommt's von extern, sagt mir die Shell auf der Box das Folgende:

/var/mod/root $ matrixtunnel -f -D 4 -A matrix-key.pem -p matrix-key.pem -d 443 -r 80 -P /tmp/matrixssl.pid
SSL: Closing on protocol error 10
sslRead error in sslAccept
warn matrixtunnel.c:377 Error could not establish ssl connection

Meine ar7.cfg (betreffende Stelle, plus ca. 15 Zeilen davor / danach) sieht so aus:

                        highoutput {
                                policy = "permit";
                                accesslist =
                                             "reject ip any 242.0.0.0 255.0.0.0",
                                             "deny ip any host 255.255.255.255",
                                             "reject ip any 169.254.0.0 255.255.0.0",
                                             "reject udp any any eq 135",
                                             "reject tcp any any eq 135",
                                             "reject udp any any range 137 139",
                                             "reject tcp any any range 137 139",
                                             "reject udp any any range 161 162",
                                             "reject udp any any eq 520",
                                             "reject udp any any eq 111",
                                             "reject udp any any eq 22289",
                                             "reject udp any any eq 1710",
                                             "reject udp any any eq 1048",
                                             "reject udp any any eq 158",
                                             "reject udp any any eq 515",
                                             "reject icmp any 149.1.1.0 255.255.255.0";
                        }
                        forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
                                       "tcp 0.0.0.0:65535 0.0.0.0:443 0 # Fritz!Box",
                                       "tcp 0.0.0.0:65534 0.0.0.0:442 0 # DS-Mod",
                                       "tcp 0.0.0.0:22 0.0.0.0:22 0 # SSH",
                                       "tcp 0.0.0.0:33086 192.168.178.23:33086 0 # Transfers",
                                       "udp 0.0.0.0:20763 192.168.178.23:20763 0 # Transfers";
                        shaper = "globalshaper";
                }
        } {
                enabled = yes;
                name = "voip";
                dsl_encap = dslencap_inherit;
                dslinterfacename = "dsl";
                no_masquerading = no;
                no_firewall = no;
                pppoevlanauto = no;
                pppoevlanauto_startwithvlan = no;
                ppptarget = "voip";
                etherencapcfg {
                        use_dhcp = yes;
                        ipaddr = 0.0.0.0;
                        netmask = 0.0.0.0;
                        gateway = 0.0.0.0;
                        dns1 = 0.0.0.0;
                        dns2 = 0.0.0.0;
                        mtu = 0;
                }

Die Zeile für SSH funktioniert übrigens wunderbar, wenn ich über meine dynamische DNS-Adresse auf die Box zugreife..


[-EDIT-]

Hab's von 'nem Kumpel testen lassen - er bekommt 'ne weiße Website, sein Firefox wechselt aber in den SSL-Modus und meine Shell auf der Box zeigt mir:

/var/mod/root $ matrixtunnel -f -D 4 -A matrix-key.pem  -p matrix-key.pem -d 443 -r 80 -P /tmp/matrixssl.pid
SSL: Closing on protocol error 10
sslRead error in sslAccept
warn matrixtunnel.c:377 Error could not establish ssl connection
SSL: Closing on protocol error 10
sslRead error in sslAccept
warn matrixtunnel.c:377 Error could not establish ssl connection
select: Bad file descriptor
SSL: Closing on protocol error 47
sslRead error in sslAccept
warn matrixtunnel.c:377 Error could not establish ssl connection
SSL: Closing on protocol error 47
sslRead error in sslAccept
warn matrixtunnel.c:377 Error could not establish ssl connection
select: Bad file descriptor
select: Bad file descriptor
select: Bad file descriptor
sslRead error in sslAccept
warn matrixtunnel.c:377 Error could not establish ssl connection
SSL: Closing on protocol error 47
sslRead error in sslAccept
warn matrixtunnel.c:377 Error could not establish ssl connection
select: Bad file descriptor

 

[kriegaex]

Bei Zugriffen von außen wird bei AVM immer eine leere Seite angezeigt. Stichworte: Schutzmaßnahme, HTTP_REFERER, siehe Erläuterung und Workaround dort.

Abgesehen davon: Wieso leitest Du über so viele Ecken um, was soll das bringen? Mach es Dir nicht so schwer und versuch das in ar7.cfg:

...
"tcp 0.0.0.0:65535 0.0.0.0:65535 0 # Fritz!Box",
"tcp 0.0.0.0:65534 0.0.0.0:65534 0 # DS-Mod",
...

Und so würden Deine Tunnels aussehen:

matrixtunnel -A matrix-key.pem -p matrix-key.pem -d 65535 -r 80 -P /tmp/matrixssl-avm.pid
matrixtunnel -A matrix-key.pem -p matrix-key.pem -d 65534 -r 81 -P /tmp/matrixssl-dsmod.pid

Ungetestet, aber in der Hoffnung auf Vereinfachung und damit verbundenes Funktionieren.

 

[Eagle3386]

Hmm, das sind alles Workarounds - gibts keine (möglichst Box-seitige) Variante, um das ganz auszuschalten?

Okay, hab die ar7.cfg entsprechend angepasst und MatrixTunnel gestartet - kann's sein, dass die in /var/mod/root liegende matrix-key.pem nach 'nem Neustart gelöscht wird?

Es funktioniert übrigens nur teilweise - MatrixTunnel (mit "-f -D 4" gestartet) sagt mehrfach

select: Bad file descriptor

und die Oberfläche an sich sieht so aus wie im angehängten Screenshot - lokal aufgerufen ist jedoch die Anzeige korrekt!?! :noidea:

 

[kriegaex]

Hmm, das sind alles Workarounds - gibts keine (möglichst Box-seitige) Variante, um das ganz auszuschalten?

Gibt es meines Wissens nicht, denn die Prüfung ist fest in AVM-Binaries verbaut, zu denen wir keinen Quellcode haben.

kann's sein, dass die in /var/mod/root liegende matrix-key.pem nach 'nem Neustart gelöscht wird?

Ja, das ist so, denn /var ist eine RAM-Disk. Du müßtest also dafür sorgen, daß die Datei aus debug.cfg oder rc.custom heraus beim Booten erzeugt wird. Alternativ kannst Du unter /var/tmp/flash die Datei anlegen und dann mit modsave speichern, dann ist sie nach dem Neustart da, sobald die DS-Mod-Initialisierung abgeschlossen ist.

Es funktioniert übrigens nur teilweise - MatrixTunnel (mit "-f -D 4" gestartet) sagt mehrfach und die Oberfläche an sich sieht so aus wie im angehängten Screenshot - lokal aufgerufen ist jedoch die Anzeige korrekt!?! :noidea:

Der Tunnel ist langsamer als der lokale Aufruf, da kann schon mal ein Bildchen fehlen oder erst später angezeigt werden wegen Timeout. Ob es spezielle Probleme mit Orange!Box gibt, die ich nicht verwende, ist mir nicht bekannt. Evtl. wird dort der Referer irgendwo abgefragt, wie es z.B. auch bei den in die AVM-Oberfläche eingebauten Links zu DS-Mod und WoL der Fall ist. Diese Links funktionieren dann mit Deiner speziellen Konfiguration nicht, aber das sollte leicht zu verschmerzen sein, da Du ja sowieso einen Extra-Tunnel für DS-Mod hast.

 

[cokejunkie]

@Eagle: Es ist bekannt, daß VirtualIP nicht so mag mit VPN, evtl. betrifft das auch MatrixSSL, also bitte sei doch so lieb und teste, wie von mir vorgeschlagen, ohne VirtualIP, stattdessen mit manueller Portfreigabe über ar7.cfg.

Das VirtualIp nicht mit OpenVPN klar kommt, lag bei mir daran, dass es NACH openvpn gestartet wird, sodass OpenVPN nicht auf die addresse binden kann.

da beide dienste als S40* in die .static bzw. /etc/static.pkg eingetragen werden, also _o_penvpn vor _v_irtualip gestartet wird. das gleiche dürfte auch auf _m_atrixssl zutreffen.

deswegen habe ich, nach einigem suchen, die datei "make/virtualip-cgi/virtualip-cgi.mk" bearbeitet:
zeile 33:
aus
@echo "S40virtualip-cgi-$(VIRTUALIP_CGI_VERSION)" >> .static
wird
@echo "S10virtualip-cgi-$(VIRTUALIP_CGI_VERSION)" >> .static

und nach einem update funktioniert nun auch mein openvpn, ohne die ar7.cfg zu bearbeiten.
( nur nebenbei: ich nutze auch brctl, um die openvpn tap devices schnell hinzuzufügen und das stp einzuschalten, bevorzuge sowas eindeutig vor dem bearbeiten der ar7.cfg )

ich hab hier im forum eigentlich nur dinge gelesen, die mich interessiert haben ( brctl, knfsd, einführung ), deswegen kann ich es nicht einschätzen. aber eigentlich dürfte es aufgrund des späten startens ( bei mir wird nur noch wol danach geladen ) häufiger zu problemen kommen, wenn services vorher starten, die auf ein noch nicht vorhandenes interface binden wollen.

ps: vielen dank an alle, die hier mitarbeiten und das dsmod ermöglichen!

 

[kriegaex]

Guter Hinweis, danke.

 

[bofh]

@kriegaex nehmt ihr die /etc/static.pkg aenderung von cokejunkie mit in den naechsten ds-mod auf?

gruss
bofh

 

[olistudent]

Wir werden uns die Startreihenfolge mal genauer anschauen.

MfG Oliver

 

[hermann72pb]

Das Thema hatten wir schon hier mit meinem Downloader. Wie Oliver schon richtig sagte, man soll es genauer anschauen. Denn alleine S-Level auf 10 zu ändern könnte zwar reichen, müsste aber nicht. Es gibt durchaus Pakete, die noch vor static.pkg aufgerufen werden. Es bleibt zu klären, ob sie mit VirtualIP dadurch immer noch im Konflikt stehen. Und es ist außerdem zu klären, ob die Lösung wirklich alle Probleme mit VirtualIP löst.
Grundsätzlich ist jedoch die Idee richtig. Und es würde nichts dagegen sprechen den Vorschlag erstmal in die nächste Version aufzunehmen. Schlechter sollte es dadurch nicht werden.

 

[algarvinho]

matrixtunnel, rudi-shell, portforwarding

Ich hänge mich mal hier an, obwohl ich keinen ds-mod einsetze.

Versuche schon seit einiger Zeit die rudi-shell + das Web-Interface der Fritz von "außen" per matrixtunnel (s.u.) zu erreichen.
Entsprechende debug.cfg, Nachladen vom Webserver + Anpassung der ar7.cfg (Portfreigaben s.u.) sind gemacht.
Web-Interface habe ich nun sowohl intern als auch extern hinbekommen.

Mit der rudi-shell hapert's allerdings noch... Der interne Zugriff über "https://192.168.178.1:12345" funktioniert schon nicht (=> url not found (404)).
Woran könnte das liegen? (httpd läuft auf Port 81)

Außerdem noch eine Verständnisfrage: der für den Matrixtunnel verwendete Key dient rein der Verschlüsselung des Tunnel und nicht der Authentifizierung, oder? Das heißt, wenn ich über xxx.dyndns.xxx (oder xxx.dyndns.xxx:12345) auf die Box zugreife muß kein Kennwort eingegeben werden, ich lande sofort auf der Web-Oberfläche (okay, hier Admi-Kennwort erforderlich) bzw. auf der rudi-shell?

...
"tcp 0.0.0.0:443 0.0.0.0:443 0 # Fritz!Box",
"tcp 0.0.0.0:12345 0.0.0.0:12345 0 # rudi-shell",
...

matrixtunnel -A matrix-key.pem -p matrix-key.pem -d 443 -r 80 -P /tmp/matrixssl-avm.pid
matrixtunnel -A matrix-key.pem -p matrix-key.pem -d 12345 -r 81 -P /tmp/matrixssl-rudi.pid

 

[kriegaex]

Wie hast Du denn die Rudi-Shell ohne DS-Mod installiert? Das geht, ich weiß da, schließlich habe ich sie entwickelt. Aber wissen möchte ich es trotzdem, damit ich Dir helfen kann. Duch welche URL genau erreichst Du sie denn ohne Matrixtunnel von innen?

Deine Vermutung bzgl. Zertifikat und Matrixtunnel ist richtig, aber das steht bereits im Wiki. Schon gelesen?

 

[RalfFriedl]

Außerdem noch eine Verständnisfrage: der für den Matrixtunnel verwendete Key dient rein der Verschlüsselung des Tunnel und nicht der Authentifizierung, oder?

Der Key (matrix-key.pem) beim Matrixtunnel, oder allgemein bei jedem SSL-Server dient nicht der Verschlüsselung, sondern der Authentifizierung des Servers, nicht des Clients. Die Verschlüsselung wäre genauso gut möglich ohne diesen Key, allerdings ist im allgemeinen Fall eine Verschlüsselung ohne diesen Key nicht sinnvoll, da sie nicht vor einem Man-in-the-Middle (MiM) Angriff schützt. Oder anders ausgedrückt, es reicht nicht, die Kommunikation zu verschlüsseln, man muß auch wissen, mit wem man spricht.

Ohne diesen Key könnte jemand (der MiM) die Verbindung abfangen. Der Client würde eine verschlüsselte Verbindung zum MiM aufbauen, ohne es zu merken. Der MiM würde ebenfalls eine verschlüsselte Verbindung zum Server aufbauen. Alle gesendeten und empfangenen Daten wären für den MiM im Klartext sichtbar.

 

[kriegaex]

Das ist korrekt, ich wollte es nur nicht so technich ausführlich erklären...

 

[algarvinho]

Yep - Wiki gelesen....mehrfach, weil's ja nicht von Anfang an geklappt hat Aber durch die technische Erklärung und nochmaliges Nachdenken darüber, hab ich's nun verstanden - Danke!

Installation der Rudi-Shell ohne Mod (s.a. Auszug der debug.cfg):
- busybox + haserl per wget nach /var/tmp geladen + ausführbar
- in rudi-cgi's Pfad zu Haserl (var/tmp/haserl) angepasst
- rudi-cgi's per wget nach /var/tmp/rudi/cgi-bin + ausführbar
- symlinks für vi, head, wc + httpd
- httpd auf port 81 gestartet

Von "innen" erreichbar über http://fritz.box:81/cgi-bin/rudi_shell.cgi
Müßte der ssl-Aufruf also: https://fritz.box:12345/cgi-bin/rudi_shell.cgi sein?

########### Auszug debug.cfg ##########
serverurl="www.XXXXX.de"        # Nachlade-Adresse
localdir="/var/tmp"             # hierher wird nachgeladen
rudidir="/var/tmp/rudi/cgi-bin" # hier liegen die rudi-Skripte

while !(ping -c 1 $serverurl); do       # Server da?
sleep 5
done

cd $localdir                    # ab nach /var/tmp
wget http://$serverurl/busybox
wget http://$serverurl/haserl   # shell fuer rudi
wget http://$serverurl/setforw.sh       # Portforwarding
chmod +x ./haserl               # ausfuehrbar
chmod +x ./busybox
chmod +x ./setforw.sh
                                # Symlinks f. dir. Aufruf
ln -s $localdir/busybox vi
ln -s $localdir/busybox httpd
ln -s $localdir/busybox head    # fuer rudi
ln -s $localdir/busybox wc
ln -s /var/flash/calllog /var/calllog # woc

PATH=$PATH:/var/tmp
LD_LIBRARY_PATH=/var/tmp/lib
export PATH LD_LIBRARY_PATH
                                ### hier kommt Rudi
mkdir -p rudi/cgi-bin           # Verzeichnis anlegen
cd $rudidir                     # ab nach /var/tmp/rudi/cgi-bin
wget http://$serverurl/rudi_shell.cgi
wget http://$serverurl/rudi_shellcmd.cgi
wget http://$serverurl/rudi_upload.cgi
chmod +x ./rudi*                # soll ausfuehrbar sein

cd $localdir
./httpd -p 81 -h /var/tmp/rudi # Start httpd a Port 81

##### HTTPS-Zugriff ######
mkdir lib                       # fuer SSL-Libary
cd $localdir/lib                # nach /var/tmp/lib
wget http://$serverurl/libmatrixssl.so
chmod +x ./libmatrixssl.so

cd $localdir
mkdir sbin                      # fuer SSL-Tunnel
cd $localdir/sbin               # nach /var/tmp/sbin
wget http://$serverurl/matrixtunnel
chmod +x ./matrixtunnel

        #### SSL-Key ablegen in $localdir/sbin
cat << EOF_CERT > /var/tmp/sbin/sslkey.pem
....
EOF_CERT
        #### SSL-Tunnel ####
./matrixtunnel -A ./sslkey.pem -p ./sslkey.pem -d 12345 -r 81 -P $localdir/sbin/matrixssl_rudi.pid
./matrixtunnel -A ./sslkey.pem -p ./sslkey.pem -d 443 -r 80 -P $localdir/sbin/matrixssl_avm.pid