Posts by /dev/null

Also noch einmal zur (evtl. notwendigen) Klarstellung:

1. Der DNS-Eintrag in den Netzwerkeinstellungen legt (wie ja wohl allgemein bekannt und auch deutlich beschrieben), den durch den Router bekanntzugebenden DNS-Server für die Clients des Heimnetzes (ohne Gastnetz!) fest.

2. Mit dem Eintrag im Bereich Zugangsdaten/DNS können wir auch dem Gastnetz einen "anderen" DNS-Server zuweisen.

Und Gexle:

Du brauchst wirklich nicht, den IP-Bereich deines Hausnetzes zu anonymisieren. Es handelt sich um einen sogenannten privaten und von außen nicht erreichbaren (nicht routingfähigen) Adressbereich.

vy 73 de Peter

Hallo @all!

Ich habe in irgendeiner der vielen Anleitungen (zur unbound-Installation /Konfiguration) gelesen, dass der DNS-Eintrag im Bereich Zugangsdaten sowohl für die Fritz-Box selbst und auch für den Gastzugang gelten soll. Und in jener Anleitung wurde auch empfohlen, dort den pi-hole mit seinen beiden Adressen einzutragen.

Diese Einstellung ist ja für interessierte Nutzer in wenigen Minuten (oder Sekunden …) erledigt - und genauso schnell wieder rückgängig gemacht. Dann könnte (der daran interessierte Nutzer …) im GUI des pihole unter Query Log nachschauen, ob dort was angezeigt wird, wenn ein im Gastnetz angeschlossenes Gerät eine bestimmte DNS-Abfrage macht.

Ich selbst habe allerdings nie eine Notwendigkeit für diesen Test gehabt, zitiere also nur aus dem Gedächtnis, was ich in der Anleitung gelesen habe. Ich sehe auch keinerlei Vorteil darin, wenn dort der pi-hole eingetragen ist. Ganz im Gegenteil! Denn wenn der pi-hole mal "tot" sein sollte, ist eigentlich "alles tot".

Ich sehe auch keinerlei Nachteil darin, dort die DNS-Server des Providers stehenzulassen. Meine Geräte nutzen ja alle den/die Upstreamserver des pi-hole.

vy 73 de Peter

Ich finde es gut und auch sinnvoll, dass das total veraltete Protokoll "ftp" aus den Browern rausgeschmissen wird. Der Browser ist nun mal das Programm, mit welchem der Nutzer meistens im www unterwegs ist. Und dieses Programm, sollte per se möglichst sicher sein.

Und ja, das Befüllen des Contents einer Webseite erfolgt üblicherweise immer noch per ftp (muss nicht, ist aber weiterhin üblich). Und was spricht dagegen, dafür (speziell dafür!) ein genau dafür bestimmtes Programm, eben einen "ftp-Client" zu benutzen. Ich (purer Linuxer) nutze dafür das Programm "FileZilla" aber derartige Programme gibt es so ziemlich für alle Betriebssysteme.

OK?

MfG Peter

[OT]

Quote from framp

Eine Digitalkamera zum Formatieren zu nutzen ... warum nehme ich dann immer mein Linux

Nun, wir nehmen auch keine Digitalkamera für einen Screenshot

[/OT]

Alles klar.

Und ich werde jetzt die Zeit nutzen, und meinen Reserve-WG-Server (eine F!B 7412) auf "IPv6-only" umzustellen und für dich die Schlüssel zu generieren.

Ich weiß natürlich, dass man einen Beitrag im Bedarfsfall editieren sollte, habe mich aber bewusst für einen weiteren ergänzenden Beitrag entschieden.

1. Ich biete URI3L an, zum Testen mal für kurze Zeit einen Gastzugang auf meinem abgeschotteten Testserver bereitzustellen. Das hat für dich den Vorteil, wirklich zu prüfen, ob mit deinem I-Dingens (und der dir zugewiesenen IP) eine Verbindung über Wireguard aufgebaut wird. Du musst dazu lediglich eine Wireguard-App installieren und mir hier Bescheid geben. Ich schicke dir dann zeitnah per PN die Zugangsdaten. Für mich ist das völlig problemlos, denn es handelt sich wirklich um einen Zweig meines Netzes ohne "Ausgang" nach innen.
Ich werde dann auch für diese Zeit bewusst den IPv4-Zugang deaktivieren.

2. Der pi.hole ist für mich ein wichtiger Bestandteil der digitalen Sebstverteidigung (aber keinesfalls der einzige ...). Da ich auch außerhäusig von den Vorteilen eines "gereinigten" Netzes leben will, ist der pi-hole nicht nur als DNS im Router eingetragen, sondern er wird auch über das VPN als DNS verteilt. Test: ein ping auf adscale.de (einem bekannten Adserver) wird mit "localhost" aufgelöst . Bei mir trifft das natürlich auch für bestimmte Datenkraken (fazzebuch) zu.

