Infrastrukturdesign: Site-to-Site VPN + internes DNS?

Guten Morgen zusammen,

aktuell stehe ich vor dem Ausbau unserer Infrastruktur:
Kunden werden per IPsec VPN angebunden, mit dem Ziel diverse interne HTTPS-Webdienste anzusprechen. Die zugehörigen Zertifikate sind momentan ausschließlich auf Namen ausgestellt.

Ruft der Kunde nun Dienste per IP auf, erhält er Zertifikatsfehler, die er in Kauf nehmen muss.

Um das zu vermeiden empfehlen wir dem Kunden die Namensauflösung selbst vorzunehmen. Je nach Projektgröße entspricht das einem einzelnen Arbeitsplatz (/etc/hosts) oder einer neuen Zone im DNS des Kunden.
Letzteres birgt die Gefahr von Fehlkonfigurationen und nicht-Auflösung unserer veröffentlichten Dienste ins Internet.

Die Inbetriebnahme eines VPN-Kunden-DNS wäre denkbar, darf jedoch aus Sicherheitsgründen nicht mit unserem produktiven DNS gekoppelt werden.

Welche saubere Alternative übersehe ich?


TL;DR: Wie sieht ein nachhaltiges, sicheres DNS-Konzept in privaten Netzen aus?

Im Voraus vielen Dank.

Was sind das für Geräte, die die Site-to-Site aufbauen? Können die nicht sowas wie Request Routes oder statische DNS Einträge?

Seh ich das richtig die Hosts die aufgelöst werden soll dürfen nicht einfach im normalen DNS stehen auch wenn sie ohne den VPN Tunnel nicht aufrufbar wären?
Ich sehe hier nicht wirklich den Gewinn, ich würde die Dienste mit Namen die im öffentlichen DNS stehen ansprechen aber die Server selbst nur über den VPN Tunnel erreichbar machen. So löst das auch ein Anbieter bei einem unserer Kunden. Hier gibt es ein Portal das man nur über eine IPSec Verbindung erreichen kann, das aber ganz normal im DNS des Anbieters auflösbar ist.

Sofern bei den Kunden immer ein eigener DNS-Server im Einsatz ist ist, kann man durch aus mit einem eigenen VPN-DNS-Server arbeiten. Seine Zone sollte aber nicht kopiert werden sondern der der VPN-DNS als bedingte Weiterleitung konfiguriert werden. Sowohl Windows als auch BIND können das. Dadurch muss die Zone nur einmal gepflegt werden, die Konfiguration beim Kunden ist recht einfach und die Auflösung der Kunden-Zone ist nicht beeinträchtigt.

Einfacherer wäre jedoch wie von @Masamune2 erwähnt eine öffentliche Auflösung der Namen. Hier kannst du problemlos private IPs eintragen, die dann sowieso nur über das VPN erreichbar sind.
Zur Trennung vom eurem DNS könnt ihr einfach eine andere Zone benutzen (z. B. fredhoffs-vpn.de) und bei einem Hoster eurer Wahl extern hosten. "dienst1.fredhoffs-vpn.de" löst dann zum Beispiel auf die VPN-IP 172.16.12.13 auf.
Das ganze erfordert keinerlei Konfiguration beim Kunden sondern funktioniert immer und überall. Der tatsächliche Zugriff funktioniert weiterhin nur über VPN.

Guten Abend,

danke erstmal für eure Antworten.

Clcreative schrieb:

Was sind das für Geräte, die die Site-to-Site aufbauen? Können die nicht sowas wie Request Routes oder statische DNS Einträge?

Zum Vergrößern anklicken....

Soweit mir bekannt ist, bietet die Juniper SSG keins von beidem an. Umstieg auf Fortinet ist in Planung.

Masamune2 schrieb:

Seh ich das richtig die Hosts die aufgelöst werden soll dürfen nicht einfach im normalen DNS stehen auch wenn sie ohne den VPN Tunnel nicht aufrufbar wären?

Zum Vergrößern anklicken....

Eine fünfstellige Anzahl Arbeitsplätze (ca. 97% kommen per VPN aus dem WAN) nutzt die Kombination internes DNS+VPN-Dienste. Nur die Drittkunden sind momentan vom internen DNS abgekapselt.

Masamune2 schrieb:

Ich sehe hier nicht wirklich den Gewinn, ich würde die Dienste mit Namen die im öffentlichen DNS stehen ansprechen aber die Server selbst nur über den VPN Tunnel erreichbar machen. So löst das auch ein Anbieter bei einem unserer Kunden. Hier gibt es ein Portal das man nur über eine IPSec Verbindung erreichen kann, das aber ganz normal im DNS des Anbieters auflösbar ist.

Zum Vergrößern anklicken....

TheCadillacMan schrieb:

