Verständnisfrage zum Routing bei Selfhosting [NAT Reflection]

Moin,

Ich bin frisch hier eingetroffen und komme direkt mit einem Problem durch die Tür

Da es mein erster Beitrag ist, hoffe ich, dass er den Ansprüchen genügt. Ich habe den Leitfaden gelesen, denke aber, dass ich einige Informationen erstmal weglassen kann da es sich wohl um ein generelles Netzwerkproblem handelt und nicht Unifi selbst.

die Istsituation:

Es soll ein Server über WAN erreichbar sein. Davor steckt ein DYNDNS Dienst.

EXTERN, also alles außerhalb meines Netzwerks, läuft es wie erwartet.

Mir ist aber aufgefallen, dass der gewünschte Dienst INNERHALB meines Netzwerkes nicht funktioniert.

Grundaufbau:
Es hängt eine UXG Pro als Router im Netzwerk, aber vermutlich ist die Hardwareaufstellung egal, da das Problem logischer Natur sein muss.

Subnetze: Es gibt verschiedene Subnetze, "Haushalt", Serversysteme, DMZ, usw.

Firewall:

Alle Subnetze sind zueinander mit Ausnahmen gesperrt:

#1: Accept, All, LAN in, established/related

#2: Drop, All, LAN in, invalid

#3: (Beispielhaft) Allow, ausgewählte Dienste und Ziele, Lan in, new

#4: drop, All, LAN in, new

Das Konstrukt soll alle unerwünschten Verbindungen zu den verschiedenen Subnetzen verbieten. Jeder darf alles finde ich dämlich.

WAN:

Als WAN-Anschluss kommt hier ein DSL Anschluss zum Einsatz, externe dynamische IP, taugt nicht für Mails, aber Minecraft geht damit schon klar.

Portweiterleitung von WAN auf ausgewählte Ports zum Server im gewünschten Ziel Subnetz

Dyndns Dienst im WAN hinterlegt, funktioniert auch alles.

Externe Aufrufe funktionieren wie gewünscht.

LAN:

Wenn ich nun aber im heimischen Subnetz die öffentliche Domain oder auch IP verwende, läuft die Verbindung nicht.

Erst, und das finde ich kurios, nach der Firewallregel "Erlaube mein Subnetz zum Zielserver" läuft das.

Vermutung:
Es ist schon eine Weile her, aber ich komm nicht mehr drauf wie das zu Stande kam, aber ich hatte das schon einmal.

Vermutlich wird schon "zuhause" im Netzwerk mit internen IPs gearbeitet und sich der Umweg über WAN gespart und dank Router der Weg abgekürzt.

Das heißt ja dann, dass der Server entweder falsch antwortet, oder AUF was falsches antwortet, auf das der Client aber gar nicht wartet.

Kennt jemand dieses Problem und wie man das sauber fixt?

Danke und Gruß,

Patrick

PS: Ach ja, nslookup sagt bei bei meinen Wunschdomains die korrekte externe IP.

Ich möchte ja bewusst nicht von LAN-->LAN den Server erreichen sondern über das WAN Interface. Oder kapiere ich das nur falsch?

Zitat von bic

Naja, von innen nach außen, auf dem Hacken kehrt und sofort wieder rein - machbar ist das, kommt aber auf die verwendete Firewall an. Diese müsste in der Lage sein, eine Loopback-NAT Regel zu händeln. Mit UI wird dies wohl nicht gehen, da brauchst Du wohl schon so etwas, wie Watchguard oder Sophos

Sophos und OPNsense betreibe ich auch ... da kam ich gerade erst drauf, dass ich wahrscheinlich dämlich bin.

Mit dem Aufruf der IP bin ich ja an einem Hop, der beide Geräte kennt und zwangsläufig die passende Route zusammenführt.

Gedanklich habe ich mich von den Webseiten ablenken lassen. Da habe ich als Proxy Cloudflare vorgeschalten und bin damit zwangsläufig extern unterwegs.

Ähnlich siehts mit meinen Proxys intern aus, die sond natürlich die Quelle meiner Daten und nicht die VM die sich dahinter versteckt.

Das zeigt mir nur, dass ich mal wieder die Routings genauer betrachten muss, man lässt sich von den Applliance der Hersteller schnell verwöhnen und dann kickt die Demenz bei mir.

Zitat von awmst4