3. Und JA, es ist möglich, auf einem Pi einen ganzen Sack voller Dienste einzurichten. Aber mit der Erfahrung meiner ehemaligen langjährigen beruflichen Tätigkeit in einem sehr speziellen Gebiet der IT ist es für mich ein absolutes Unding, auf einem Kryptogateway (und ein WG-Server ist ja grundsätzlich nichts anderes als ein solches!) noch andere Dienste laufen zu lassen. Gewisse Grundsätze gelten für mich eben auch als Pensionär lebenslang.

4. Als Ergänzung der von dir geplanten "eierlegenden Wollmichsau" empfehle ich, das kleine Programm "iperf3" auf diesem Pi zu installieren und dauerhaft als Dienst laufen zu lassen. Eine bessere Methode für (zeitlich) umfangreiche lokale Speedtests aber auch Speedtests über das VPN gibt es nicht.

URI3L:

hier nur zum Thema IPv6 und VPN:

Wireguard ist es so ziemlich egal, ob IPv4 oder IPv6 genutzt wird. Und das sowohl innerhalb des VPN-Tunnels als auch was den "Trägerkanal" betrifft.

Wenn ich mir die VPN-Logs meiner 8 in drei Ländern verteilten WG-Server betrachte, da wird fast immer und überall der/die Server via IPv6 angesprochen und der Tunnel aufgebaut. Damit betrachte ich einen "echten" Dual Stack für das VPN (zumindest für reinen Server-Server-Betrieb) nicht mehr als unbedingt erforderlich!

Es gibt, was die o.g. Aussage betrifft eine noch bestehende Ausnahme: Wenn der Client in einem Mobilnetz eingebucht ist, und der Provider immer noch nur IPv4-only anbietet. Das soll es wohl leider immer noch geben. Aber selbst eingebucht im Freifunk-Netz erhält jeder Client mindestens eine IPv6 und erreicht seinen Server auch bei DS-lite.

Es kommt also darauf an, was mit dem VPN bezweckt ist: einen LAN2LAN-Betrieb oder einen Client2LAN-Betrieb durchzuführen und hier, ob du "den richtigen Provider" hast.

Und die aktuelle WG-App im Playstore ist vom 07.05.2021

Also ist doch alles richtig geschrieben: eine Änderung der IP des Servers kann ggw. (bei einer aktiven Verbindung) noch nicht vom Android-Client erkannt werden. Dass der Client bei einer neu zu startenden Verbindung sich zuerst die IP holt, ist ein alter Hut. Das funktioniert ja auch prächtig und superschnell.

Bei einem (Linux-)Client ist das mit dem Wechsel der Server-IP problemlos per Script zu lösen. Und wenn die Wireguard-Macher das Problem für die Android-App noch nicht gelöst haben, dann können wir das wohl auch mit viel gutem Willen auch nicht.

Wir sollten einfach abwarten - und/oder die WG-Session täglich neu starten. Zumindest bis ...

Du hast ja - wie fast immer - grundsätzlich Recht.

Aber: Ich verwende auf meinen umgeflashten FritzBoxen das ganz normale OpenWrt (19.07.7 r11306-c4a6851c72) und ich habe auch weder Zeit noch Lust, da aus den Quellen irgend was sebst zu compilieren. Und ich habe auch persönlich keinen Grund das weiter zu verfolgen. Meine Clients (Smartphones und Notebooks) sind nachts im Flugmodus bzw. werden bei Bedarf neu gestartet und bei meinen Servern habe ich das per Script zufriedenstellend gelöst.

Immerhin besteht die reale Möglichkeit, dass alles in einem neuen Build der Firmware dann so wie wireguard.com beschrieben, wirklich funktioniert. Ich würde mich jedenfalls freuen - und warte mangels eigenem Bedarf einfach mal ab.

BTW:

Alle meine Partner haben echten Dualstack. Und ich selbst nutze aus Überzeugung (!) von Anfang an in meinem Heimnetz konsequent IPv6. Nur die Mobilfunkprovider sehen das noch nicht ganz so.

Naja, ich spiele ja gern. Aber jetzt gehen wir erst mal auf Nahrungssuche ... .

So, nach einer weiteren halben Stunde "DLM-Wartezeit" habe ich mir wieder eine neue IP geholt.

Diesmal mit aktiviertem Keep-Alive auf Server und Client.

Nach nunmehr über 20 Minuten Wartezeit wurde kein neuer Tunnel aufgebaut.

Fazit: noch gibt es (außer einem clientseitigen Erkennen der neuen IP des Servers und automatischem Neustart der Verbindung - was aber mir auf dem Androiden nicht möglich ist) keine Lösung.

