Ach so, die iptable-Einträge waren noch aktiv, nachdem Du mir mitgeteilt hattest, dass Du den Firewall abgeschaltet hattest. Ich habe mich glücklicherweise über meinen Rechner zu Hause einloggen können. Nachdem ich die iptables mit der Option -F gelöscht hatte konnte ich mich sofort auch vom lokalen Rechner einloggen. Also irgendwas läuft da nicht so wie es soll.
vy 73s de Adi, DL1HRC
Hallo zusammen,
ich habe in letzter Zeit ähnliche Probleme beobachtet.
Heute hatte ich mal Zeit zum "Troubleshooting", folgendes habe ich dabei bemerkt:
Ich habe auf meinem RPI, wo auch der Echolink-Server beheimatet ist, eine Anbindung an das HamNet.
Dieses hat exklusiv den 44.0.0.0/8 Bereich (Class A). Und jetzt kommt es:
Es scheint eine Umstellung des Adressbereiches einiger (nicht aller!!!) europäischer Echolink-Gateways gegeben zu haben.
Von manchen kommt die "Incoming Connection" nun auch aus diesem Bereich. Wie blöd! Also kommt der Connect via Internet
und wird via HamNet bei mir zurück geroutet. Somit kommt zwar das IP-Paket bei meinem Server an, aber der Rückweg verläuft im Sande...
Im Log von SVXLINK ist kein auffälliges Verhalten zu bemerken, es kommt einfach die "Rückantwort" da draußen nicht an.
Bis ich einen schlaueren Einfall habe, habe ich das mit einer statischen Route (best match) auf dem RPI gelöst:
route add -net 44.137.0.0 netmask 255.255.0.0 gw x.x.x.x (mein DSL-Router). Das hat natürlich den Nachteil, dass für mich nun Teile des HamNet
aus diesem Bereich nicht mehr erreichbar sind. Wahrscheinlich lässt sich der Range weiter einschränken (vielleicht Class-C mit einer /24 Maske),
aber das ist mit meinem Netzwerkanalyzer ein langwieriger Debugging-Prozess 
---Einfacher wäre hier das IP-Adresskonzept des EchoLink Sysop zu kennen.
Den Bereich 44.137.0.0 habe ich aus dem IP-Debugging entnommen, hier kamen die Requests von außen von z.B. 44.137.75.245...246...247 u.s.w.
Es sind die sogenannten "Relais" im Echolinknetz. Warum diese nun auf den exklusiven IP-Bereich des HamNet umgestellt werden ist mir ein Rätsel.
Routenverfolgung:
pi@raspberrypi ~ $ traceroute 44.137.45.245
traceroute to 44.137.45.245 (44.137.45.245), 30 hops max, 60 byte packets
1 mein.router (mein.router) 0.644 ms 0.931 ms 0.759 ms
2 217.0.118.201 (217.0.118.201) 21.643 ms 21.914 ms 22.929 ms
3 87.186.237.230 (87.186.237.230) 28.743 ms 28.612 ms 28.600 ms
4 217.239.52.126 (217.239.52.126) 29.867 ms 31.059 ms 31.101 ms
5 ffm-s1-rou-1102.DE.eurorings.net (134.222.249.121) 31.882 ms 32.434 ms 34.102 ms
6 asd2-rou-1043.NL.eurorings.net (134.222.95.48) 41.077 ms 32.215 ms 32.920 ms
7 134.222.93.145 (134.222.93.145) 33.701 ms 31.497 ms 32.229 ms
8 te5-4.swcolo2.1d12.xs4all.net (194.109.12.6) 34.150 ms 35.066 ms 34.943 ms
9 * * *
10 * * *
11 * * *
Es scheint als stehen die Gateways schon im HamNet und werden via L2TP oder so`n Zeug getunnelt...
Evtl. hat ja der ein oder andere eine ähnliche Konstellation.
73 de Michael
DL5OCD
Hallo zusammen,
ich habe mal nachgesehen: Das Netz 44.137.75.0/24 gehört zu PI9NOZ, dort werden wohl eine ganze Reihe EchoLink-Proxys betrieben (siehe hier). Die Adressen 44.137.75.245, 246 usw. kann ich auch im HAMNET erreichen. Vielleicht gibt es ja bei PI9NOZ einen Konfigurationsfehler?
Schönen Gruß
Frank, DL3DCW
Hallo,
ich glaube eher an einen Konfigurationsfehler bei den EchoLink Relays. Diese bedienen sich scheinbar aus dem IP-Range des HamNet...
73 de Michael
DL5OCD
pi@raspberrypi ~ $ traceroute 44.137.45.245
traceroute to 44.137.45.245 (44.137.45.245), 30 hops max, 60 byte packets
1 mein.router (mein.router) 0.644 ms 0.931 ms 0.759 ms
2 217.0.118.201 (217.0.118.201) 21.643 ms 21.914 ms 22.929 ms
...
Hallo Michael,
die oben angegebene Route über das Internet geht vermutlich über die UCSD (University of California, San Diego). Dort steht wohl ein ganz kleines Gateway. Das war aber schon immer so und ist daher normal. Für "normalen" Traffic ist diese Route aber nicht gedacht und aufgrund der absolut geringen Bandbreite auch nicht zu gebrauchen.
Wenn ich vom HAMNET aus eine Verbindung via HAMNET-Echolink-Proxy nach außen aufbaue, sollte als Absender dann eigentlich eine Internet-Adresse auftauchen. Nämlich die Internet-Adresse des Rechners, auf dem der Proxyserver installiert ist. Unter dieser ist dann auch meine HAMNET-Station für alle anderen Echolink-Stationen aus erreichbar. Eine HAMNET-IP-Adresse sollte dort also eigentlich nicht stehen.
So habe ich das zumindest verstanden und auch bei den HAMNET-Proxys von DB0TV konfiguriert. Und bisher sind mir damit keine Probleme bekannt ;-).
Schönen Gruß
Frank, DL3DCW
ich glaube eher an einen Konfigurationsfehler bei den EchoLink Relays. Diese bedienen sich scheinbar aus dem IP-Range des HamNet...
Hallo Michael,
ich denke, mit "EchoLink Relay" und "Echolink-Proxy" bei PI9NOZ meinen wir im Moment das gleiche. Ich vermute dort ebenfalls einen Konfigurationsfehler. Das mit den IP-Adressen aus dem HAMNET ist aber ok und auch sinnvoll, denn für den HAMNET-User muss der Proxy aus dem HAMNET erreichbar sein. Die Internet-Adressen werden im HAMNET ja nicht geroutet.
Von der EchoLink-Welt (also vom Internet) aus gesehen sollten dort aber immer nur Internet-Adressen stehen. Denn mit HAMNET-Adressen kann dort ja niemand etwas anfangen. Denn diese wiederum werden ja Im Internet nicht geroutet ...
HAMNET HAMNET Proxy INTERNET INTERNET
DL3DCW DB0TV DB0TV DL2DCW
44.225.125.12 <-> 44.225.125.2 <-> 178.77.70.208 <-> 178.77.70.218
Schönen Gruß
Frank, DL3DCW
Hallo Frank,
genau das ist das Problem. Das gesamte Netz 44.0.0.0 wird dorthin geroutet, soweit normal. Macht ja auch Sinn, denn dieses Class-A Netz ist für das HamNet reserviert.
Wenn nun aber einzelne Hosts, in diesem Falle die EchoLink Relays im Internet(!) sich aus diesem Bereich bedienen, kommt es auf meinem RPI bzw. meiner gesamten DMZ zu Routingproblemen.
Da hat irgendwo einer geschlafen...ich vermute fehlendes Masquerading am Gateway.
73 de Michael
DL5OCD
Hallo,
ich habe nun einmal genauer nachgesehen und aus dem HAMNET von DL3DCW aus jeweils eine Verbindung über die Proxys DB0TV und dann über PI9NOZ zum Zielsystem DL3DCW-L aufgebaut. Das System dort sagt dann:
Via Proxy DB0TV: "Incoming EchoLink connection from DL3DCW (Frank) at 176.28.1.160"
Die 176.28.1.160 ist die IP-Adresse des Proxys DB0TV. Unter der Adresse ist die HAMNET-Station DL3DCW dann auch aus dem Internet (und damit für alle anderen EchoLink-Stationen) erreichbar. Soweit also erst einmal ok.
Via Proxy PI9NOZ: "Incoming EchoLink connection from DL3DCW (Frank) at 44.137.75.108"
Die 44.137.75.108 ist die IP-Adresse des Proxys PI9NOZ. Dies ist aber eine HAMNET-Adresse! Das bedeutet, die HAMNET-Station DL3DCW kann nur per HAMNET - und nicht vom Rest der Welt via EchoLink (wie es eigentlich sinnvoll wäre) - erreicht werden. Und hier vermute ich den Konfigurationsfehler.
Ganz 100% sicher bin ich mir aber nicht ... 
Schönen Gruß
Frank, DL3DCW
Hi Frank,
prima, dann kann ich ja bald meine statische Route wieder löschen
Ok, wenn die Büchse in den Niederlanden auch das EchoLink Relay beherbergt passt das.
Ich hoffe, dass ein Teil (Großteil?) der beschriebenen Probleme dann bald ein Ende hat...
Wie sage ich das jetzt aber dem Sysop? Hast du da Verbindungen?
73
Bei QRZ.com gibt es eine E-Mail-Adresse. Vorher schaue ich aber lieber noch einmal genau nach, ob es wirklich daran liegt. Ich werde dafür nachher einmal einen der Proxy's von DB0TV umbiegen. Dann weiß ich vielleicht mehr ...
Cool, leider habe ich hier nur eine AX25-IP Anbindung (ja, diese vorsintflutliche Technik gibt es noch!) und DB0UHI scheint zur Zeit über diesen Weg vom Rest des HamNet abgeschnitten zu sein.
Sonst könnte ich hier selber mal aktiv werden...
73
... und DB0UHI scheint zur Zeit über diesen Weg vom Rest des HamNet abgeschnitten zu sein. Sonst könnte ich hier selber mal aktiv werden...
Für solche schlimmen Notfälle gibt's ja auch noch VPN (z.B. http://www.ruhrlink.org)
Merkwürdig, ich habe es noch nicht geschafft, die Einstellungen des EchoLink-Proxyservers so zu verbiegen, dass er sich genauso verhält wie PI9NOZ. Ich werde die OM's aber einfach mal anschreiben. Dann wissen wir vielleicht mehr ...
Hallo Michael,
ich habe eine Antwort von Rob (er ist vermutlich Sysop bei PI9NOZ) bekommen. Es scheint wohl wirklich so zu sein, dass die dortigen HAMNET IP-Adressen (44.137.x.x) auch im Internet per BGP announced werden und somit auch über diesen Weg erreichbar sind. Das würde unsere Beobachtungen und auch die Route (s.o.) erklären. Diese geht ja anscheinend nicht zur UCSD. So genau hatte ich mir das anfangs noch gar nicht angesehen ...
In wie weit das sinnvoll ist, kann ich im Moment noch gar nicht beurteilen. Da fehlt mir leider ein wenig der Überblick. Da müssen vielleicht wirklich mal die HAMNET-Spezialisten ran ;-).
Nachtrag: Im Prinzip müsste es ja eigentlich trotzdem funktionieren, auch wenn es vielleicht keine perfekte Lösung ist: Eingehende Verbindungen über den Proxy von PI9NOZ kommen übers Internet rein und der Rückweg geht über das HAMNET (da Du ja die 44.0.0.0/8 als statische Route eingerichtet hast). Das sich die Verbindung bei Dir nicht aufgebaut hat könnte ja eventuell an der schlechten HAMNET-Anbindung liegen. Von hier aus ist PI9NOZ via HAMNET ganz gut erreichbar; der Standort scheint direkt via Tunnel an DB0FHN in Nürnberg zu hängen ...
Schönen Gruß
Frank, DL3DCW
Hallo Michael,
bei PI9NOZ handelt es sich nicht um einen Konfigurationsfehler, sondern das Ganze wird bewusst so gemacht. Die dort verwendeten HAMNET-Adressen sollen auch aus dem Internet erreichbar sein. So hat mir Rob das gerade noch einmal in einer ausführlichen E-Mail erklärt. Es gibt wohl in den verschiedenen Ländern unterschiedliche Sicht- bzw. Vorgehensweisen. Die einen routen 44er-Adressen auch im Internet, die andern nicht. Ich denke, damit müssen wir also leben. Auf jeden Fall habe ich wieder etwas dazugelernt ...
Schönen Gruß
Frank, DL3DCW
Hallo Frank,
danke für deine Mühe. Aber das was die dort in NL treiben verstehe ich nicht so ganz...HamNet Adressen nun auch im Internet...na dann.
Jetzt wo ich den Tunnel eingerichtet habe, ist meine HamNet Anbindung super! 
Ich hoffe, dass ich auch bald wieder über die Luftschnittstelle eine Anbindung bekomme...mal sehen.
Für alle anderen OM`s mit ähnlicher Konstellation: Achtung!!!
Vielen Dank!
73
HamNet Adressen nun auch im Internet...na dann.
Hallo Michael,
naja, das Ganze ist ja nicht verboten. Unter gewissen Umständen kann das vielleicht sogar recht sinnvoll sein. Mit allen Vor- und Nachteilen, die man sich dadurch erkauft. Hier in DL gibt es ein Routing der HAMNET-Adressen im Internet ja eher nicht. Das hat vor allem den Vorteil, dass man sich keine umständlichen Authentifizierungsmaßnahmen überlegen muss. Wer über HF mit Amateurfunkparametern einsteigt, ist erst einmal Funkamateur (oder Schwarzfunker, hi) und die VPN-Server sind ja durch die Verwendung von Benutzername/Kennwort geschützt und damit nur für Funkamateure zugänglich.
Schönen Gruß
Frank, DL3DCW
Hallo,SVXer
Interessante Diskussion,wird wahrscheinlich viele Relais betreffen
Auf keinen Fall sind das Konfigurationsprobleme der bisher laufenden SVX-Relais.
Ich habe in den letzten Wochen ebenfalls diese seltsamen Connects auf DB0CSD beobachten können.
1. ständige Connects mit sofortigen Diskonnects bis zu 5 oder 6 mal hintereinander
2. Connectversuche von Stationen mit deutschem Call und Hamnetadresse
Normalerweise läuft der EL-Verkehr bei mir vom Internet über einen Router,der Hamnet und mein Heimnetz trennt und einen
EL-Proxy ,welcher bei mir steht und sich im Hamnet über eine 5Ghz-Strecke zum Hamnetknoten und von dort zu DB0CSD
verbindet..
Diese Konfiguration läuft seit etwa einem Jahr ohne Probleme.Seit etwa 1 Monat treten gehäuft fehlerhafte Connects auf.
Ich werde mal tracen,was da wohl schief läuft. Zeit dazu habe ich ja.
Sollte ich zu verwertbaren Ergebnissen kommen,werde ich diese mal hier darlegen.
Tschüss,73 von Jürgen, DL1JAC
Hallo Jürgen,
dann wäre es interessant zu wissen, ob es sich bei den HAMNET-Adressen vielleicht auch um die Proxys bei PI9NOZ (44.137.75.x) handelt. Da Du ja bestimmt auch eine statische Route zum HAMNET eingetragen hast (44.0.0.0/8), kommt es dann eventuell zu Problemen, z.B. wenn die IP-Adresse via HAMNET nicht erreichbar ist ...
Schönen Gruß
Frank, DL3DCW
Hallo Jürgen,
genau so äußert sich das Problem! Ich habe es einfach mit einer statischen Route gelöst, das EchoLink-Proxy-Cluster aus NL habe ich jetzt via Internet geroutet (44.137.75.0/24).
Die Probleme häuften sich bei mir seit Anfang/Mitte Dezember.
PS: Ich glaube immer noch nicht, dass das alles so im Sinne des Erfinders ist. Der Betreiber von dem Proxy-Cluster sollte diese Konfiguration noch einmal überdenken.
73 de Michael
DL5OCD
Hallo,SVxer
Mein Zwischenergebnis:
Fehlerhafte Connects kamen mit IPs:
44.137.75.241
44.137.75.243
44.137.75.245
Ergebnis traceroute:
traceroute to 44.137.75.241 (44.137.75.241), 30 hops max, 60 byte packets
1 44.225.32.100 (44.225.32.100) 0.347 ms 0.324 ms 0.311 ms
2 44.225.32.90 (44.225.32.90) 4.583 ms 4.745 ms 8.353 ms
3 44.225.32.96 (44.225.32.96) 9.485 ms 9.710 ms 9.965 ms
4 44.225.32.101 (44.225.32.101) 13.449 ms 13.451 ms 13.998 ms
5 44.225.32.32 (44.225.32.32) 14.046 ms 17.824 ms 17.855 ms
6 bb-db0chz.db0gw-2.as64621.de.ampr.org (44.224.2.33) 57.907 ms 55.040 ms 58.364 ms
7 bb-hubwest.db0fhn.as64621.de.ampr.org (44.224.2.6) 73.999 ms 71.704 ms 71.949 ms
8 db0fhn.as64626.de.ampr.org (44.130.60.100) 60.347 ms 63.316 ms 65.027 ms
9 * * *
Traceroutes für alle Adressen zwischen 44.137.75.240 und 44.137.75.249 bringen
die gleichen Ziele bei leicht abweichenden Zeiten.
Ich habe am Sonntag einen OM kontaktiert,der ständig versuchte,über Echolink an unserer
Sonntäglichen Chemnitzer Runde teilzunehmen.
Während der Runde hatte ich das Relais DB0CSD direkt übers Terminal mitlaufen.
Incoming EchoLink connection from DM2xxx (Frank) at 44.137.75.241
*** WARNING: Ignoring incoming connection from DM2xxx since the IP address registered in the directory server (44.137.75.242) is not the same as the remote IP address (44.137.75.241) of the incoming connection
Spurious audio packet received from 44.137.75.241
Das alles hätte überhaupt nicht übers Hamnet kommen dürfen!
Ergebnis der Befragung des OMs:
Technik Fritzbox,T-Online kein Hamnetzugang
betreibt EL sonst über PC,wohin auch die Portweiterleitung verweist
Er hat diesmal sein Android-Netbook mit WLAN an der FB benutzt,
ohne die Portweiterleitung auf das WLAN zu setzen!
Als nächstes werde ich DB0CSD so abschotten,dass nur ich selbst und sein Echolink-Proxy ,der ihm sonst seine
EL-Verbindung ins Internet verschafft,das Relais aus dem HAMNET erreichen kann.Das bekämpft zwar nicht die Ursache,aber mindert die Wirkung.
Tschüss,73 Jürgen,DL1JAC