Matrixtunnel: VirtualIP vs. ar7.cfg

Eagle3386 · 18 Sep 2007

kriegaex: verschoben aus Thread zu ds26-15.2

kriegaex schrieb:
So, Ihr hattet ja ein paar Tage Ruhe vor mir (Dienstreise) und mich sicher nicht vermißt. Hier bin ich also wieder.

[...]

@Eagle: Ich verwende dieses Virtual-IP-Zeug nicht. Leg Dir ein Port-Forwarding direkt über ar7.cfg an und schau, ob es dann geht mit Matrixtunnel. Ich hatte nie ein Problem damit.

DHCP muß man übrigens nicht deaktivieren, um feste IPs verwenden zu können. Ich tue das auch, allerdings mit multid, dnsmasq habe ich nie probiert.

[...]

Verschwundene Kompetenz wird *immer* vermisst..

Virtual-IP funktioniert super - du hattest mir damals in http://www.ip-phone-forum.de/showthread.php?t=139314 geholfen (sowohl mit MatrixTunnel, als auch mit einem persönlichen Problem zwischen uns beiden, was mir noch immer sehr Leid tut..), aber obwohl ich das Thema und auch das Wiki studiert und alles exakt nach Anleitung gemacht habe, weigert sich MatrixTunnel immer noch stur, SSL bei externen Anfragen auszuwerfen..

Komischerweise bekommt der Laptop aber auch ohne Deaktivierung keine IP, d. h. er bekommt schon eine, wenn ich statt

Code:

192.168.178.42 00:1A:4F:9E:16:6F tiwlan0 Laptop

einfach nur

Code:

192.168.178.42 00:1A:4F:9E:16:6F * Laptop

angebe.. - Nur laut ifconfig *ist* das wirklich das WLAN-Interface und daher müsste das doch tun?!

kriegaex · 18 Sep 2007

@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.

Eagle3386 · 18 Sep 2007

Okay, ich hab direkt in der ar7.cfg die Weiterleitung auf .1 geändert - gilt das dann sofort, oder muss ich eventuell irgendetwas neustarten?

[-EDIT-]

Nebenbei bemerkt: seit ich 15.2 verwende, spinnt meine Fritz!Box.. Obwohl ich sauber auf die DSL-Labor-Firmware aktualisiert habe und danach auch Werkseinstellungen zurücksetzte, weigert sich seit meinem Neustart heute Mittag der VOIP-Daemon beharrlich, meine beiden SIP-Nummern zu registrieren.. Ständig kommt der bekannt "DNS-Fehler" als Grund, obwohl ich alles das getan hab, was die SuFu zur Lösung angeboten hat und es ja wie gesagt bereits funktionierte - bis vor dem Neustart..

hermann72pb · 18 Sep 2007

1. du musst es nicht an .1 weiterleiten, sondern an 0.0.0.0!
2. Ja, das gilt sofort, man muss nichts starten.

MfG

Eagle3386 · 18 Sep 2007

Hö?

Regel vorher:

Code:

forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
 "tcp 0.0.0.0:65535 192.168.178.86:443 0 # Fritz!Box",
 "tcp 0.0.0.0:65534 192.168.178.86:442 0 # DS-Mod";

Regel jetzt:

Code:

 forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
 "tcp 0.0.0.0:65535 192.168.178.1:443 0 # Fritz!Box",
 "tcp 0.0.0.0:65534 192.168.178.1:442 0 # DS-Mod";

Wieso jetzt bitte 0.0.0.0 - das steht doch schon da?!

MaxMuster · 18 Sep 2007

"rechts" soll die hin: Statt der eigenen IP die 0.0.0.0 , also z.B.:

Code:

"tcp 0.0.0.0:65535 0.0.0.0:443 0 # Fritz!Box",

Eagle3386 · 18 Sep 2007

Thanks, done.

Rules:

Code:

"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",

Result: Couldn't connect to amd-power.homeip.net:65535: Connection refused =>

hermann72pb · 18 Sep 2007

Probier doch ohne diese Kommentare dahinter. Manchmal machen sie Probleme:

Code:

"tcp 0.0.0.0:65535 0.0.0.0:443",
"tcp 0.0.0.0:65534 0.0.0.0:442"[COLOR="Red"][B];[/B][/COLOR]

Und bitte mit Semikolon abschließen, wenn Port 442 die letzte Regel ist. Solche Kleinigkeiten machen oft Probleme. Um auf Nummer sicher zu gehen, würde ich temporär 443 in 80 oder 81 ändern und damit probieren.

MfG

Eagle3386 · 19 Sep 2007

Danach kommen noch 2 Regeln, aber nach der letzten steht ein Semikolon..

Hab's ebend mit 80, respektive 81 versucht - nix war's..

(Immer noch "Couldn't connect to amd-power.homeip.net:65535: Connection refused"..)

hermann72pb · 19 Sep 2007

dann hast du Probleme mit ar7.cfg, Port 65535 oder Firewall auf der anderen Seite (von welcher du zugreifst).

MfG

kriegaex · 19 Sep 2007

