2 „Gefällt mir“
Tailscale: Privates DNS mit MagicDNS
Eine der Funktionen von Tailscale heißt MagicDNS . Das wichtigste sichtbare Merkmal besteht darin, dass Sie auf alle Knoten in Ihrem Tailnet über deren Namen und nicht über die Tailscale-IPs zugreifen können.
Das klingt vielleicht nicht besonders neu; Schließlich ordnet DNS Namen Zahlen zu. Systeme wie mDNS erledigen das sogar automatisch. Das Interessante an MagicDNS ist, wie es dies sicher tun kann, ohne dass Namenssuchinformationen Ihr Gerät verlassen, und wie es die Sicherheit von DNS-Abfragen, die nicht von Tailscale stammen, verbessern kann.
Der aktuelle Stand der DNS-Sicherheit
Aber warum machen wir uns überhaupt Sorgen um die DNS-Sicherheit? Was bedeutet das überhaupt? Warum sollte es unsicher sein?
Alles geht auf die Anfänge des Internets zurück (damals, als es großgeschrieben wurde), als die Menschen einander größtenteils vertrauten oder es zumindest nicht wussten, wie man einander nicht vertrauen sollte. Vielleicht konzentrierten sie sich mehr darauf, Computer überhaupt zum Laufen zu bringen, als sich um die Sicherheit zu sorgen.
Auf jeden Fall war das frühe DNS weder verschlüsselt noch authentifiziert. Jeder in Ihrem Netzwerk oder auf seinem Weg könnte Ihre DNS-Anfragen sehen oder deren Antworten ändern. Man könnte meinen, dass das heutige Internet all diese Unsicherheiten inzwischen beseitigt hat und DNS jetzt sicher ist. Und Sie würden sich irren. Veränderungen brauchen Zeit, insbesondere wenn es darum geht, große, sich bewegende Rube-Goldberg-Maschinen wie das Internet zu verändern.
Aber es gab Fortschritte.
Eine kurze Zusammenfassung der DNS-Geschichte im Wandel der Zeit, sodass Sie nicht ein paar Dutzend RFCs lesen müssen:
- DNS über UDP : der Klassiker. Hoffe, sie bekommen es! Ich hoffe, niemand ändert es! Hoffentlich spioniert dich niemand aus!
- DNS über TCP : langsamer, aber zuverlässiger. Genauso leicht auszuspionieren, geringfügig, aber nicht wirklich schwieriger zu manipulieren.
- DNSSEC : Vielleicht könnten wir Schlüssel in DNS einfügen und dann Dinge signieren? Das hat sich schon seit Ewigkeiten hingezogen , ein bisschen wie IPv6. Es ist auch nicht gerade bei jedem beliebt. DNSSEC hat zwar einige Vorzüge, liegt aber weitgehend außerhalb des Rahmens dieses Beitrags. Für unsere Zwecke liegt die Sicherheit, die uns am Herzen liegt, in der Vertraulichkeit und Integrität des DNS-Verkehrs von Ihren Tailscale-Geräten und Ihrem Resolver.
- DoT : DNS über TLS über TCP. Legen Sie etwas TLS darauf. Jetzt können andere den Datenverkehr zwischen Ihrem DNS-Client und Ihrem Resolver nicht mehr ausspionieren.
- DoH : DNS über HTTP über TLS über TCP (oder über QUIC, eine Mischung aus all diesen Protokollen). Dies ist wie DoT, aber mit etwas HTTP, das im Protokollsandwich verschmiert ist. Jeder liebt HTTP.
So funktioniert MagicDNS
Tailscale betreibt auf jedem Knoten einen integrierten DNS-Server, der unter läuft 100.100.100.100 .
Ja, Tailscale auf Ihrem Computer / Telefon enthält einen DNS-Server!
Die IP 100.100.100.100 , normalerweise „Quad One Hundred“ ausgesprochen, ist Teil des privaten Carrier-Grade-NAT-Bereichs . Das bedeutet, dass es, genau wie IPs in den allgemeinen privaten Bereichen , 192.168.1/24 und 172.16/12 , 10/8 nicht im öffentlichen Internet geroutet werden kann. Wenn also eine Software auf Ihrem Computer ein herkömmliches, unverschlüsseltes UDP-Paket an sendet 100.100.100.100 , wird es ohnehin kein Standard-Router senden.
Anschließend teilen wir Ihrem Betriebssystem mit, dass sein DNS-Server lautet 100.100.100.100 . Da die DNS-Clients des Betriebssystems größtenteils im Jahr 1987 stecken bleiben, leiten sie alle ihre DNS-Anfragen über das unsichere UDP-DNS der alten Schule an weiter 100.100.100.100 . Tailscale installiert außerdem eine Route 100.100.100.100/32 zurück zu Tailscale und übergibt diese Pakete dann an den integrierten DNS-Server von Tailscale, sodass unverschlüsselte Abfragen Ihr Gerät nicht verlassen.
Push…not pull
Jetzt ist es an der Zeit, dass MagicDNS Fragen beantwortet. Zum Auflösen öffentlicher Domänen (z. B. „wikipedia.org“) leitet der lokale Tailscale-Prozess die Abfrage an den Nameserver weiter, mit dem Ihr Betriebssystem ursprünglich konfiguriert war, oder an den Nameserver, den Sie in Ihren Tailscale-Administratoreinstellungen überschreiben. Zum Nachschlagen privater Namen in Ihrem Tailnet: Die Abfrage führt zu nichts! Wenn Ihr lokales Tailscale stattdessen mit einer Karte Ihres Tailnets konfiguriert ist, werden alle privaten DNS-Namen übertragen, auf die Ihr Computer Zugriff hat. Abgesehen davon, dass es keinen externen Dienst gibt, der Ihre privaten Namenssuchen protokollieren kann, bietet eine Push-basierte DNS-Datenbank für kleine Netzwerke (wobei „klein“ „nicht Milliarden“ bedeutet) einen zusätzlichen Vorteil: keine TTL.
Im Standard-DNS enthält jede Abfrageantwort eine Time To Live (TTL). Ihr lokaler Computer und andere, normalerweise hilfreiche Vermittler wie Ihr lokaler Netzwerk-Router speichern eine Kopie einer Anfrageantwort so lange, wie es die TTL vorgibt. Ihre nachfolgenden Abfragen suchen im gespeicherten Cache. Wenn der Datensatz noch nicht abgelaufen ist, wird keine neue Suche durchgeführt.
Das ist großartig, um Bandbreite und, was noch wichtiger ist, Latenz zu sparen, wenn Sie ein Programm verwenden, das viele separate Verbindungen zum selben Ziel herstellt. Es hat jedoch einen Nachteil: Wenn Sie Ihre DNS-Einträge für eine Domain ändern, werden diese erst dann vollständig weitergegeben, wenn die TTL in allen zwischengespeicherten Resolvern im Internet abgelaufen ist. Für große öffentliche Websites ist das in Ordnung. Es gibt verschiedene Problemumgehungen, mit denen Ingenieure Datensätze langsam ändern können, ohne dass jemand Schaden nimmt. Bei der Konfiguration und Neukonfiguration Ihres persönlichen Netzwerks kann es jedoch äußerst nervig sein. Wir wollen Veränderungen sofort sehen. Das ist ein Vorteil des Push-basierten Ansatzes: Sobald Sie Ihr Tailnet ändern, indem Sie einen Host hinzufügen oder einen Namen bearbeiten, wird die neue Netzwerkkarte sofort an jeden Computer in Ihrem Tailnet gesendet und der neue Name ist einsatzbereit .
Spaß mit MagicDNS
Sobald der MagicDNS-Resolver die Abfragen hat, können wir lustige Dinge tun:
- Wir können Fragen direkt beantworten, sodass Sie
ssh pi@dogcamIhr Gerät anhand des Namens erreichen könnendogcam, anstatt sich daran zu erinnernssh pi@100.127.2.95. Auch die Latenz bei solchen Abfragen ist groß, da wir die Ergebnisse nie aus dem Internet abrufen müssen; Sie sind alle in Erinnerung. - Wir können DNS-Antworten von verschiedenen Upstream-Servern laufen lassen (falls angemessen).
- Wenn Ihr Upstream-DNS (oder einer Ihrer Upstream-DNS-Server) eine Tailscale-IP ist oder sich hinter einem Tailscale-Subnetz-Router befindet, können wir einfaches altes UDP-DNS über Tailscale weiterleiten, damit sie mit WireGuard verschlüsselt werden
-
1.1.1.1Wenn Ihr Upstream-DNS DoH unterstützt, kann der MagicDNS-Forwarder dann ein DoH-Client sein, um Cloudflare , Google Public DNS8.8.8.8oder Quad9 abzufragen9.9.9.9, ohne dass jemand Ihren Datenverkehr sehen oder manipulieren kann.
Zukünftige Arbeit
MagicDNS befindet sich noch in der Beta-Phase, da wir noch nicht ganz mit allen Funktionen fertig sind, die wir hinzufügen möchten, und mit der Behebung des langen Schwanzes der Betriebssystemintegrationen ( dies kann ein Albtraum sein ).
Einige der Funktionen, die wir gerne hinzufügen würden:
- Weiterleiten von DNS-Abfragen über Tailscale durch Exit-Knoten , wenn Sie einen Exit-Knoten verwenden.
- Dadurch können Sie Ihrem Tailnet zusätzliche, benutzerdefinierte Datensätze hinzufügen, die dann von allen Kunden direkt und ohne Weiterleitung beantwortet werden.
- Unterstützung für beliebige DoT- und DoH-Clients, um beliebige Upstream-Resolver zu erreichen. (Derzeit codieren wir nur die am häufigsten verwendeten fest)
Versucht es
Um MagicDNS zu aktivieren, gehen Sie zu den DNS-Einstellungen der Admin-Konsole und klicken Sie auf „MagicDNS aktivieren“.
Wenn Sie Split-DNS verwenden, wird der integrierte 100.100.100.100 MagicDNS-Resolver nicht verwendet, es sei denn, er wird zum Auflösen eines Namens in Ihrem Tailnet benötigt. Um Ihre Kunden zu zwingen, DoH für ihre Upstream-Abfragen zu verwenden, können Sie auf „Lokales DNS überschreiben“ klicken und einen globalen Nameserver auf Google ( 8.8.8.8 ), Cloudflare ( 1.1.1.1 ) oder Quad9 ( 9.9.9.9 ) IPs festlegen.
Einzelne Geräte können die Tailnet-weiten DNS-Einstellungen deaktivieren, indem sie die Tailscale-App öffnen und „Tailscale DNS-Einstellungen verwenden“ unter „Einstellungen“ deaktivieren oder die tailscale up --accept-dns=false Option auf der CLI verwenden.
Ihren Knoten werden basierend auf ihren Hostnamen automatisch DNS-Namen zugewiesen, wobei bei Bedarf numerische Suffixe hinzugefügt werden, um Konflikte zu lösen. Um ihre DNS-Namen zu ändern, gehen Sie zur Seite „Maschinen“ in der Admin-Konsole, klicken Sie auf die drei Punkte rechts neben einem Gerät, das Sie umbenennen möchten, und wählen Sie „Maschinennamen bearbeiten…“
Ich denke zwar ein Link dazu hätte es auch getan, aber korrekt. Die Konfiguration des DNS findet hier statt: https://github.com/juanfont/headscale/blob/main/config-example.yaml#L195-L256
Kann man den VPN Server auch so einrichten das diese danach automatisch sämtlichen Traffic durch das TOR Netz routed ?
Kannst du. Dazu brauchst du einen Host, der alle Routen über TOR jagd und lässt auf dem eine Exit Node laufen. Wichtig: Das geht denke ich 2x durchs Nadelöhr. (Kann ich nicht 100% sagen ohne es probiert zu haben, könnte ich mir aber logisch vorstellen)
Hallo, da ich bisher die normale Variante von Tailscale nutzte, wollte ich einmal die alternative Headscale ausprobieren. Der Titel des Beitrages sprach mich an und ich probierte es aus mit dem Resultat, das ich lediglich eine leere Seite im Browser angezeigt bekomme. Docker Logs sind fehlerfrei, selbst das SSL Zertifikat ist gültig. Bin da echt ratlos … jemand ggf. eine Idee, woran das liegen könnte?
Hey, probier mal den endpoint /web aufzurufen. Also https://meine-doma.in/web
Finde ich Sinnvoll. Gute Anleitung, sehr verständlich geschrieben.
… das war es gewesen, vielen Dank für den Tip, funktioniert alles bestens nun …
Noch einmal nachgefragt: Wie könnte/sollte man am besten das Verzeichnis WEB absichern gegen unbefugte Zugriffe?
Musst du an sich nicht. Der API-Key wird bei dir im Browser gespeichert. Wenn also jemand auf /web zugreift, braucht er nen API-Key und wenn er den hat, kann er die API auch direkt nutzen.