Siduction Forum
Siduction Forum => Software - Support => Topic started by: dieres on 2023/01/25, 10:33:01
-
Moin,
ich habe sowohl zu Hause, als auch im Job einen Linux Server, der über dyndns per ssh erreichbar ist.
Zuhause hängt das LAN an der Fritzbox, die über DSL mit dem Internet verbunden ist. In Der Praxis ist wegen Anlagenanschluss die Verbindug über die Audiocodes500 hinter der eine Fritzbox als Unterrouter das Lan verwaltet.
Zuhause funktioniert ssh -p <port> externIP/dyndnsName sowohl auf den dyndnsnamen von zuhause als auch der Praxis.
in Der Praxis funktioniert der ssh Zugriff auf zu Hause, aber nicht der Zugriff auf den eigenen dyndnsNamen der Praxis oder deren ext. IP.
ssh: connect to host 95.33.158.234 port 2764: Connection refused
ssh -p 2764 192.168.1.254 dagegen funktioniert.
das muss mit der Konfiguration/Firmware der Audiocodes500 zusammenhängen, denke ich?
Obwohl ich das Connection refused nicht wirklich verstehe, wo es von aussen und im lokalen Netz funktioniert. Nur aus dem lokalen Netz auf die externe IP oder den eigenen DyndnsNamen geht es nicht. Heisst auch nicht no route to Host, es wird also eigentlich etwas gefunden.
Ist nicht wirklich ein Drama, weil die wichtigen Einsatzgebiete funktionieren ja.
Aber ich würde diese Auffälligkeit gern verstehen.
-
Da ich deinen Aufbau nicht ganz nachvollziehen kann, da ich die Geräte nicht kenne, einfach ein allgemeiner Hinweis aus der Praxis: Häufig hast Du es in solchen Fällen damit zu tun das eine Komponente versucht "schlau" zu sein und erkennt das die Anfrage von intern kommt und entsprechend um-routet. Das kann an einem falsch gesetzten default-gateway liegen oder auch an forward-Regeln oä. Leider sind solche Fehler meist schlecht zu finden, gerade wenn Du es mit Consumerhardware zu tun hast.
-
...In Der Praxis ist wegen Anlagenanschluss die Verbindug über die Audiocodes500 hinter der eine Fritzbox als Unterrouter das Lan verwaltet.
...
Wenn hier jemand helfen soll müßtest du wohl eine Anschlussskizze der beiden Fälle liefern (genaue Reihenfolge der Verbindungen)
-
Die Internetverbindung läuft über die EWE Tel, Hardware: Audiocodes500 Router, hinter der die ISDN Anlage sitzt, und das interne Netz 192.168.0.0/24 hat. der Router 192.168.0.1, als einziger Teilnehmer diese Netzes fungiert die Frizbox 7590 die das interne Netz 192.168.1.0/24 aufzieht, wo sich alle anderen Netzteilnehmer, PCs, Telematik Router, etc. befinden.
Der Linux-Server hat die IP 192.168.1.254 wo pihole als lokaler DNS Server läuft, Nextcloud, urbackup, samba sshd etc. Die Fritzbox hat die lokalen Adressen 192.168.1.2 und 192.168.0.2. Auf der Audiocodes ist die Fritzbox als DMZ eingetragen, so das alles zur Fritzbox weitergeroutet werden sollte.
die Fritzbox spielt auch DHCP Server und verweist auf den lokalen DNS Server auf die IP ders Linux-Servers.
Weil dort eine virtuelle (Windows) Maschiene im Netz gebraucht wird, ist das Netz als bridge für QemuKVM konfiguriert.
root@debian-server:~# route -n
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.2 0.0.0.0 UG 425 0 0 br0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 vnet0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-1ed01 26dbaa4
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-692f9 e311e36
172.21.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-a9deb be5cfe8
172.22.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-18d93 32f0c13
192.168.1.0 0.0.0.0 255.255.255.0 U 425 0 0 br0
root@debian-server:~# ifconfig br0
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.254 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::8e92:397e:5734:d30b prefixlen 64 scopeid 0x20<link>
ether 96:e5:81:23:40:a9 txqueuelen 1000 (Ethernet)
RX packets 89068015 bytes 433687695468 (403.9 GiB)
RX errors 0 dropped 173889 overruns 0 frame 0
TX packets 64501722 bytes 346567047135 (322.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
-
Huch! Das mit den code Blöcken war eigentlich anders geplant.