Für mich ist dieses Thema hiermit leider momentan beendet. So sehr ich mich gefreut hätte ... .

MfG Peter

edit:

Hinweis - nach dem Editieren der Einstellungen der WG-App erfolgt automatisch ein Neustart der Verbindung. Ich hatte mich schon gefreut, als ich KA aktiviert hatte und die Verbindung sofort wieder stand. Aber wie oben beschrieben, war das leider nur ein Nebeneffekt.

So, und nun eine Ergänzung.

Ich habe mir getraut, nach Ablauf des "DLM-Reaktionsfensters" einen 5. Versuch zum Erhalt einer neuen IP zu bekommen. Diesmal hat es funktioniert. Wie zu erwarten, war der Tunnel sofort weg.

Ich habe dann bewusst 1,5 Stunden gewartet und sehe in dem GUI des Servers, dass auch nach dieser Zeit kein neuer Tunnel aufgebaut wurde. Genau so, wie ich es erwartet habe.

Weil ich gern herumspiele, habe ich vor dem Neustart der Verbindung durch den Client in dessen GUI ebenfalls (entgegen der deuitlichen Warnung - "Nicht empfohlen") ebenfalls KA mit 25s aktiviert.

Mal schauen, was nach der nächsten Zwangstrennung passiert. Man soll ja die Hoffnung nie aufgeben!

Einen wunderschönen guten Morgen!

PersistentKeepAlive kenne ich als eine Einstellung, welche aller n Sekunden (hier: 25) ein Paket sendet, damit eine eventuell ungenutzte Verbindung nicht zusammenbricht.

Hier geht es nach meinem Verständnis nur darum, dass Portweiterleitungen (IPv4) und geöffnete Ports in der Firewall (IPv6) nicht deaktiviert werden.

Bei der Geschwätzigkeit eines Androiden, der wohl nie zur Ruhe kommt, dürfte das auch nicht nötig sein.

Von Seiten der Entwickler wird empfohlen, das deaktiviert zu lassen (default = 0) bzw. nur bei Verbindungen zwischen WG-Servern zu aktivieren.

Deshalb war bei mir bei den Server-Verbindungen 25s und bei den Clients 0 eingetragen.

Ich habe vor einer halben Stunde auch bei der Verbindung zu meinem Schlau-Fernsprechapparat bewusst mal das KA aktiviert (25s). Allerdings ist es mir heute auch nach vier Versuchen nicht gelungen nur mit "Neu verbinden" eine andere IP zu bekommen. Da ich meine DSL-Verbindung (extrem lange TAL und out of the Box nur 85Mbit/s von den bezahlten 100) durch eine kleine Manipulation in der GUI der FritzBox auf (stabile!) 105Mbit/s zu "pimpen", möchte ich jeden Neustart der F!B vermeiden um das DLM keinesfalls zu provizieren. Aber die nächste Zwangstrennung kommt gewiss und ich werde mich melden.

Ich wünsche einen schönen Tag!

MfG Peter

Autsch ...

Das kann ich mir gerne morgen mal vornehmen. Heute will der Alte nicht mehr ...

Das "Problem" ist, dass ich openWRT auf meinen 4040 oder 7412-FritzBoxen zu laufen habe. Und auf meiner 4040 habe ich die Verbindungen zu allen meinen weiteren 7 verteilten Servern und auch noch alle meine eigenen Clients (3 Smartphones und 2 Notebooks und einige Gäste) konfiguriert. Um dann dort Veränderungen vorzunehmen, will ich ausgeschlafen sein. Ich melde mich aber morgen im Laufe des Tages.

Der auf den Server zugreifende Client (!) verliert die Verbindung, wenn der Server seine IP ändert.

Der Client muss also ständig prüfen, ob die ihm bekannte IP des Servers (letzte Verbindung oder letzte Prüfung) noch mit der aus der aus der aktuellen Namensauflösung über DynDNS (also der aktuellen Prüfung) übereinstimmt. Und dann startet der Client bei Nichtübereinstimmung den Dienst neu. Er nimmt also die Verbindung zur neuen IP aktiv auf.

Bei meinen Servern (Verbindung zwischen den Servern, es werden die IP der jeweiligen Gegenstellen geprüft) ist das kein Problem. Sind ja alles Linux-Rechner. Auch bei einem Linux-Client ist ein derartiges Script kein Problem. Und wie schon geschrieben, ist bei einer reinen Serverkopplung ein Cronjob kurz nach der üblichen Zwangstrennung der Gegenstelle + Zeit für DynDNS-Aktualisierung völlig ausreichend, denn in der Nacht fällt das kaum auf. Zumindest, wenn es nur um die (planbare) Zwangstrennung geht.

