Ich habe auf meiner Synology DiskStation den Pi Hole im Docker Container eingerichtet. Die DHCP Funktion habe ich aber abgestellt, weil ich nicht erkannt habe, dass ich damit meine VLAN DHCP Zuweisung aus dem Edge Router abbilden kann. Darum bin ich darauf angewiesen die DHCP Funktion des Routers weiter zu nutzen.
Wie geht also die Einrichtung, wenn PiHole nur als DNS Server arbeiten soll, danach aber noch, quasi als Fallback, der Router kommt, der die lokale DNS Auflösung übernimmt?
In der Frage steckt schon ein Teil der Antwort. Mein DHCP Server vergibt als DNS Server 1 die lokale Adresse vom PiHole. Er selber löst DNS Adressen nicht über den PiHole auf. Er ist das Gateway und löst die DNS über den externen DNS Dienst auf, den ich normalerweise im PiHole angeben würde. Statt dass ich den externen DNS Server jetzt im PiHole angebe, gebe ich als externen DNS Server den Router an. Der nimmt jetzt alle Anfragen entgegen: die für die lokalen Adressen und die gefilterten externen Adressen. Damit werden die lokalen Adressen richtig aufglöst und die externen werden nach aussen geleitet. Zwar ohne DNSSEC und DoT, etc. aber das ist vielleicht nicht so problematisch, wenn es nur um den Filter geht.
Hier stellt man den Nameserver im Edge einHier stellt man den Router als DNS Server ein
Also noch mal: der DHCP Server im Router teilt den Clients mit, dass ihr DNS Server der PiHole ist. Der PiHole ist jetzt der erste DNS Server im Netzwerk. Im PiHole stellt man für die externe DNS Auflösung nicht Quad9, OpenDNS, Cloudflare oder was auch immer ein, sondern gibt die IP des Routers ein (Settings > DNS). Und dem Router sagt man, dass der DNS Anfragen dann über den externen DNS Server seiner Wahl übernimmt. Im Fall des Edge Routers ist das in der Leiste am untersten Bildrand (System > Nameserver
Ich war neulich auf Reisen und bekam eine LTE Verbindung mit Volumenbegrenzung von 10GB spendiert. Problem war, dass ich von einer Flatrate ausgegangen war. Nun hatte ich darauf verzichtet vorher alle für die Arbeit benötigten Daten auf lokale Speichermedien zu kopieren, da ich dachte, dass ich ja auch später noch alles was fehlt nachträglich über das Netz laden kann. Doch wenn man sich seine 10GB doch einteilen muss, sucht man nach anderen Internet-Quellen. Die nächste Flatratequelle war in diesem Fall ein kostenloses Gastnetzwerk in der Nähe. Auf diesem Gastnetzwerk waren nicht viele Ports offen: 80, 443, 25, 143, 993, 995, 8080, um den Großteil zu nennen. Alle Ports die ich für eine Downloadverbindung zum Server brauchte, waren verschlossen und da meine OpenVPN Verbindung auf UDP 1194 eingestellt war, kam ich damit auch nicht weiter.
SSH Port Weiterleitung am Router
Welche Ports blockiert werden, kann man ganz einfach mit curl portquiz.net:993 herausfinden. Wobei 993 der Port ist, den man testen will. Die Seite portquiz.net bietet auch noch andere Testvarianten.
Zum Hauptproblem fand ich mehrere Lösungswege. Der erste schien mir am schnellsten. Wollte ich doch zu erst meine SSH Verbindung wieder nutzen, ohne den Port vom SSH Client zu ändern. Ich hatte zwar schon eine Portweiterleitung eingerichtet, aber die benutzte einen Port, der ebenfalls blockiert wurde.
Die Portweiterleitung ändere ich eigentlich am einfachsten mit dem Webinterface meines entfernten Routers, der die Zugänge zu meinem Server hinter dem Router regelt. Dort leite ich einfach einen im Gastnetzwerk freien Port (bspw. 993) auf meinen SSH Client um.
Das funktionierte leider nicht sofort und ich habe erst später gemerkt, woran es lag. Ich hatte in meiner Portweiterleitung mehrere Weiterleitungen angelegt, die alle auf den gleichen Port zeigten. Doch es fand weiterhin nur eine Weiterleitung über meinen alten Port statt, nie über die neu angelegten. Und der alte war nach wie vor im Gastnetzwerk gesperrt. Nach langem Rumprobieren kam ich drauf, dass ich die Portweiterleitungen, die ich für den Zielport 22 angelegt hatte, ein mal alle komplett abschalten musste, abspeichern und dann auf dem neuen Port wieder aktivieren musste. Dann übernimmt er die neue Weiterleitung. Doch darauf war ich erst ganz am Schluss gekommen. Denn vorher habe ich meine OpenVPN Verbindung auf TCP 443 eingestellt.
Open VPN auf https-Standardport 443 einstellen
Mit dem Umstellen von UDP Port 1194 auf TCP 443 habe ich eine sichere Fallback Lösung für alle Fälle, denn 443 müsste immer und überall offen sein und mit der VPN Lösung sollte ich immer alles über das Netzwerk bekommen, was ich brauche. Was ist eigentlich besser: OpenVPN via UDP oder TCP? (engl)
SSH Tunnel mit lokaler Portweiterleitung
Die dritte und und interessanteste Lösung war der SSH Tunnel, den ich ausprobieren musste, um ihn wirklich zu verstehen.
Angenommen ich erreiche meinen SSH Client neuerdings über Port 25, gebe ich im Terminal folgendes ein sudo ssh -p 25 user@sshclient.de -L 8080:meinserver.de:5006 -N
macOS wollte sudo, weil Privileged ports can only be forwarded by root.
Ich verbinde mich also zuerst mit -p Port 25 auf meinen SSH Client.
Warum noch mal 25? Ist beispielhaft für einen Port im Gastnetzwerk, der nicht gesperrt ist, so dass nun der angerufene Router den Verkehr von 25 auf 22 weiterleiten kann.
Jetzt steht schon mal eine SSH Verbindung im blockierten Gastnetzwerk.
Wenn ich jetzt mit dem Browser auf das unerreichbare Webinterface meines Servers kommen möchte brauche ich noch -L offenerPort:angerufenerServer:geblockterPort.
Mit -L leite ich alle „local“ Anfragen, auf den im Gastnetzwerk freien Port 8080, über die etablierte SSH Verbindung. Mein verbundener SSH Client erzeugt einen Tunnel auf dem offenen Port 8080 und holt darüber die Pakete von dem im Gastnetzwerk unerreichbaren Port 5006 aus meinem Server.
Das -N weist SSH an, keine Befehle zu erwarten, das heißt, SSH stellt keine Eingabeaufforderung her, sondern ist im Horch-Modus.
Um die Adresse, die ich normalerweise mit https://meinserver.de:5006 aufrufen würde, zu erreichen, gebe ich jetzt im Browser https://localhost:8080 ein. Dann kann ich über den Port 8080 in den Tunnel meiner SSH Verbindung steigen und komme am anderen Ende auf meinem Server mit dem Port 5006 raus.
Mit diesen drei Lösungsmöglichkeiten ist man wirklich gut ausgestattet, um seine Daten in blockierten Umgebungen zu erreichen.
Ein Problem gibt es aber noch, nämlich wenn man im Browser über einen Nicht-Standard-Port in den Tunnel möchte. Wenn man, wie ich, über Port 993 seine getunnelte Seite ansurfen will, gibt es bei allen Browsern eine Fehlermeldung, bspw. Firefox Fehler: Port aus Sicherheitsgründen blockiert.
Um den Fehler zu beheben gibt man in die Firefox Adresszeile about:config ein und sucht oder erstellt den Eintrag network.security.ports.banned.override. Als Wert wird der Port eingetragen bspw. 993.
Meine Synology Diskstation war voll. Ich musste die Festplatten vergrößern. Ich betreibe sie aber nicht wie die meisten im RAID 0, 1 oder 5, sondern zwei Platten laufen separat. Platte 1 beinhaltet das System und einen Teil der Daten. Platte 2 beinhaltet den zweiten Teil der Daten. Ich mache Backups regelmäßig mit rsync über das Netzwerk auf Journaled formatierte Platten, die im OSX hängen. So bleiben meine Backupplatten meistens aus und werden nur zum Backup hochgefahren. Nach meiner Überlegung schont das die Backup-Platten und damit Ressourcen.
Als ich nun Platte 1 im System vergrößern wollte, wusste ich nicht was auf mich zukommmt. Vorallem viele Rückschläge, aber auch viel neues Wissen.
Meine überarbeitete Website habe ich zu großen Teilen in freier Natur mit vim geschrieben. Nicht immer habe ich dafür einen Laptop benutzt. Auch das Smartphone, ein iPad oder Zuhause der stationäre Rechner, kamen zum Einsatz.
Damit ich unabhängig vom Gerät die gleiche Entwicklungsumgebung habe, musste ich mich erst mal mit dem Gedanken anfreunden, dass ich mich von der grafischen Oberfläche meines hoch geschätzten Atom-Editors verabschieden muss und die Grundlagen von vim, als Texteditor, und tmux, als Terminal Multiplexer, zu lernen habe. Beides Programme die auf der Kommandozeile laufen. Denn nur die Kommandozeile ist auf jedem Gerät und jedem OS installierbar und somit der kleinste gemeinsame Nenner aller Geräte, sei es Smartphone, Tablet oder Computer. Diese beiden Programme sind der Schlüssel zum Cloud Computing. Die wichtigste Rolle spielt dabei tmux.
flickr
twitter
RSS