Einfacherer wäre jedoch wie von @Masamune2 erwähnt eine öffentliche Auflösung der Namen. Hier kannst du problemlos private IPs eintragen, die dann sowieso nur über das VPN erreichbar sind.
Zur Trennung vom eurem DNS könnt ihr einfach eine andere Zone benutzen (z. B. fredhoffs-vpn.de) und bei einem Hoster eurer Wahl extern hosten. "dienst1.fredhoffs-vpn.de" löst dann zum Beispiel auf die VPN-IP 172.16.12.13 auf.
Das ganze erfordert keinerlei Konfiguration beim Kunden sondern funktioniert immer und überall. Der tatsächliche Zugriff funktioniert weiterhin nur über VPN.

Zum Vergrößern anklicken....

Sorry für die Salamitaktik:
Je nach Kundenbedürfnis wählen wir zwischen "Zugriff via IPsec VPN" oder "direkter Veröffentlichung ins Internet".
Grundsätzlich sind die Dienste bereits mit dienst1.fredhoff.de/Kundennummer/ und öffentlicher IP ins Internet veröffentlicht. Der Zugriff wird per Loadbalancer kontrolliert: Permit = KdNr. + feste IP Kunde.
Im VPN wird derzeit ebenfalls mit dienst1.fredhoff.de/Kundennummer/ gearbeitet, so können wir unser Root-Zertifikat wiederverwenden.

TheCadillacMan schrieb:

Sofern bei den Kunden immer ein eigener DNS-Server im Einsatz ist ist, kann man durch aus mit einem eigenen VPN-DNS-Server arbeiten. Seine Zone sollte aber nicht kopiert werden sondern der der VPN-DNS als bedingte Weiterleitung konfiguriert werden. Sowohl Windows als auch BIND können das. Dadurch muss die Zone nur einmal gepflegt werden, die Konfiguration beim Kunden ist recht einfach und die Auflösung der Kunden-Zone ist nicht beeinträchtigt.

Zum Vergrößern anklicken....

Ein Großteil der Stadtverwaltungen betreibt entweder ein eigenes DNS oder kauft es beim kommunalen Dienstleister ihres Vertrauens ein. Die Ausnahme bestätigt die Regel und lebt sonst meist mit der Veröffentlichung ins Internet (siehe oben) oder das Projekt stirbt.

Über die zusätzliche Zone und ein weiteres Zertifikat denke ich nochmal nach, Danke dafür!

FredHoff schrieb:

Grundsätzlich sind die Dienste bereits mit dienst1.fredhoff.de/Kundennummer/ und öffentlicher IP ins Internet veröffentlicht. Der Zugriff wird per Loadbalancer kontrolliert: Permit = KdNr. + feste IP Kunde.
Im VPN wird derzeit ebenfalls mit dienst1.fredhoff.de/Kundennummer/ gearbeitet, so können wir unser Root-Zertifikat wiederverwenden.

Zum Vergrößern anklicken....

Eine weitere Möglichkeit wäre den IP-Block der im Internet (und somit im öffentlichen DNS) verfügbaren Dienste über das VPN zu Routen.
Irgendwelche Routen ins VPN werden beim Verbindungsaufbau ja sowieso installiert. Wenn ihr damit die öffentlichen IPs ins VPN "umbiegt" braucht ihr weder neue Zonen noch Zertifikate und für den Kunden ist das nahezu komplett transparent.

Das setzt natürlich voraus, dass im VPN ebenfalls ein Load Balancer vorhanden ist. Ob das machbar/gewünscht ist, kann ich nicht beurteilen. Wenn man den Kundentraffic so früh wie möglich trennen will/muss, geht das natürlich nicht.

TheCadillacMan schrieb:

Eine weitere Möglichkeit wäre den IP-Block der im Internet (und somit im öffentlichen DNS) verfügbaren Dienste über das VPN zu Routen.
Irgendwelche Routen ins VPN werden beim Verbindungsaufbau ja sowieso installiert. Wenn ihr damit die öffentlichen IPs ins VPN "umbiegt" braucht ihr weder neue Zonen noch Zertifikate und für den Kunden ist das nahezu komplett transparent.

Das setzt natürlich voraus, dass im VPN ebenfalls ein Load Balancer vorhanden ist. Ob das machbar/gewünscht ist, kann ich nicht beurteilen. Wenn man den Kundentraffic so früh wie möglich trennen will/muss, geht das natürlich nicht.

Zum Vergrößern anklicken....

Hallo,

genau so machen wir es jetzt. Auflösung über externen DNS und am Ende des Tunnels D-NATen wir die öffentlichen Zieladressen auf Backbone. Ist zwar regeltechnisch noch nicht hundertprozentig, da ich für jedes Ziel eine neue Regel bauen muss (ist der Anwendung geschuldet), lässt sich allerdings später gut konsolidieren.

Danke für die Hilfe!