Hast du das schon probiert?
Hallo MPW,
Die beiden eingetragenen DNS Server der Telekom sind erreichbar und geben auch Antworten. Am Anfang hatte ich es auch mit 8.8.8.8 probiert. Mit 1.1.1.1 hab ich es noch nicht probiert.
Es ist sehr schade, dass ich im LAN Bereich nicht mit festen IP Adressen arbeiten kann. Das ist deshalb schwer verdaulich, da es sonst überall im Netzwerk mit festen IP Adressen funktioniert. Das ist bei dieser Software echt kompliziert gelöst.
Normalerweise geht der Router ins Internet, baut den Tunnel zu einem der Freifunk Server auf und darüber stürzen sich die Leute ins Internet. Da habe ich zu einfach gedacht…
Das Menü beim Einrichten ist freundlicher Weise selbsterklärend aufgebaut. Keine meiner Einstellungen wurde irgendwie gefrickelt. Ich ging echt davon aus, dass ich die in den Menüs angebotenen Konfiguration Einstellungen auch funktionieren. Dort kann ich beispielsweise auch für die WAN Nic eine feste IP vergeben. Sie funktioniert ja eigentlich auch, da ich auf den Router darüber per ssh zugreifen kann.
Ich habe neben dem hier an zwei weiteren Standorten diese TP - Link Kombination in Betrieb genommen mit dem gleichen enttäuschenden Ergebnissen. Alle drei arbeiten mit festen IP Adressen auf der WAN Seite. Geht nicht anders. Da die Router direkt im Internet hängen. Es ist KEINE Firewall, oder Router mit ACL oder anderes davor! Es gab auch keine Sonderlocken Konfiguration, wie adorfer das meint. Ne feste IP auf der WAN Seite, das war schon alles. Wir haben da nur IPv4.
Ich habe mir viel durch gelesen über Freifunk, ein tolles Projekt, ehrlich. Aber wenn die Teilnahme so derart kompliziert einzurichten ist, dann sitzt die Frustration tief. Diese ist im Übrigen normal, da im Internet das Einrichten der Router als leicht dargestellt wird. Deshalb kann ich die überheblich wirkenden Angriffe von adorfer nicht nachvollziehen. Da sollte er diese Energie dafür verwenden, dass das auch läuft und es nicht zu monatelangem wiederundwiedwrinstallationen, oder Marathontroubleshooting ohne brauchbares Ergebnis führt.
Da sich unsere Geschäftsleitung bereits für die kostenpflichtige Lösung der Telekom entschieden hat, verfolge ich das hier nun privat weiter. Der grundlegende Gedanke an freies WLAN ist das wert. Bemerkenswert ist hier, dass die Hotspot Lösung unter diesen Bedingungen problemlos funktioniert.
Habt ihr alle eine FRITZ!Box vor dem Router, der diesem dann auf der WAN Seite per DHCP mit IP Adressen füttert? Niemand, der mit festen IP Adressen am WAN Port arbeitet? Ich hab das auch mal umgeklemmt, den MikroTik zwischen Internet und Freifunk Router geklemmt, wegen DHCP. Der FF Router versucht dann zu den gw Adressen von Freifunk eine Verbindung aufzubauen. Allerdings schickt er nur UDP Pakete auf den Zielort 53 zu diesen Servern. Es kommen jedoch keine Antworten auf diese DNS Anfragen zurück. Ich glaube, dass er dieses Verhalten auch mit fester IP Adresse zeigt.
Grüße
Ruebenmaster
Nein, soweit ich das hier nachvollziehen kann verrätst du nicht was mit „Internet“ gemeint ist. Auch nicht auf dem „Schaltbild“.
Es ist nie gut in einer Anleitung zu behaupten dass irgendwas einfach ist. Es ist aber z.B. auch nicht einfach zu verstehen von welchen Geräten du in den einzelnen Beiträgen sprichst. Ich vermute einfach mal dass du nicht den FF-Router direkt an die Telefondose steckst?
2 „Gefällt mir“
Wenn ich es recht sehe, dann wird gw02.ffrn.de aufgelöst.
und ping auf 88.99.210.115 funktioniert auch.
Ich werde mich jetzt nciht auf’s Nitpicking versteifen, ob eine Wolke „Internet“ auch legacyIP mit einschliesst oder nicht, wäre nicht weiterführend.
Ich tippe darauf, dass irgendeine Firewall/DDos-Erkennung/Teredofilter was gegen den VPN-Tunnel „tut“.
Meines Wissens unterstützt Gluon feste IPs auf der WAN-Seite.
Wenn das nicht geht, frag mal im Gluon-IRC nach oder erstelle ein Ticket.
Viele Grüße
Matthias
Schreibt er doch oben. Das Gerät hängt direkt am Upstream mit öffentlicher IP:
Laut whois ein Anschluss der
netname: TRIPORT-TWLKOM
@ruebenmaster, du müsstest doch per SSH von außen auf den Router kommen. Hast du evtl. mal Lust das Problem per Mumble in einer Livesitzung zu besprechen und jemandem hier Zugriff per SSH zu geben? Das dürfte vermutlich einfacher werden.
Viele Grüße
Matthias
PS: Dumme frage, kann ich mir natürlich selbst beantworten.
mpw@XPS13-Touch:~$ ping 217.151.149.75
PING 217.151.149.75 (217.151.149.75) 56(84) bytes of data.
64 bytes from 217.151.149.75: icmp_seq=1 ttl=55 time=44.4 ms
64 bytes from 217.151.149.75: icmp_seq=2 ttl=55 time=44.8 ms
^C
--- 217.151.149.75 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 44.499/44.658/44.817/0.159 ms
mpw@XPS13-Touch:~$ ssh root@217.151.149.75
The authenticity of host '217.151.149.75 (217.151.149.75)' can't be established.
RSA key fingerprint is SHA256:U4WF8t9QiqBZD7tzC6+B1YiER3O2iRhojVR1Y7iXURI.
Are you sure you want to continue connecting (yes/no)?
1 „Gefällt mir“
Hallo coco,
ich bin etwas irritiert wegen Deiner Frage/Kritik. Im Schaltbild ist zu erkennen, dass der Freifunkrouter direkt im Internet hängt. Wie kann ich das anders erklären?
Da ist ein Switch des Providers, auf dem ich mein Patchkabel einstecke und dann, mittels der manuellen Vergabe der IP Adresse und des Gateways, direkt im Internet bin. Deshalb auch die offizielle IP Adresse 217.151.149.75. Der Gateway ist die 217.151.149.65.
Wie soll ich anders den Anschluss ans Internet beschreiben?
Gruß
ruebenmaster
Hallo adorfer,
wenn eine Einrichtung vorhanden ist, welche tatsächlich als Firewall, DDos-Erkennung oder gar einen Teredofilter aktiv hat, dann weiß ich davon nichts. Wie schon erwähnt, ist mit dem Anschluss des Routers ans Internet (offizielle IP Adressvergabe) mein Zugriffsbereich beendet. Es müsste dann irgendwo im Internet einer den Verbindungsaufbau unterbinden. Ich bin kein Freund von Spitzfindigkeiten. Ich habe nur reagiert…
Was bedeutet „legacyIP“?
Gruß
Ruebenmaster
Hallo MPW,
das ist eine gute Idee. Wir sollten einen Termin finden, an dem wir dann auf den Router schauen.
Gruß
ruebenmaster
@ruebenmaster, idealer Weise macht das jemand aus deiner Community, aber ich schaue auch gerne drauf.
Melde dich ggfs. per PN.
Viele Grüße
Matthias
Hallo Matthias,
Ich werde mich bei der Community für den Freifunk Rhein-Neckar mal melden und vielleicht kann von denen eine(r) drauf schauen.
Wenn nicht, dann melde ich mich bei Dir.
Gruß
Ruebenmaster
Am 02.10.18, 20:37, MPW no-reply@forum.freifunk.net schrieb:
IPv4. Jener 32-Bit-Adressraum ist seit Jahren vollständig mindestens auf die regionalen Vergabestellen verteilt, leider nimmt das Nachfolgeprotokoll IPv6 (128-Bit-Adressraum; während Du als Privatkunde heute bestenfalls eine IPv4-Adresse von Deinem ISP bekommst, bekommst Du i. d. R. bei IPv6 gleich mindestens ein /64-Subnetz, also rund 2^64 nutzbare Adressen, zugeteilt) seit 20 Jahren nicht wirklich Fahrt auf und so versucht man, IPv4 z. B. durch solche Spitznamen madig zu machen.
Sollte er auch/tut er an sich auch. Also, bei den meisten Setups 
Verständlich; mir ist allerdings auch nicht wirklich klar, was hier schief läuft.
Erm. Ich habe grade mal eine VM mit der FFRN-FW aufgesetzt (statisch konfiguriert, da ich im RZ auch kein DHCP verwende), am Ende steht da:
Dies ist der öffentliche Schlüssel deines Freifunk-Knotens. Erst nachdem er bei uns registriert wurde, kann sich dein Knoten mit dem Freifunk Rhein Neckar Mesh-VPN verbinden. Bitte klicke dazu auf folgenden Link, dieser füllt das Formular schon mit einem Teil der Daten aus.
Zur Registrierung.
Da du gerade vermutlich keine Internetverbindung hast, verbinde dich einfach wieder mit einem Internetanschluss und aktualisiere dann die Registrierungsseite.
Hast Du den Link „zur Registrierung“ angeklickt/das Formular ausgefüllt?
Ich habe, und bei mir kommt eine Verbindung zustande:
Nachtrag: Auch ein hinter die VM gehängter Client tut, ich bin mir also ziemlich sicher, daß Du schlicht und ergreifend Deine Knoten nicht beim FFRN registriert hast, daher wird kein VPN aufgebaut und nix klappt. Hier hingegen tut’s, wie’s soll:
root@ffrn-client:~# ip route show
default via 10.142.0.3 dev ens4
10.142.0.0/16 dev ens4 proto kernel scope link src 10.142.107.185
192.168.122.0/24 dev ens3 proto kernel scope link src 192.168.122.9
root@ffrn-client:~# traceroute -T heise.de 80
traceroute to heise.de (193.99.144.80), 30 hops max, 60 byte packets
1 10.142.0.3 (10.142.0.3) 16.707 ms 16.693 ms 16.681 ms
2 vm01.rz17.fks.de.ffrn.de (138.201.30.195) 16.675 ms 16.663 ms 16.653 ms
3 static.193.30.201.138.clients.your-server.de (138.201.30.193) 16.643 ms 16.871 ms 16.852 ms
4 core24.fsn1.hetzner.com (213.239.203.233) 16.865 ms 17.085 ms core23.fsn1.hetzner.com (213.239.203.229) 16.805 ms
5 core4.fra.hetzner.com (213.239.229.73) 21.638 ms core4.fra.hetzner.com (213.239.203.149) 21.629 ms core0.fra.hetzner.com (213.239.252.41) 21.619 ms
6 te0-0-2-3.c150.f.de.plusline.net (80.81.192.132) 22.410 ms 22.034 ms te0-0-2-3.c350.f.de.plusline.net (80.81.193.132) 22.271 ms
7 * * *
8 * * *
9 * * *
10 redirector.heise.de (193.99.144.80) 31.443 ms 31.430 ms 31.359 ms
root@ffrn-client:~# cat /etc/network/interfaces.d/ens4.cfg
auto ens4
iface ens4 inet dhcp
iface ens4 inet6 auto
(Wir (Kreis GT, Müritz) und viele andere (Münsterland, Fichtenfunk(?), …) haben den Registrierungszwang, teils vor Jahren, ad acta gelegt und agieren mit Blacklists statt Whitelists. Das könnte erklären, warum wir uns 'nen Wolf suchten …)
4 „Gefällt mir“
Jetzt fehlt nur noch die Bestätigung von @ruebenmaster, ob nach (Neuinstallation und) Registrierung auch sein Knoten tut. (Achtung, jede Neuinstalliation erzeugt IIRC einen neuen, zufälligen Schlüssel, d. h. nach jeder Neuinstallation (nicht: Update/Konfig-Änderung) muß der Knoten neu angemeldet werden.)
1 „Gefällt mir“
Hallo Wusel,
noch keine neuen Infos aus Ludwigshafen, wo mein TP-Link noch immer auf die Verbindung wartet.
Gruß
ruebenmaster
1 „Gefällt mir“
Erm. Du hast …
… wahrgenommen? Konkret: hast Du Deine Knoten über das Formular von FFRN mit allen Daten angemeldet? Ich denke nicht, denn sonst …
… dürfte jener schon längst »Verbindung« haben. Den Tests nach tut auch die Namensauflösung der Gateways für den relevanten Prozeß (fastd) bei Dir. Da FFRN eine Übermittlung des fastd-Schlüssels vorab verlangt, bevor FFRNs fastd mit dem Deines Knotens spricht, paßt das »keine FF-Verbindung«-Symptom ins Bild eines aufgesetzten, aber nicht angemeldeten FFRN-Knotens.
Hallo Wusel,
wohooo,
Unser DELUH01-FFRN001 ist online!
Vielen Vielen dank für Eure Hilfe!
Glücklicher Gruß
ruebenmaster
Ist das da unten ein Testrouter von Dir, Wusel?
Und eine „Auflösung“ gibt es nicht, woran es lag?
Schade.
Hallo adorfer,
sorry, hab ich vergessen dazu zu schreiben. Es lag tatsächlich an der Registrierung des Knotens. Ich habe nach der Neuinstallation das Ding neu registriert und siehe da… geht.
Gruß
DER ruebenmaster
War dieser „letzte Schritt“ nicht in der Anleitung vermerkt?
War es eine Community fremde Anleitung?
…oder hast Du die Anleitung nicht zuende gelesen?
Yepp, meine VM in Hamburg, hinter der eine andere VM auf dem virtuellen „gelben Port“ hängt und tut, wie sie soll:
root@ffrn-client:~# traceroute forum.freifunk.net
traceroute to forum.freifunk.net (185.66.195.242), 30 hops max, 60 byte packets
1 10.142.0.3 (10.142.0.3) 17.178 ms 17.140 ms 17.100 ms
2 vm01.rz17.fks.de.ffrn.de (138.201.30.195) 17.067 ms 17.029 ms 17.002 ms
3 static.193.30.201.138.clients.your-server.de (138.201.30.193) 17.905 ms 17.900 ms 17.875 ms
4 core23.fsn1.hetzner.com (213.239.203.229) 17.784 ms core24.fsn1.hetzner.com (213.239.203.233) 17.760 ms 17.723 ms
5 core5.fra.hetzner.com (213.239.224.254) 21.860 ms core5.fra.hetzner.com (213.239.224.250) 21.833 ms 21.776 ms
6 ae6-229.RT.IRX.FKT.DE.retn.net (87.245.245.113) 22.427 ms 21.928 ms 21.895 ms
7 ae0-5.RT.SB.BER.DE.retn.net (87.245.232.246) 30.282 ms 30.113 ms 30.456 ms
8 185.66.195.0 (185.66.195.0) 33.488 ms 33.544 ms 33.509 ms
9 forum.freifunk.net (185.66.195.242) 33.493 ms 33.469 ms 33.453 ms
Schön, das es nun auch bei Dir tut, dann kann ich das Setup ja einstampfen
Offensichtlich mindestens auch die Hinweise nach „fertig eingerichtet“ überlesen:
(FTR: Wir hatten damals einen Auto-Refresh nach 90 Sekunden auf die Registrierungs-URL drin, jene war per HTTP GET zufriedengestellt.
Grundgedanke für Umstellung von White- auf Blacklist: Mesh-Knoten müssen auch nicht registriert werden, wozu also der Heckmeck für’s VPN? Aber das entscheidet halt jede Community für sich und das ist auch gut so.)