Hallo zusammen.
Ist es möglich bei einer Verbindung, die sowohl über das Internet als auch per VPN erreichbar ist, den Weg über VPN zu bevorzugen?

Beispiel:
Internet: meineSoftware.meineDomain.de >> 84.87.155.251
VPN: meineSoftware.meineDomain.de >> 192.168.189.100 << soll bevorzugt werden

Ich kann den Aufruf leider nur über den Domain-Namen machen und nicht über die IP. Deswegen geht der Aufruf auch bei bestehender VPN Verbindung immer über das Internet. Der einzige Weg, der mir einfällt, ist dem VPN einen eigenen DNS mitzugeben und dort die Domain intern aufzulösen, nur geht das vermutlich nur wenn ich den kompletten Traffic über VPN leite und nicht als Split, oder?
Gibt es noch andere Wege? Im Netz hab ich ein Skript für Windows gefunden, um die Host-Datei zu beeinflussen, aber nichts für Mac und von Hand ist das umständlich. Dann noch Conditional Forwarding für das man aber einen lokalen DNS Resolver benötigt. Oder ich denke komplett falsch ...

Ursprünglich habe ich dieses Problem durch den Einsatz von zwei verschiedenen Pi-holes gelöst. Die aktuelle Lösung basiert auf Tailscale und kommt ohne Abo aus, das eine Split-DNS-Funktion bereitstellen würde.

Der zentrale Baustein ist ein Pi-hole, das in der Tailscale-Konfiguration als DNS-Server eingetragen ist und dort über eine 100.x-Adresse erreichbar ist. Da VPN im Heimnetz meist nicht aktiv ist, bekommt der Pi-hole-Container per macvlan eine eigene interne IP. Diese Adresse ist unabhängig von der IP des Host-Systems.

Ein zweiter Tailscale-Container fungiert als Subnet-Router und leitet den Verkehr für die internen Adressbereiche weiter. In denselben Netzwerk-Stack ist Caddy integriert, das über eine DNS-01-Challenge bei Hetzner gültige Let's-Encrypt-Zertifikate bezieht, ohne dass ein Port nach außen geöffnet sein muss.

Bei aktiver VPN-Verbindung löst die Domain automatisch auf die interne IP auf. Das Editieren von Host-Dateien oder das Schreiben von Skripten für macOS ist damit nicht notwendig. Die Logik liegt vollständig auf der Infrastrukturseite. Wenn ich unterwegs bin, aktiviert die Tailscale-App das VPN automatisch und deaktiviert es im Heimnetz.

Daran habe ich übrigens ein paar Tage gebastelt. Bin ja nicht vom Fach …

ist das denn nur für einen Rechner, den Du unter Kontrolle hast? Und ist das VPN immer zur Verfügung, es braucht also nie ne direkte Verbindung zu dem Host ohne VPN?

Wenn ja, müsste es doch reichen, einen Eintrag in der /etc/hosts hinzuzufügen mit der internen IP und dem vollen Hostnamen. Dann müsste das doch vom System immer überschrieben werden beim Zugriff mit der IP die übers VPN erreichbar ist.
Ist natürlich nur mühsam, wenn Du zwischen Situationen wechselst wo mal das VPN verfügbar ist und mal nicht. Dann müsste man das jedes Mal wieder ändern.

Doch das geht, besonders mit Split-Tunnel/(-DNS).
Wichtig ist, dass dem VPN ein DNS-Server mitgegeben wird.
Ist der erreichbar, löst er "intern" die 192er Adresse auf und steuert diese per Split-Tunnel per VPN an.
Ansonsten geht er übers Internet.
Das ist die sauberste und einfachste Lösung ohne Bastelei.

Wenn der Hostname „nur“ über den Browser aufgerufen wird und du berechtigt bist, die Hostsdatei auf deinem Rechner zu ändern, einfach 2 Einträge in der Hostsdatei anlegen, einen „meineSeite.extern externeIP“ und im 2. Eintrag „meineSeite.intern interneIP“