Die Auskunft, daß man nicht neu starten müsse, war falsch, soweit ich mich erinnere. Tu das mal, bitte. Alternativ geht auch das, damit dsld die Konfiguration neu einliest:

Code:

killall -sighup dsld

oFooBaro · 19 Sep 2007

Eagle3386 schrieb:
Okay, ich hab direkt in der ar7.cfg die Weiterleitung auf .1 geändert - gilt das dann sofort, oder muss ich eventuell irgendetwas neustarten?

Hallo,
ich hoffe, das ich mich mit meine ersten Post nicht gleich disqualifiziere ;-)

Aber wenn man Änderungen an der ar7.cfg macht, sollte man doch das Skript ar7cfgchanged ausführen. Ich glaube ich habe das im wiki irgendwo gelesen.

GRuß

hermann72pb · 19 Sep 2007

ok, kann sein, ziehe meine Behauptung schon mal zurück. Neustart ist immer gut.

MfG

MaxMuster · 19 Sep 2007

oFooBaro schrieb:
... sollte man doch das Skript ar7cfgchanged ausführen.

Ist qualifiziert ;-)

Eagle3386 · 19 Sep 2007

MaxMuster schrieb:
oFooBaro schrieb:

... sollte man doch das Skript ar7cfgchanged ausführen.

Zum Vergrößern anklicken....

Ist qualifiziert ;-)

*zustimm*

hermann72pb schrieb:
ok, kann sein, ziehe meine Behauptung schon mal zurück. Neustart ist immer gut.

MfG

Hö? Neustarts unter Linux sind immer gut? Hab ich was verpasst? - Mir wurde immer von "Linux-Gurus" gesagt, der einzige Grund, 'n Linux neuzustarten, ist 'n Kernel-Update - für alles andere gäbe es Tools, Befehle und Workarounds, um das zu vermeiden..

RalfFriedl · 19 Sep 2007

Eagle3386 schrieb:
Neustarts unter Linux sind immer gut? Hab ich was verpasst? - Mir wurde immer von "Linux-Gurus" gesagt, der einzige Grund, 'n Linux neuzustarten, ist 'n Kernel-Update - für alles andere gäbe es Tools, Befehle und Workarounds, um das zu vermeiden.

Es ist beides richtig.
Ein Neustart ist bei Linux so gut wie nie notwendig.
Wenn man aber nicht weiß, wie eine geänderte Konfiguration wirksam wird, ist ein Neustart die einfachste Lösung. Das ist auch der Grund, warum es bei Windows häufig die einzige Lösung ist.

hermann72pb · 19 Sep 2007

Eagle3386 schrieb:
Hö? Neustarts unter Linux sind immer gut? Hab ich was verpasst?

Die Box ist ja kein server mit mehreren Diensten. Sie neuzustarten dauert vielleicht 2-3 Minuten, "ar7cfgchanged"-Trick in IPPF zu finden dagegen, wenn du es nicht aus dem Kopf weiß kann schon etwas mehr Zeit in Anspruch nehmen. Das ist eben das Problem, man muss genau wissen, welche Dienste oder Skripte man ausführen muss, damit es neu ausgelesen wird.

MfG

Eagle3386 · 19 Sep 2007

OK, ich hab ar7cfgchanged ausgeführt - anscheinend führt das aber auch zu einem Neustart, denn nach

Code:

/var/mod/root $ ar7cfgchanged
/etc/init.d/rc.net: eval: line 1: avmike: not found

war in der Konsole einfach Schluss und Miranda meldete einen Verbindungsabbruch.. Ca. 20 Sekunden später war jedoch alles wieder da..

Und ich komme jetzt auch über 'nen Open-Proxy auf meine Box - allerdings kann ich auf einmal nicht mehr die ar7.cfg speichern - mit Nano bekomme ich ja schon immer nur die Fehlermeldung "File is a device file" beim Öffnen, aber nvi streikt jetzt auch!
Ich kann die Datei wunderbar öffnen und auch editieren - aber nach dem Editieren kann ich nicht per ESC aus dem Einfüge-Modus raus, sondern das bleibt einfach, egal wie oft ich auf ESC drücke..

hermann72pb · 19 Sep 2007

Deswegen mache ich es immer noch nach der alten Methode

Code:

cat FLASH > RAM
edit (mcedit)
cat RAM > FLASH

Aber das ist eher eine Glaubenssache, wie wir hier schon mal gelesen haben, die auch teilweise ihre Hintergründe im unterschiedlichen Verhalten von cp hat usw.
Sonst dürfte es eigentlich mit nnano genau so gut wie mit nvi oder mit nmcedit (von MC) gehen.

MfG

RalfFriedl · 19 Sep 2007

nvi verwendet aber auch immer cat, sowohl im Original als auch die Version vom ds-mod.

Matrixtunnel: VirtualIP vs. ar7.cfg

Neuer User

Aktives Mitglied

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Neuer User

IPPF-Promi

Aktives Mitglied

Neuer User

IPPF-Promi

IPPF-Promi

Neuer User

IPPF-Urgestein

IPPF-Promi

Neuer User

IPPF-Promi

IPPF-Urgestein

Statistik des Forums