Aber auf einem Androiden kann ich das nicht. Zumindest auf meinem Galaxy S10+ unter Android 11 (Patchstand Juni 2021) sehe ich dazu keine Möglichkeit.

Was ich allerdings nicht verstehe ist, warum von Seiten der Entwickler von Wireguard oder zumindest der WG-App nichts kommt. Eigentlich sollte das doch möglich sein, auch unter Android etwas derartiges zu coden.

BTW:

Ich habe jetzt mal ganz bewusst eine neue IP für meine Fritz!Box provoziert. Wie zu erwarten war der Tunnel auf dem Androiden weg und kam auch von alleine nicht wieder. Den WG-Tunnel (einen meiner vorbereiteten 8 Tunnel) kurz deaktiviert und schon stand der Tunnel wieder. Also immer noch der übliche "Handbetrieb". Und JA, ich kann damit leben.

Viel Erfolg!

Peter

Hallo,

ich betreibe schon recht lange ein "gar nicht mehr so kleines" Netz aus mittlerweile 8 WG-Servern, verteilt in drei EU-Ländern. Als Hardware nutze ich allerdings keinen Pi mehr, aber das spielt hier keine Rolle.

Es ist eine Tatsache, dass 1&1 (aus kaum nachvollziehbaren Gründen) weiterhin auf die Zwangstrennung nach 24h beharrt.

Und es ist auch eine Tatsache, dass eine Verbindung (also ein VPN-Tunnel) zwar beim Client (also Smartphone oder Notebook) beim Wechsel des Trägerkanals (heimisches WLAN - Mobilfunk - fremdes WLAN - und wieder zurück zum heimischen WLAN) blitzschnell und fast unbemerkt wieder aufgebaut wird. Allerdings, wenn der Server bedingt durch Zwangstrennung o.ä. eine andere IP bekommt, startet der Tunnel nicht mehr von alleine. Obwohl natürlich per DynDNS die neue IP des Servers recht schnell wieder bekanntgegeben wird.

Bei meinen Servern (also Verbindung zwischen den Servern) habe ich das Problem gelöst, in dem ich ein Script geschrieben habe, welches aller paar Sekunden die letzte bekannte IP mit der aktuell vorhandenen/zugewiesenen IP vergleicht und bei Nichtübereinstimmung den Dienst neu startet. Geht sehr schnell und fällt kaum auf. Auch ein cronjob, welcher in der Nacht den wg-Dienst neu startet, macht das. Diese Lösung funktioniert natürlich auch bei einem außerhäusig betriebenen (Linux-)Notebook.

Beim Betrieb eines Androiden habe ich allerdings keine Möglichkeit gefunden, dieses irgendwie zu implementieren. Und rooten will ich mein Smartphone auch nicht. Eine offizielle Lösung seitens der WG-Entwickler ist mir leider nicht bekannt.

Da ich (anders als die letzten 40 Jahre vorher) nicht mehr ständig erreichbar sein muss, habe ich mir angewöhnt, mein Smartphone abends in den Flugmodus zu versetzen und diesen am Morgen wieder zu deaktivieren. => Problem (für mich) gelöst.

Ansonsten ist mein Smartphone immer und überall (also auch @home) über VPN mit meinem eigenen WG-Server verbunden. Das hauptsächlich, weil ich unterwegs gerne den bei uns gut ausgebauten (unverschlüsselten) Freifunk benutze.

Frage:

Ist "Das wars" der neue Alias für das, was wir früher mal mit "Danke" ausgedrückt haben?

Fragen darf man ja noch.

MfG Peter

Man möge mir verzeihen, dass ich mich hier noch einmal melden

Der pi-hole wirkt ja, indem er bestimmte "unerwünschte" Servernamen auf "localhost" auflöst.

Also wenn durch eine seiner Filterlisten irgend etwas Unerwünschtes erkannt wird, wird diese Seite nicht aufgerufen.

(Bsp.: eine ICMP-Anfrage auf "adscale.de" wird von "localhost" beantwortet. Das ist der bei mir übliche Test)

Soweit ich festgestellt habe, ist die Werbung bei YT direkt von YT eingespielt, kommt also von der gleichen IP. Und da hilft keine DNS-Filterung.

BTW: Ich bin kein großer Youtube-Konsument. Das mit der Werbung KANN, MUSS aber nicht immer so sein. Es war nur bei den wenigen meiner Besuche so.)

vy 73 de Peter

Und was war an meiner Antwort falsch?

Die 10 Minuten, die der TE für eine eigene Antwort benötigt hätte, liegen beträchtlich unter der Zeit, die wir alle für die nächsten 8 Antworten aufgewandt haben.

Passende Antwort auf "k.T....":

Probiers doch einfach mal aus. Den Raspi 2 und eine ungenutzte SD-Karte wirst du wohl herumzuliegen haben und ein pi-hole ist in 10 Minuten installiert.