konnektor möchte den internen Dienst meineSoftware.meineDomain.de sowohl per VPN unterwegs als auch im Heimnetz über die gleiche Adresse erreichen. Unterwegs wird er über 84.x.y.z aufgelöst, intern über 192.x.y.z. Das Routing sollte ohne unterschiedliche Domains für VPN und Heimnetz funktionieren.

Was du beschreibst, ist, wie man den DNS-Server fürs Internet (z.B. Google) und für Heimnetz (Pi-hole) getrennt anspricht.

Nein, ich beschreibe, wie man einen Namen auf eine interne IP auflöst. Und das macht man am besten und unkompliziertesten mit einer internen DNS-Zone. Das VPN spielt dabei erstmal keine Rolle.

Ich habe eines überlesen: Der Dienst ist von außen per Internet erreichbar und kann damit über öffentliche DNS-Server aufgelöst werden.
Ich beschrieb eine Lösung für den Fall, dass der Dienst ausschließlich intern verfügbar ist. Nur ein DNS-Server (Pi-hole), der sowohl im VPN als auch im Heimnetz (separate DNS-Zonen) korrekt auflöst, ohne dass ein Port nach außen geöffnet sein muss.

Vielen Dank für die vielen Antworten und Lösungsansätze.
Das Programm ist per Webclient über das Internet aufrufbar und das soll auch so bleiben.
Im Büro existiert ein permanentes VPN zum Programmserver und eine Routing mit DNS, das den Aufruf intern direkt per VPN zum Server sendet. Im HomeOffice kann und will (Sicherheit, andere private Teilnehmer) ich das mit meiner Fritz!Box nicht nachstellen und suche deswegen eine andere Lösung für ein einzelnes MBP. Der Zugriff dort erfolgt per Tunnelblick VPN.
Und die Auflösung auf die interne IP wird dann bevorzugt?
Ich hab die Hostdatei schon öfters wegen solcher Sachen geändert. Für ein ständiges hin und her ist das aber zu aufwendig. Wie weiß der Mac bei 2 Einträgen, wann er welchen bevorzugen soll?

Zwangsläufig, wenn der primäre DNS-Server die interne IP liefert. Bei A- und AAAA-Records gibts keine Prioritäten.

@caMpi
Werde ich versuchen, danke.

@MikeMuc
Hab gerade mal die Host Datei mit 2 Einträgen versucht, der interne zuerst.
Mit VPN funktioniert es, ohne VPN läuft es ins leere.
Hab ich Dich da missverstanden?

Hello,

ich habe mal u.a. im Rahmen eines Projekts beim Kunden den »VPN Tracker« von Equinux genutzt. Generell fand ich die App super – vor allem beim Verteilen / Verwalten von Verbindungen für mehrere Nutzer –, nur leider teuer.

Ich meine zu entsinnen, dass Du nicht nur platt den gesamten Traffic durch den Tunnel schieben, sondern auch einen DNS mitgeben konntest. Kannst Du ja zumindest mal kostenlos testen. Vielleicht hilft es ja.

Greetings, C.

Man kann für einen Namen auch mehrere IPs hinterlegen. Löst man den Namen z.b. mit dig oder nslookup auf, erhält man dann zufällig eine der beiden IPs. Nennt sich Round Robin und ist nicht wirklich vorhersehbar. Zudem landen DNS-Anfragen häufig im Cache. Hat sich der Client also mal auf eine IP festgelegt, hilft nur das Leeren des DNS-Cache.
Praktikabel ist das nicht.
Einträge in der hosts funktionieren mit dig und nslookup nicht. Hier zählt first come first serve.
Seine Idee fußte auf zwei unterschiedliche Hostnames.