Das was du meinst wäre NAT-Reflection. Das kann z.B. eine OPNsense, es wird aber i.d.R davon abgeraten, da es den Router unnötig belastet (*) und Sicherheitstechnisch nur einen Mehrwert bietet, wenn dein (Quell)Netzwerk ein öffentliches Gast - Netzwerk ist. --> Einstellbar in der UDM ist es meine ich nicht.

Für alles anderen Anwendungen, die mir einfallen ist die ACL (Firewall Regeln) der Schnellere und effektivere Weg

(*) Die beteiligten LAN / WAN Schnittellen werden doppelt mit IN und OUT Traffic belastet, es werden alle IDS / IPS Regeln angewendet, es wird die NAT Tabelle unnötig belastet. --> i.d.R. packt das eine UDM pro bei "Normalen" Pro-Consumer Netzwerken. Normal ist aber ein dehnbarer begriff und die Übergänge sind fließend

Danke! Mit dem Begriff bin ich wieder am Dampfer!

Zitat von bic

Hhhm ... eine reflexive Regel nützt Dir für Dein Vorhaben n.m.M. nix. Diese kehrt ledoglich die Übereinstimmungskriterien der Zielregel um. Hast Du z.B. eine Zielregel, welche eingehenden Datenverkehr auf einen internen Server übersetzt, dann erlaubt die hierzu reflexive Regel den Datenverkehr vom Server zu der in der Zielregel angegebenen Quelle. Du benötigst wohl tatsächlich eine Loopback-Regel, um internen Hosts die Kommunikation mit anderen internen Hosts über die externe IP-Adresse oder den Domänennamen zu ermöglichen.

Mir fällt nur kein Case ein an dem das dann wirklich notwendig ist.

Zitat von awmst4

Wieso unterschiedliche Zugangsdaten? wenn du im DNS der UDM den selben FQDN einträgst, der auch im öffentlichen DNS steht, verhält sich der Server aus dem LAN genauso wie aus dem WAN. Auch evtl. vorhandene Zertifikate für den FQDN bleiben voll funktionsfähig.

Meine Synology ist als Foto und Private-Cloudserver genau so angebunden. In der UDM gibt man den DNS Namen vor, oder bei einer OPNsense macht man ein DNS override.

NAT-Reflection macht nur sinn, wenn du dem entsprechenden LAN (weils z.B. ein öffentlicher Hotspot o.ä. ist) nicht vertraust.

Das kenn ich mit DNS Splitting.

Ich muss mir nur nochmal das technisch vor Augen malen.

Der Client fragt den NS nach der IP, den bekommt der auch geliefert.
Client verbindet sich mit der IP, die auf den Router zeigt.
Welches bischen Magic genau sagt dann aber, "Boy, der wohnt hier, redet local miteinander"?

Für mich ergibt das generell Sinn, nur warum wird das so gemacht, denn default (weil die Kommunikation so nicht vorgesehen ist) laufen die Pakete ja dann gegen die Wand.

Zitat von awmst4

Das bisschen Magic kommt von deinem lokalen DNS Server i.d.R. dein Router

Das könnte natürlich auch ein PIHOLE sein (local DNS Record).

Die UDM kanns, die OPNsens kanns und ein PIHOLE kanns (ja auch der DNS Server einer Synology kanns)

Bei der UDM gehst auf den Client, gehst auf Einstellungen und unter IP-Einstellungen musst du Feste IP und Lokaler DNS Namen anhaken und dann da den FQDN eingeben.

Ja, nein, das meine ich nicht ... oder ich kann dir nicht folgen

DNS ist nicht einmal das Thema, sondern warum aus 84.123.132.123 trotzdem 10.11.12.13 wird.

Also wie exakt im Gehirn der Routingtable der auf die Idee kommt, die Pakete mit lokaler IP zu versenden.

Ja das ist bekannt.

Der Client weiß auch von der öffentlichen IP zu sub.domain.tld (nslookup).

Die Besonderheit war ja, dass der Client dann an die public IP die Anfrage stellt, der Server dank Router aber mit der private angesprochen wird.

Die Funktion ansich ist bei mir angekommen, aber ich wollte die genaue Mechanik wissen. Das DNs Gebimsel ist sogar irrelevant, weil das auch mit Angabe der direkten IP so verläuft.

Da gehts nun eher um tieferes Wissen zu erlangen.