Hi,
kurze Frage: ist es nur so gewollt oder hat es einen technischen Grund warum man händisch neue Knoten (deren Namen und Key) eintragen muss?
Der Router bootet ja eh nach der Konfiguration neu und sollte danach Internetzugang haben - demnach müsste er auch selber das eintragen können, oder?
Ja, er hat ohne eingetragenen Key keine fastd-(VPN)-Verbindung - demnach sollte auch kein Zugriff aus dem angebundenen WLAN ins Internet möglich sein. Aber das ist mMn nur eine Firewall-Regel und nicht mehr. Es ist technisch ein bischen Klimmzügig - aber möglich mMn.
Umso einfacher man die Installation machen kann umso weniger Support-Anfragen, oder?
Das Problem dabei ist, dass man dann beim nächsten Booten in den Konfigurationsmodus den Router erneut doppelt (dreifach, vierfach) registrieren würde.
Es ist auch überhaupt nicht gesagt, dass der Router an diesem Punkt überhaupt schon ins Internet kommt. Bei meinem Laptop muss ich erstmal WLAN deaktivieren, damit ich überhaupt über LAN in das Webinterface des Routers komme. Dann heisst es erstmal wieder Router abstecken, WLAN wieder aktivieren und dann registrieren. Warum auch immer das so sein mag.
Also so rein prinzipiell muss man Knoten garnicht registrieren. Wenn man on verify "true"; in die fastd.conf schreibt, nimmt fastd direkt jeden Key an. true darf man dabei durch ein beliebiges Shellscript ersetzen, das entweder 0 (True) oder 1 (False) zurück gibt.
Dem Script stehen diverse Umgebungsvariablen zur Verfügung anhand derer es entscheiden kann ob es den Knoten reinlässt, oder nicht. Beispielsweise könnte man ja eine Blacklist implementieren oder anhand der IP grob Geolokalisierung betreiben und Knoten aus dem Gebiet der Community direkt zulassen während man andere nur manuell einträgt.
Vielleicht fallen euch da ja clevere Lösungen ein. Ich find das Keyeintragen auch ziemlich umständlich.
Ich habe von Anfang an den sinn des Fastd Registers nicht so ganz Verstanden. Was macht es für einen unterschied ob ich vorher nen Key eintragen lasse oder nicht?
Meiner Auffassung nach ist das ein Schlüssel, der ähnlich wie bei SSH zum Verbindungsaufbau genutzt wird. Mir ist das generell nie so als Hürde aufgefallen, bei Foren muss ich ja auch einen Authcode übergeben, wobei der da in eine URL schon voreingebacken ist.
Blöde Frage, wie liefert man den passenden Rückgabewert? Wie in einem Shellscript mit exit 0 um die Connection des Node zuzulassen und bspw. exit 1 um die Connection abzulehnen?
Der Link kann dann irgendwann angeklickt werden, sobald der einrichtende Client eine Internetverbindung hat.
Jetzt müsste die Register-Seiter noch leicht angepasst werden um auch GET-Parameter zu akzeptieren. Außerdem darf auf keinen Fall eine doppelte Registrierung bei mehrfachem klicken vorgenommen werden, was nach meinem Wissensstand immernoch ein Problem im Ruhrgebiet darstellt.
Auf den Routern ist wget installiert: Das kann auch doch auch PUT, wenn es nicht rausgepatcht wurde (Wer sollte das tun?). Das Skript sollte doppelte Registrierungen nicht durchführen.
OT: ich meine, ich hätte via uci schon mal den Namen des Knotens geändert und für den weiteren Betrieb keine neue Registrierung vornehmen müssen. Falsche Erinnerung?
Richtige Erinnerung. Es ist nur der Key notwendig, der Name spielt beim Aufbauen des Tunnels keine Rolle.
Von der Registrierung haben wir im Grunde genommen nix, außer das wir die Router einzeln löschen können bei Bedarf, haben aber auch noch keine Lösung für eine Bereinigung des Verzeichnisses.
Die Lösung einfach jeden Router reinzulassen, in sofern er nicht per Mac oder Public Key blacklisted ist, sollte für uns eine sehr gute Möglichkeit darstellen, den Prozess zu entschlanken und dennoch einzelne Router aussperren zu können.
Für die Auto Registrierung gibt es bereits ein fertiges Gluon Paket einer Community, aber warum sollen wir überhaupt noch mit Registrierung arbeiten - welchen Vorteil hätten wir dadurch?
@CyrusFox backt uns ein kleines Script zusammen, dass den Peer Public Key gegen eine Blacklist matched, die per Cron direkt aus nem Repo kommt. So können wir das unaufwändig zentral verwalten und sind endlich die lästige Registrierung los…
Ich hab mal die FastDBL GitHub - ffruhr/fastdbl für eines unseres Gateways aufgesetzt. Scheint auch soweit alles zu funktionieren. Allerdings frage ich mich jetzt wie ich einen Knotenkey ausfindig machen kann um ihn dann zu sperren? Im syslog selbst tauchen die Keys nicht auf.
Feb 15 17:15:45 ffuegw1 fastd[23262]: new session with {a32feb7e10594d71} established using method `salsa2012+umac'.
Wie bekomme ich jetzt z.B. vom Knotennamen wie er in der Map erscheint oder dessen MAC Adresse eine Verbindung zu einen FastD Key hin, und vor allem wo kann ich beim laufenden fastd sehen welche Keys gerade in Verwendung sind?
Das „Debugging“ läuft über die Alfred Daten und den Unix Socket des fastd.
Sieh mal in mein Repo für die Daten des neuen Map Servers:
Die status.pl musst Du nach dem Aktivieren des Unix Socket auf Dein Gateway laden, dann kannst Du Dir die aktuellen Verbindungsdaten mit folgendem Aufruf ansehen:
Sehr junge jq Version, die mergen kann und sehr alte bat2nodes.py, joa.
Aber Du brauchst aus dem Repo tatsächlich nur die status.pl wgetten, Unix Socket wie oben beschrieben in der fastd.conf aktivieren und nen minütlichen cron Job mit dem Aufruf gegen die status.pl wie oben beschrieben anlegen, dann hast Du immer eine aktuelle /tmp/fastd.json in der Du dann nach Mac Adresse suchen kannst um an den Public Key zu kommen.
Du musst natürlich die VPN Mesh Mac Adresse für die Suche benutzen, diese findest Du in den Alfred Daten…fürs Panoptikum (unseren neuen Map Server im FFRL) wünsche ich mir fertige Funktionen, mit denen man sich sofort den Key passend zu einem Router ansehen kann.