konnektor
Sinn meiner Lösung ist, das du den Webclient mit unterschiedlichen Namen aufrufst, der Mac muß da nix mehr entscheiden. Du allein entscheidest, mit welchem Namen du dein Ziel erreichen willst und wählst dann den passenden Namen dazu aus.
Theoretisch sollte die Hostsdatei die erste Anlaufstelle zur Namensauflösung sein, daher verwende dort 2 eindeutige Namen die garantiert nicht extern aufgelöst werden.
Wenn ich nochmals nachdenke: ein Eintrag mit dem internen Namen und der internen IP sollte ausreichend sein denn der öffentliche Namen wird ja über den DNS aufgelöst.

Jetzt hab ich es verstanden, hab ich überlesen. Wird aber vermutlich nicht funktionieren. In der Konfiguration des Programms taucht an vielen Stellen der eindeutige, vollständige Hostname auf. Entweder es funktioniert also gar nicht mit einem anderen oder es wechselt auf den ursprünglichen Hostnamen.

Im anderen Thread schreibst du, dass Du ein Ugreen-NAS hast. Mein Vorschlag oben ist für deine Situation unnötig komplex, weil dein Dienst öffentlich erreichbar ist und dein VPN bereits die internen IPs verwendet.
Mit einem NAS sollte es so viel einfacher funktionieren:

• Installiere Pi-hole als Docker-Container.
• In Pi-hole trägst du unter Local DNS einen einzigen Eintrag ein: deine Domain zeigt auf die interne IP deines Servers (also der Reverse Proxy oder direkt die interne IP deines Dienstes).
• In der Tunnelblick-Konfiguration gibst du die IP des Pi-hole als DNS-Server mit.

Fertig. Unterwegs löst Tunnelblick die Domain über Pi-hole intern auf, ohne VPN läuft alles wie bisher über den öffentlichen DNS.

Warum nicht einfach einen passenden A-Record im DNS setzen?

https://www.meineSoftware.meineDomain.de für extern
https://meineSoftware.meineDomain.de für intern

Damit umgeht man die ganzen umständlichen Konfigurationen oder nötigen Hosts Änderungen die man irgendwann mal vergisst.

So wie ich das verstanden habe, läuft die Software bzw. die Webseite ja intern auf einem NAS/Webserver und wird irgendwie ja öffentlich zugänglich gemacht. Wobei ich mich wieder Frage, warum soll oder muß die öffentlich erreichbar sein und wird nicht einfach nur intern gehostet und von aussen nur per VPN zugänglich gemacht?
Erhöht die Sicherheit.

Zu bedenken wäre aber auch, dass ein Zertifikat dann beide Domains beinhalten muss!

Dann muss der Webdienst auch mehrere Domains verwalten können (mit Caddy sollte das machbar sein), ist aber Aufwand.

Aber andere Frage: wenn der Dienst per http(s) extern erreichbar ist, was bringt der Weg über VPN für Vorteile?

Danke, gut erfasst und mitgedacht!
Ich werde aber trotzdem erst mal den Weg verfolgen im VPN selbst den internen DNS Eintrag mitzugeben.

Nein, die Software läuft auf einem öffentlich erreichbaren Webserver und muss eingeschränkt auch von Kunden erreichbar sein. Für diese Einschränkung sorgt die Software selbst, in dem man in der Konfiguration "interne" IPs angeben kann und nur die haben dann vollen Zugriff. Im Büro haben wir einen ständigen Tunnel und die IPs sind eingetragen. Im Homeoffice hat das trotz eingetragenen IPs und aufgebautem Tunnel keine Wirkung gehabt, weil der Hostname extern aufgelöst wurde.
Der Weg ist also tatsächlich dem Tunnel einen DNS mitzugeben. Wie ich jetzt mitbekommen habe, haben die Windows-Leute das über AD automatisch, nur die Macs wurden mal wieder vergessen.
Der Aufruf über www. würde umgeleitet werden und wieder extern sein.

Wildcard, würde also gehen.Das geht nicht, s. Antwort an rmayergfxErklärung s. Antwort an rmayergfx


@all
Vielen Dank für die umfassende Hilfe und das Mitdenken! Für mich ist erstmal die passende Antwort dabei (DNS im VPN). Wir haben auch schon getestet und feilen nur noch an den Details.