Wenns ein Spezialserver ist, evtl auch wenn nicht, hier ins Bieteforum rein und Du bist ihn auch früher los. Dann Kündigung rückgängig machen und via Inhaberwechsel übertragen.
Beiträge von TBT
-
-
Schick mir Deine ISO FTP Server Zugangsdaten per PN und ich schiebs Dir drauf. Sind ja eh nur temporäre Zugangsdaten, Deinen Accountzugang will ist natürlich nicht haben. Habe hier eine sehr schnelle Verbindung. Willst Du DE oder EN?
-
Ok, also immer noch Allgemeinpositionen und "Du bist zu dumm um den riesigen Fehler zu sehen" Kommentare. Kein einziger echter technischer Hinweis in diesem ganzen Thread.
Ich hab schon lange keine Lust mehr auf eine solche Gummidiskussion, aber habe immer noch gehofft, dass da mal was substantielles kommt. Aber ist nicht.
Ich bin raus.
-
Weder noch: Über die durchgereichte Grafikkarte an einem eigenen Bildschirm. Und mit durchgereichten USB-Eingabegeräten.
Ah ok. Klar, das Thema war ja VT-D passthrough. Ist mir bei den 39 Posts entfallen.
-
Die
Bereits in #14 und noch mehr in #16 ist das Problem präzise beschrieben. Ich mache zum wiederholten Male darauf aufmerksam, dass ihr Beiträge lesen solltet, bevor ihr Statements abgebt.
Die beiden Posts sind eben solche Allgemeinsätze ohne wirklich Nennung des Problems mit dem 100 Netz oder wie man es, Deiner Meinung nach, hätte besser machen sollen (einer Lösung) oder welche Netzwerkbereiche mit welcher Begründung man statt dessen hätte verwenden sollen.
Zudem unterstellst Du Tailscale ständig, "bei Fehlern wegen der Netzwerkwahl Daten zu leaken". Als Softwareentwickler kannst Du Dir ja gerne https://github.com/tailscale/tailscale (ist open source) ansehen und uns Fehler aufzeigen.
Die IP Ebene ist doch bei verschlüsselten Wireguard Tunneln nahezu egal. Hat man die Schlüssel nicht, kommt man nicht rein, egal ob man nun die IP sieht oder nicht.
Siehe How Tailscale works · Tailscale .
Zitate:
Zitatthe coordination server (key drop box) protects nodes by giving each node the public keys of only the nodes that are supposed to connect to it. Other Internet computers are unable to even request a connection, because without the right public key in the list, their encrypted packets cannot be decoded. It’s like the unauthorized machines don’t even exist. This is a very powerful protection model; it prevents virtually any kind of protocol-level attack. As a result, Tailscale is especially good at protecting legacy, non-web based services that are no longer maintained or receiving updates.
Man könnte sogar sagen, dass Services wie TS die Sicherheit erhöhen, denn es erstellt
Zitatpoint-to-point fully encrypted connections (no unencrypted traffic carried over any LAN)
d.h. TS ist sogar sicherer, als wenn sich Client und Server im LAN unterhalten, bzw. kann sogar die Sicherheit im LAN erhöhen.
-
Wird die VM dann über den Browser (Proxmox VNC) oder RDP verwendet? Und wofür braucht man noch eine Windows XP VM? Alte Spiele?
-
das hast leider falsch aufgefasst
Ach Quatsch. Dieses Bild direkt unter meinem Zitat. Ist eine Beleidigung. Punkt. Und sie wurde nach Beanstandung durch die Moderation erneut hochgeladen.
-
Ich habe lediglich gesagt, dass es ein Risiko für eine missbräuchliche oder irrtümliche Verschaltung von Endpunkten gibt, und wenn das passiert (aus was für Gründen auch immer), dann sorgt das System der Adressverteilung für ein erhöhtes Risiko für einen unerwünschten Datenfluss. Nicht mehr und nicht weniger.
Und WARUM sollte das so sein? Ich habe noch nicht ein sinnvolles technisches Argument gehört aber schon viele Begründungen geliefert wieso das nicht so ist. Stell doch die ständig angesprochenen aber nie belegten Schwachpunkte des verwandten Systems der Adressverteilung dar.
Wie ich schon mal sagte, offenbar habt ihr eine vollkommen falsche Auffassung von der Problemstellung.
Du hast das Problem niemals technisch begründet und nachvollziehbar dargestellt. Nur immer mit Allgemeinpositionen im Nebel rumgewabert.
-
es ist immer noch unklar, ob Du ein Netzwerkdiagramm oder eine Diensteansicht machen willst.
Als Netzwerkdiagramm ist die Sache sehr einfach: alle verkabelten Geräte mit 192.168.1.X hängen gleichberechtigt nebeneinander an Switches, alle wireless Geräte mit 192.168.1.X sind im gleichen Netz, ergo auch eigentlich gleichberechtigt, aber halt nicht mit Kabel (Linie), sondern z.B. gestrichelter Linie. Auch sollte man irgendwo eine Legende beschriften, d.h. hinschreiben was eine durchgezogene Linie und eine gestrichelte Linie bedeutet.
Dein Pi-Hole hat nicht die "zentrale" Aufgabe, die Du ihm immer noch in der Grafik zuschreibst. Der Raspi mit Pihole drauf ist einfach ein Netzwerkgerät gleichberechtigt mit allen anderen.
Zudem solltest Du Überkreuzungen von Linien vermeiden und unnötige Verbindungen nicht ziehen. Sofern Du keine LAN Direktverbindung zwischen CUPS Sever und Drucker hast (also direkt, nicht über den Switch) gehört da keine Linie hin. Zudem kann es nur logisch falsch sein, zwischen dem Switch und dem MinisForum eine WLAN Verbindung einzuzeichnen. Entweder ist es per WLAN angebunden, dann gehörts unten rechts an den Asus, oder es ist per LAN angebunden, dann gehörts mit durchgezogener Linie an den Switch.
Deine konzeptionelle Arbeit ist sinnvoll und nicht nur Malerei, denn erst wenn Du einen Netzwerkaufbau verstanden hast, weißt Du wo Du ansetzen musst um etwas in eine gewünschte Richtung zu verändern. Ansonsten ist alles nur Stochern im Nebel und Du musst Leute fragen, weil Du Den Aufbau nicht verstanden hast.
-
- Windows 7: Läuft ohne Probleme, alles sehr zufriedenstellend und flüssig.
- Windows XP: BSOD beim Windows Installer, da komme ich vorläufig nicht weiter.
Aber bitte ohne Zugriff aufs Internet.
- Windows 7: Läuft ohne Probleme, alles sehr zufriedenstellend und flüssig.
-
Ich denke, dass ich die Technologie von Tailscale recht gut kenne, da wir mit ähnlichen Verfahren arbeiten.
Wir entwickeln industrielle Bedienlösungen für mobile Arbeitsmaschinen. Dazu gehören neben den Bediengeräten (robuste Linux Tablets) auch verschiedene Kommunikationsmodule für die Cloudanbindung und die Infield-Kommunikation. Die Herausforderung ist, dass diese Maschinen dynamisch für einen Auftrag in einem Netz zusammenarbeiten müssen, ohne dass sich die Netze untereinander gegenseitig beeinflussen können (wir nennen das "Fence").
...
Im Grunde arbeiten wir also wie Tailscale, nur haben wir keine Kunden-Netze, sondern Einsatz-Netze. Wir haben zusätzlich das Problem, dass die Netze jederzeit dynamisch generiert, verändert und terminiert werden und trotzdem gekapselt sein müssen, während die Tailscale Kunden-Netze ja relativ statisch sind. Nicht zuletzt können wir uns nicht auf eine Cloud verlassen für die Netzkonfiguration. Dabei kann natürlich der Internetzugang in einem Einsatz-Netz mal verfügbar sein und mal nicht (in Abhängigkeit der teilnehmenden Maschinen).
Du kennst nicht die Technologie von Tailscale, sondern Du nimmst an, dass sie den von Dir verwendeten Techniken (die Du nicht näher spezifiziert hast) ähnlich sind. Das kann sein, oder halt auch nicht. Können wir von außen natürlich nicht nachvollziehen.
Du beschreibst auch den wesentlichen Unterschied, dass Ihr Euch nicht auf eine Cloud verlassen könnt - Tailscale kann das halt schon, das ist ja der Witz an einem controllerbasierten VPN. Da ist der Controller die einzige Autorität für die IP Vergabe und die Berechtigungen. Bei Euch scheint das ein verteilter Ansatz zu sein, ergo schon mal keine ähnliche Architektur.
Von daher glaube ich, ganz gut beurteilen zu können, mit welchen Herausforderungen Tailscale so zu kämpfen hat und was die Folgen ihrer Addresszusweisung sind.
Ich seh noch nichts überzeugendes. Du hast Deine - andere - Netzwerkanwendung geschildert und dann gemeint, dass Tailscale das ja so ähnlich machen müsste. Das ist alles.
Nein, muss ich nicht. Selbst Tailscale hat nie behauptet, dass ihr Netz 100% sicher ist, und auch ihr bestreitet nicht, dass die üblichen IT Risiken hier greifen. Ein Netz ist solange unsicher, bis die Sicherheit bewiesen ist, nicht umgekehrt.
True. Aber wieso sollte dieser Sachverhalt generell gegen Tailscale sprechen?
Ich habe sie nicht ignoriert, lese es noch mal nach. Ich habe geantwortet: Nicht die Verfahren von Wireguard sind das Problem, sondern die Konfiguration. Was nützt dir die beste Zertifikatsarchitektur, wenn ein Controller-Algorithmus die Zertifikate an die falschen Endgeräte verteilt?
Und wieso stellst Du den Service unter Generalverdacht, dass genau das "aufgrund der IP Zuordnung im 100.X.X.X Netz" passieren müsse? Wenn der Controller auch nur einmal Käse macht, dann wird das 1. sofort auffallen und 2. kann Tailscale dann zusperren. So einfach ist das.
-
und zum Glück gibts nur eine verschwindend kleine Anzahl an E-KFZs;
Mindestens 850.000 ePKWs in DE (Ende 2022). Das ist noch nicht allzuviel ggüber den 48,5 Mio. an "installierter Basis".
Allerdings waren laut ADAC in 2022 in DE ca 50% aller zugelassenen PKWs mit einem alternativen Antrieb ausgestattet (dazu zählen leider auch Hybride). Ein Plus an Zulassungen findet man praktisch nur mehr bei eAutos.
weil eines sollte klar sein, wenn jeder E-Herd auch nur mit rund ¼ seiner Anschlußleistung
schlagartig zu Mittag diese Leistung anfordert heißt das bei dieser Größenordnung,
dass 50 Mio. mal 2½ kW macht 125 Gigawatt; da würden ma wirklich jeden Tag nur knapp am Blackout vorbeischrammen;
mögen es auch nur 25 Mio. E-Herde sein, sinds immer noch 65,5 Gigawatt od. mehr als 60 AKW-Äquivalente;
sind es nur 10 Mio. E-Herde welche die gesamte Anschlußleistung anfordern sind es 100 Gigawatt od. mehr als 90 AKW-Äquivalente;
Du weißt also nicht, wie viele Haushalte es in DE gibt, auch wenn die Antwort nur eine Suche entfernt ist. Es waren 2021 40,6 Millionen. Ein Kochfeld braucht zwischen 1 und 5,5kW, ein Herd nochmal um die 4kW. Je nachdem wie viel Platten man braucht und wie viele gleichzeitig an sind. Kommt schon vor, dass alles gleichzeitig an ist.
Bei einer installierten Leistung von rund 232.000 MW in DE ist das kein Problem. Ebenso ist es aber auch kein Problem, eine größere Zahl von eAutos mit dem vorhandenen Netz und einem niedrigeren Gleichzeitigkeitsfaktor als eHerde abzudecken. Es kommen perspektivisch immer mehr eAutos dazu, der Netzausbau muss daran angepasst vorangetrieben werden. Abschaltbare Lasten und innovative Tarifmodelle basierend auf Smartmetern können ihr übriges dazu tun.
Zu Deiner unnötigen persönlichen Beleidigung, die ich im Übrigen gemeldet habe, werde ich mich nicht weiter äußern. Im Unterschied zu Dir mache ich mir immerhin die Mühe, meine Behauptungen zu belegen...
EDIT: da wurde die Beleidigung von der Moderation entfernt, aber Herr mainziman macht sie wieder rein. Nochmals gemeldet. Schon dreist.
-
Korrekt.
Ist mir bekannt. Dieser wird für den jeweiligen Fall aus Erfahrungswerten gebildet. Laut Wikipedia für Wohnungen nach DIN 18015-1. Wie oft wird eine DIN angepasst? Wieviel Erfahrung gibt es schon mit E-Autos im großen Stil, oder wird da einfach hoch extrapoliert?
https://de.wikipedia.org/wiki/Gleichzei…on_Elektroautos bringt ja hier einige Anhaltspunkte und schreibt, dass "Erfahrungen noch gesammelt werden". Das geschilderte Experiment lässt jedenfalls einen eher geringen Gleichzeitigkeitsfaktor vermuten (max 0,5 in 0,1% der Zeit, d.h. quasi immer liegt er darunter). Das würde sich auch mit meiner dreijährigen Lade-Erfahrung decken.
Verstehe mich nicht falsch. Das Problem liegt doch momentan nicht in der theoretischen Möglichkeit der Regulierung, sondern in der praktischen Umsetzung dessen.
Die praktische Umsetzung passiert schon heute täglich, aber vermutlich anders als Du denkst. Wie beschrieben kann man für mehrere Ladepunkte eine, z.B. an den Hausanschluss angepasste, maximale Leistung vergeben, die das Netz drumherum nicht überfordert. Da Ladepunkte gegenüber dem Netzbetreiber ohnehin mitteilungs- oder über 22kW genehmigungspflichtig sind, kommt da nicht "plötzlich" was unerwartetes, sondern der Netzbetreiber weiß Bescheid und plant entsprechend.
Zum Glück wurde meiner Wohnung noch kein Smartmeter verpasst. Bürokraten lieben Abschaltbutton, solange Sie sich nicht selbst abschalten müssen. Werden dann auch konsequent E-Autos Remote stillgelegt, wenn es mal klemmt?
Hier werden zwei Dinge verquickt, die nichts miteinander zu tun haben, zudem scheint es falsche Annahmen hinsichtlich abschaltbarer Lasten zu geben.
Ein Smartmeter hat erst einmal keine Abschaltvorrichtung, sondern sendet "nur" eine Verbrauchskurve. Ein solches Smartmeter (ich habe auch noch keins, der Netzbetreiber wollte schlicht noch keines verbauen) kann zeit- und lastabhängige neue Tarifmodelle ermöglichen, in denen z.B. mit günstigeren Preisen honoriert wird, wenn ein flexibler Verbraucher seinen Strombedarf in Zeiten mit niedriger Last (z.B. Nachtstunden) oder Stromüberfluss verschiebt (sonniger, windiger Sommertag um 12 Uhr). Das ist im Sinne der Energiewende sehr zu begrüßen.
Das Lastmanagement der Ladepunkte kann übrigens auch zum "PV Überschussladen" verwendet werden, d.h. es wird immer nur so viel Strom ins Auto geladen, wie gerade im Haushalt zu viel da ist und sonst ins Netz abgegeben würde.
Für abschaltbare Lasten legt man sich i.d.R. einen eigenen Zähler, an dem wirklich nur Geräte hängen, die abschaltbar sind, z.B. das eAuto oder auch mehrere. Mitnichten wird ein ganzer Hausanschluss als "abschaltbare Last" betrieben und irgendwann ist das Licht aus.
Der Mensch ist ein Herdentier und hat seine Routinen. Ein E-Herd hat seine "Peakzeit" und ein E-Auto hat sie auch, auch wenn man versucht dessen Lastzeiten im Netz zu strecken.
Liegt an den Netzbetreibern / Stromanbietern, hier ein netzförderliches Verhalten preislich zu incentivieren.
Aber ja, man kann dann Dinge abschalten, die gerade nicht passen oder keine Prio haben. Ich ahne schon was dann dabei rauskommt.
Was soll dabei rauskommen? Bei abschaltbaren Lasten wird oftmals gar nicht und wenn dann z.B. für 1-2 Stunden pro Tag abgeschaltet. Für ein eAuto ist das komplett irrelevant.
-
Natürlich. Wenn die Argumente ausgehen, wird es persönlich. Das hatten wir heute schon mal.
Du posaunst hier im Brustton der Überzeugung raus, dass Tailscale wegen seiner Netzwerkarchitektur gar nicht sicher sein kann ohne sie im Detail zu kennen oder ein Experte dafür zu sein. Als Begründung kommen Allgemeinsätze (alle Software hat Fehler), Du belegst Deine Aussagen nicht, ignorierst Belege und Links die Dir gebracht werden und pickst Dir Aussagen selektiv raus. Da kann man schon mal fuchsig werden...
Dass sie nur 1x vergeben wird ist ja das Problem. Denn nur dadurch wird es unsicherer.
Beispiel für Allgemeinsatz ohne jeglichen Beleg oder technische Grundlage.
Wenn ihr euch so sicher seid, dann beweist mir doch bitte mal, dass es theoretisch unmöglich ist, dass sich zwei Tailscale Geräte unerwünscht erreichen können, sei es aufgrund eines Fehlers, einer Lücke oder warum auch immer.
Du stellst die Behauptung auf, dass Tailscale inhärent unsicher ist. Diesen "Beweis" musst also erst mal Du führen. Wir müssen hier gar nichts beweisen. Ich habe Dich bereits auf die Zertifikatsarchitektur und Funktionsweise von Wireguard hingewiesen und Du hast sie ignoriert.
Nur um das hier auch mal einzustreuen: ich nutze Tailscale nicht, da mir die kostenfreie Variante zu restriktiv ist, sondern verwende Zerotier und Netbird, die vom Prinzip her aber Ähnlichkeiten haben (controllerbasierte VPN Lösungen).
-
Den Vergleich Herd mit E-Auto halte ich doch eher für einen Vergleich mit Äpfel und Birnen.
Der Punkt mit der Uhrzeit kommt noch oben drauf.
Fürs Netz sind beides Stromverbraucher, die mehrere kW abfordern.
Hier kommt der Gleichzeitigkeitsfaktor ( Gleichzeitigkeitsfaktor – Wikipedia ) ins Spiel. Während der eHerd hier zur Mittagszeit einen eher hohen Gleichzeitigkeitsfaktor hat (Mittags kochen die Leute halt) und damit das Netz und der Anschluss dafür ausgelegt werden muss, haben eAutos einen eher niedrigeren GF, da beileibe nicht immer alle eAutos gleichzeitig geladen werden und diese Ladungen auch noch über den ganzen Tag hinweg und auch mitten in der Nacht passieren können, idealerweise also zu Zeiten in denen die Grundlast sehr niedrig ist. So habe ich meine Autoladung auf 2:30 Uhr in der Früh gelegt, da dort die Grundlast sehr niedrig und der Rest des Hauses auf seinem Minimum ist (auch über Stunden hinweg).
Zudem kann man mit Ladepunkten auch Lastmanagement konfigurierern, so dass z.B. zwei Ladepunkte, die jeweils 11kW max könnten, nur zusammen 11kW max verwenden (so ist das bei mir). Dadurch werden trotzdem zwei eAutos geladen (meist mit Höchstgeschwindigkeit, siehe GF) ohne dass man sich einen Stecker teilen muss, aber das Netz wird zu jeder Zeit nicht mit mehr als 11kW durch die Ladung belastet.
Und zuletzt gibt es noch die Möglichkeit der "abschaltbaren Lasten". Diese Funktion mussten alle geförderten Ladepunkte unterstützen. Damit könnten die Netzbetreiber theoretisch Ladepunkte zeitweilig abschalten. Dies ist jedoch nicht wirklich technisch in den meisten Netzen irgendwie umgesetzt, aber es KÖNNTE verwendet werden. Auch hier ist es wiederum egal, ob das Auto 2 Stunden früher oder später geladen wird.
Im Vergleich zu einem Herd, bei dem man dem deutschlandweiten Mittagspeak kaum auskommt (außer man kocht off-peak), sind eAutos hier vieeeel flexibler und werden daher die Netze nicht überlasten.
-
Vorab: bitte mach doch bei solchen Themen ein eigenes Thema auf...
- Der Gigacube ist mein "Modem", lokal 192.168.8.1, hängt am WAN-Port vom Asus. CG-NAT, also keine öffentliche IPv4
Der Gigacube ist in Deinem Fall kein reines Modem, denn das würde die öffentliche IP, die es zugeteilt bekommt, an das nachfolgende Gerät weitergeben, sondern ein Modem + Router, der von 100.X.X.X (vermutlich bei CG NAT) in das 192.168.8.X Netzwerk routet. Wäre er ein reines Modem, hätte der Asus die 100.X.X.X IP weitergegeben bekommen.
- 3 Raspberry4 hängen per LAN-Kabel am Asus (statische IP), u.a. der mit 192.168.1.2 , mit Pihole, der im Asus als DNS eingetragen ist
- am 4. LAN-Port vom Asus ist der Switch, wo derzeit nur mein Haupt-PC und der Proxmox-MinisForum per Kabel angeschlossen ist.
Dann sind diese Geräte ohne "Durchleitung" wie in Deinem Bild vermutbar einfach alle parallel an einem Switch (Bild: Linie vom Asus zum Switch, an diesem gleichberechtigt die 3 Rasperries, der Haupt PC und der MinisForum. Denn netzwerktechnisch sind die gleich, egal ob sie nun am Switch des Asus oder an einem separaten Switch hängen.
- der Rest (Drucker, Scanner, Smartphone, Tablet, Notebook) ist im WLAN
Wenn diese am Asus hängen, wäre von diesem ein Wellensymbol weggehend und eingehend auf Seiten dieser Geräte grafisch einzufügen. Du könntest hierfür solche Icons verwenden: https://de.vecteezy.com/vektorkunst/44…or-illustration . Das 2. oder 4. Icon auf dem Link könnte einen AP (Asus) darstellen und die anderen nimmt man auf der Empfangsseite her.
-
Das ist mir schon klar. So soll es sein, und im Normalfall wird es auch so sein. Ich rede aber nicht vom Normalfall, ich rede vom Fehlerfall.
Weil ich selber Softwareentwickler bin. IT Security ist im Grunde eine einzige große Risikoanalyse. Welches Risiko bin ich bereit, in Kauf zu nehmen? Welche Rolle spielen die kommerziellen Aspekte dabei? Wenn ihr mir jetzt erzählen wollt, dass das Risiko in diesem Fall 0 ist, dann kann ich nur sagen: träumt weiter. Ob das Risiko akzeptabel ist? Für euch mag es das sein, und das werfe ich euch auch gar nicht vor. Für mich ist es das nicht.
Dude, dann darfst Du keinerlei Software, ja noch nicht einmal einen Computer verwenden, denn all das könnte Fehler haben (hats ja auch). Die Logik ist doch in diesem Zusammenhang komplett sinnfrei und kann gegen jegliche Software, im Prinzip gegen ALLES verwendet werden. Als Softwareentwickler solltest Du es besser wissen. Und Softwareentwickler müssen nicht unbedingt Ahnung von Networking haben. QED.
Nein, aber die Konfiguration kann fehlerhaft sein.
Vielen Dank, sehr gutes Beispiel. Genau da gibt es je mehrere Beispiele, wo Konfigurationsfehler bei den Internetprovidern dazu führten, dass plötzlich Kunden des gleichen Providers die Netzwerkumgebung anderer Kunden sehen konnten.
https://www.heise.de/newsticker/mel…rft-153559.html
Exakt davon rede ich.
Einen Fall des Zusammentreffens von Fehlkonfiguration des DSL Anbieters und das direkte Betreiben eines PCs an einem Modem (der PC bekommt die öffentliche IP, MACHT ABSOLUT NIEMAND) aus 2007 kombiniert mit passwortlosen Freigaben vergleichst Du mit controllerbasiertem Wireguard VPN?
Etwas noch älteres und unwahrscheinlicheres hast Du nicht mehr gefunden? Was hat denn bitte das mit Tailscales Technik zu tun? Exakt GAR NICHTS.
Wenn es am Ende nur ein großes privates Netz ist, keiner. Wenn es viele kleine mit überlappenden Adressen sind, ist es ein gewaltiger Unterschied, weil es genau den Risikovektor, den ich anspreche, ausschaltet.
Tailscale sagt, dass jede(r) eine "unique" IP Adresse bekommt. Also nehme ich an, dass jede IP aus diesem 100.X.X.X Netz nur genau 1x vergeben wird. Wo ist dabei Dein Problem? Alles andere was ich geschrieben habe, hast Du übrigens einfach ignoriert.
Nebenbei ist es nicht "ein großes privates Netz", sondern viele viele kleine, individuelle OHNE überlappende Adressen und mit keybasiertem Routing. Du solltest Dich dringend mit der Funktionsweise von Wireguard auseinandersetzen, insbesondere mit dessen https://www.wireguard.com/#cryptokey-routing .
-
Das ist vermutlich von vorne bis hinten verkehrt und unvollständig. Du routest doch nicht Deinen kompletten Traffic durch Dein Pi-Hole. Sieht aber danach aus. Alle internen Geräte sind erst mal (logisch) an einem Switch hängende gleichberechtigte Netzwerkendpunkte.
WLAN zeichnet man häufig so, dass es mit mehren Bögen gezeichnet wird und bei den WLAN Endgeräten werden diese Bögen umgedreht. Verkabelte Geräte mit Linie (ggfalls noch Geschwindigkeitsangabe "1G").
Dein Gigacube hat sicherlich eine (wechselnde) Provider NAT IP Adresse (die man darstellen könnte) und eine feste oder DCHP vergebene private IP (hoffentlich aus einem anderen Subnetz als der Asus), über die die Internetanbindung vermittelt wird. Anhand des Bildes würde man annehmen dass der Asus der eigentliche Router im Netz ist und die IPs vergibt (da da die Linie aus dem Internet durch geht) Du hast also doppeltes NAT, was gerne mal Probleme bereitet. Außer Du nutzt den Asus nur als Accesspoint, in einem solchen Fall wäre die Grafik falsch und der Asus hinge nur parallel an einem Switch.
Die Schwierigkeiten die Du mit der Grafik hast, zeigen m.E. wieso Du allgemein Probleme mit diversen Anwendungen und Vorhaben hast, denn die Basics sind eher nicht da (no front, nur eine Feststellung).
-
Ich würde eben nicht alle Kundenanschlüsse in ein großes 100.x.y.z/10 Netz verfrachten.
Die Beschreibung auf der Tailscale Seite und die Art der Adressverteilung lässt diesen Schluss zu. Offenbar werden alle Kundengeräte nach welchem Algorithmus auch immer aus einem großen 100.x/10 Netz mit Adressen versorgt und dann in kundenspezifischen Gruppen zusammengefasst.
Laut How Tailscale assigns IP addresses · Tailscale scheint jedes Gerät sein eigenes IP Netz maßgeschneidert zu bekommen, das Beispiel 100.108.38.123/32 auf der verlinkten Seite lässt genau eine einzige IP Adresse zu: 100.108.38.123.
Ein Tailnet ist eine abgeschlossene Einheit, die nur Clients miteinander kommunizieren lässt, die im gleichen Tailnet sind. Die Verbindungen zwischen den Geräten sind controllervermittelte Mesh Wireguard Tunnel, die Clients haben private Encrytion Keys, die nötig sind, damit die Partner miteinander reden können. Hat eine "benachbarte" IP, die nicht im gleichen Tailnet ist, deswegen diese Keys nicht, kann sie nichts machen. In einem Tailnet kann die Kommunikation von Clients untereinander noch weiter durch ACLs ( Terminology and concepts · Tailscale ) eingeschränkt werden.
Wer sagt, dass das unter allen Umständen reibungslos funktioniert? Dass nicht plötzlich mal Adressen eines anderen Kunden in meinem Netz auftauchen? Vielleicht sogar provoziert? Es ist Software, es ist menschengemacht, es ist damit prinzipiell fehleranfällig. Und erst der Umstand, dass alle Geräte mit Unique Adressen aus einem großen Pool versorgt werden, öffnet diesen Vektor. Grundlagen TARA.
Das korrekte Funktionieren dieses Stacks ist die Geschäftsgrundlage von Tailscale. Wieso zweifelst Du generell an, dass die Firma ihr Kerngeschäft drauf hat? Willst Du damit sagen, dass Wireguard unzuverlässig ist? Jede(r) hat irgendeine IP Adresse für den öffentlichen Internetzugang. Wieso sollte die Versorgung mit unique IP Adressen "aus einem großen Pool" bei Tailscale etwas anderes sein? Was wäre der Unterschied zwischen dem 100.X.X.X Bereich und den privaten Adressbereichen?
Ob es nun sinnvoll ist, den CG-NAT Adressbereich zu verwenden, oder die komplett privaten Adressbereiche, darüber können wir gerne reden. Aber alles andere ist doch Käse.
Ich würde eben nicht alle Kundenanschlüsse in ein großes 100.x.y.z/10 Netz verfrachten.
Sondern?
-
Das hoffst du. Aber die Auswahl der Adressen erhöht das Risiko, dass es (irrtümlich?) schiefgeht. Bei einer anderen Wahl der Kunden-Adressen könnte man das bereits prinzipiell unterbinden, hier ist man drauf angewiesen, dass die Software, die den Fence realisiert, auch ordnungsgemäß funktioniert, konfiguriert ist, und keine Lücken hat. Da hätte man das System direkt in der Architektur sicherer auslegen können. Deshalb oben schon mein Hinweis: Wenn da wirklich 100er Adressen benutzt werden, wäre das für mich schon ein Grund, auszusteigen.
Aufgrund welcher technischen Grundlage stellst Du die Verwendung des 100.x.x.x. Netzes in Frage? Wieso sollte die Auswahl eines IP Netzwerkes hier irgend etwas beeinflussen? Welche Kundenadressen sollten denn sonst gewählt werden?
Wieso sollte etwas "irrtümlich" schief gehen? Das ist das BUSINESS MODELL der Anbieter, dass das korrekt und sicher funktioniert.
Wieso Tailscale das verwendet wird hier erklärt, es kommt damit weder den privaten noch den öffentlichen Adressranges in die Quere.Ein privates Netzwerk ist ein "Tailnet". Was das ist, wird hier erklärt.
Den Absatz
ZitatEach device gets a private Tailscale IP address in the CGNAT range and every device can talk directly to every other device, wherever they are on the internet.
mag man evtl falsch verstehen in Deine Richtung. Gemeint ist damit aber, dass jedes Gerät mit jedem anderen IM GLEICHEN TAILNET reden kann, nicht darüber hinaus.
Zudem wird mit
ZitatYour tailnet is your space. The internet cannot reach it.
sonnenklar erklärt, was nicht geht.
Tailscale wie Zerotier und andere sind controllerbasierte VPNs, die die lästige dezentrale Konfiguration der Clients zentralisiert und damit die Handhabung extrem vereinfacht. Quasi jedes Angebot hat logischerweise Einstellungen die beschränken, welche Clients in welchem Netz sind. Bei manchen Angeboten kann man darüber noch hinaus mit ACLs einstellen, welcher Client ggüber anderen Clients was darf.
