@klp55tsch:
Was sind denn
manchen FW-Versionen der FritzBox
genau?
Das gezeigte Kommando wäre ja "ausgeschrieben" ein
ip route get <addr> und auf dem Client im Gastnetz exakt so zu erwarten, denn der Client SOLL ja auf dem Weg zur IP-Adresse
192.168.178.44 den Weg über das Gateway im Gastnetz (
192.168.179.1) nehmen und dabei verwendet er sein Interface
eth0 mit der Absenderadresse
192.168.179.20 - das ist ja auch eine "gelernte" Route (cloned/cached) und kein statischer Eintrag (bzw. das
get veranlaßt den Kernel überhaupt erst, die Route zu ermitteln und zu speichern, wenn sie nicht gerade erst ermittelt wurde und ohnehin noch gespeichert ist).
Was das Gateway damit jetzt macht, entscheidet der Client ja gar nicht länger allein - das Gateway kann jetzt (a) seinerseits einfach routen (was es aufgrund der Isolation der Netze NICHT machen sollte) oder es führt (b) für die weiterzuleitenden Pakete eine "network address translation" (NAT) aus und ersetzt die ursprüngliche Absender-Adresse in den Paketen durch seine eigene, womit es für das angesprochene Gerät so aussieht, als käme die Verbindung vom Gateway.
Das weißt Du vielleicht selbst, ich erkläre es dennoch noch einmal so ausführlich, da ja sicherlich (heute oder in der Zukunft) auch noch andere mitlesen (und damit wir am Ende von derselben Sache reden). Wenn es die Absender-Adresse durch die eigene ersetzt, muß es sich parallel dazu merken, woher die ursprünglichen Pakete kamen, damit die Antworten auch wieder dorthin gesendet werden können (connection tracking).
Ich verstehe also letztlich nicht so wirklich, was Du mit #22 sagen willst (stimmst Du zu, daß die Verbindung NAT verwenden SOLLTE oder nicht und ist das HIER nun eine mit oder ohne NAT), daher zur Präzisierung:
Was genau wolltest Du uns mit dem Anzeigen der Route zu einem Gerät im Heimnetz von einem anderen Gerät im Gastnetz zeigen? Oder woher stammt das gezeigte Kommando und seine Ausgabe sonst?
Welche Firmware-Version (Modell und Version) ist das genau, für das Du diese Feststellung triffst? Weiter vorne ist mal eine 08.03 erwähnt, aber kein Modell - oder gilt das (nach Deiner Erfahrung) für ALLE Modelle mit 08.03 (und ggf. auch weiteren Versionen, dann für welche noch - das muß ja keine vollständige Aufzählung sein, nur irgendetwas, was man nachstellen kann)?
Welche Erfahrungen hast Du denn bei Dir hinsichtlich von Zugriffen (welchen?) aus dem Gastnetz ins Heimnetz gemacht (wieder bezogen auf die Abhängigkeit von Versionen) - wird da NAT über die Gateway-Adresse gemacht oder nicht? Es würde vielleicht auch ohne NAT funktionieren, aber dann eher "zufällig", solange die Box auch das Standard-Gateway im Heimnetz ist - denn eine explizite Route ins Gastnetz dürften die meisten Geräte im Heimnetz nicht haben und damit das Standard-Gateway nutzen.
Bei NAT funktioniert auch das wieder, denn da gehen die Antworten dann direkt an das Gateway über die Route für das lokale Netzwerk. Dennoch wäre die Isolation zwischen Gastnetz und Heimnetz dahin, wenn solche Zugriffe per Routing funktionieren und auch mit NAT sollte das auf genau den DNS-Service beschränkt sein (ggf. noch DoT).
Wie genau sieht diese "Portfreigabe (v4-Firewall)" in der Firmware des Routers aus? AFAIK steht ja auch in den Supportdaten ziemlich haarklein, was da im "connection tracking" in den Hardware-Tabellen der Paket-Beschleunigung eingetragen ist. Ich kann mir das auch gerne selbst ansehen, aber eben nur, wenn ich wenigstens einen konkreten Anhaltspunkt habe für den Fakt, daß eine solche Weiterleitung (mit oder ohne NAT) existiert und bei welcher Version man mit welchen Einstellungen suchen sollte.
Denn ich verstehe auch nicht so richtig, warum Du einmal davon schreibst, daß ALLE Ports erreichbar wären in so einer Konstellation und andererseits von einer "Portfreigabe" (i.d.R. ja auf einzelne Ports/Dienste beschränkt) und dann nicht gleich von einem "exposed host", wo wirklich alles, was keinem anderen Ziel zugeordnet werden kann, an diesen Host geht (da dann ggf. auch mit der Adresse des originalen Absenders).
Wenn die FRITZ!Box da tatsächlich ein Routing(!) ohne "connection tracking" zwischen Gast- und Heimnetz machen sollte, wie könnte sie dann zwischen Antworten auf "Requests" aus dem Gastnetz und direkt aus dem Heimnetz ausgelösten Verbindungswünschen unterscheiden und zuordnen, welche Pakete woher und wohin zulässig sind und welche die Isolation zwischen diesen Netzen unterlaufen?
Es ist sicherlich denkbar(!), daß da bei fehlerhafter Implementierung die Isolation tatsächlich nicht funktioniert - das sollte sich ja dann, mit den nötigen präzisen Informationen, auch nachstellen lassen.
Das mit dem DNS-Server ist auch noch so eine Sache - eine gesonderte Angabe des DNS-Servers für das Gastnetz ist m.W. gar nicht vorgesehen, es müßte also per DHCP entweder der "lokale DNS-Server" aus den LAN-Einstellungen annonciert werden oder die eigene IP-Adresse der Box.
Ist es die Server-Adresse im LAN, ist das vom Gastnetz nur per NAT erreichbar (so SOLLTE es jedenfalls sein, das wäre dann tatsächlich ein Grund für eine (gezielte) Freigabe für den DNS-Service und - in meinen Augen - eine unnötige Schwächung der Isolation, denn Forwarder ist ja die "native" Arbeitsweise des DNS-Servers im
multid (mithin implementiert) und für die lokale Zone ist er direkt SOA, solange kein anderer lokaler Server konfiguriert ist) und wenn es die Adresse der Box selbst ist, ist sie der DNS-Forwarder und es bräuchte erst recht keine (IP-)Weiterleitungen, wie ich am Beginn des Threads versucht habe zu erklären.
Was wird denn tatsächlich per DHCP im Gastnetz bekanntgemacht? Bei der gezeigten Konfiguration der (von der FRITZ!Box verwendeten) DNS-Server (Bild in #12) sollte ja, sofern nicht noch andere Festlegungen bei den LAN-Einstellungen erfolgen, die FRITZ!Box per DHCP als DNS-Server gesetzt sein bzw. das wäre die passende Konfiguration, wenn der Pi-Hole dann seinerseits öffentliche IP-Server als Uplink nutzt. Spezielle Auflösungen, die nur im Netz des Providers gelten (z.B. die Adressen von SIP-Servern), sind dann allerdings nicht auflösbar, wenn die öffentliche DNS-Zone dazu nichts enthält.
Das mit der DHCP-/DNS-Konfiguration richtet sich auch als Frage an
@rerhafnhabu - zumal es hier vielleicht sogar um zwei unabhängige Probleme gehen könnte, angesichts der doch recht unterschiedlichen Symptome (alle Ports vs. nur SSH ist erreichbar).
