Rahmenbedingungen

Im herkömmlichen Setup einer Praxis wird ein Konnektor im gleichen IP Netz betrieben, in dem sich auch die Arbeitsplätze (also Clients) der Praxis befinden.

In Verbindung mit einem Default Gateway, welches eine sog. stateful-paket-inspection durchführt (Allgemein bekannt als “echte” Firewall) führt dies zu Kommunikationsproblemen.

Schaubild

Problemsituation(en)

• Es kann Probleme geben, die tatsächlich den VPN Tunnel zwischen dem Konnektor und der TI betreffen
  • In diesem Fall ist häufig der Router der Praxis im Übergang zum Internet (DSL, Glasfaser, etc.) eine Fehlerquelle
  • Der Router greift dann in problematischer Weise in den Paketfluss ein. Beispiele hierfür sind:
    • Firewall lässt die Verbindung gar nicht zu
    • Optimierungsmechanismen im Router für Priorisierung (bspw. von Sprache) oder andere Funktionen ändern die Paketreihenfolge
    • weitere Probleme sind hier denkbar
  • Der Ort dieser Probleme kann im Bild gut erkannt werden, aber in diesem Beitrag geht es nicht um diesen Teil der Kommunikation
• Das Problem des asynchronen Routings besteht in dem kurzen Verbindungsstück zwischen den Clients und dem Konnektor in der Praxis.
  • Ohne weitere Konfigurationsanpassungen kennen sowohl der Konnektor als auch die Clients ihr sog. Default Gateway zusätzlich zur Information, wie Sie in das lokale Netz eingebunden sind.
  • Da beide Seiten (siehe Rahmenbedingungen) im gleichen Netzwerk arbeiten, erfolgt eine Kommunikation zwischen einem Client und dem Konnektor selbst immer direkt untereinander
  • Das sog. Default Gateway kommt immer dann zum Tragen, wenn ein Ziel erreicht werden soll, welches NICHT im gemeinsamen lokalen Netzwerk liegt
    • bspw. Internetseiten (unkritisch)
    • bspw. VPN Aufbau zur TI vom Konnektor (unkritisch)
    • bspw. Zugriff vom Client auf Komponenten in der TI (unter Umständen problematisch
  • Das Default Gateway hat – funktionsbedingt – die Aufgabe, Pakete zwischen verschiedenen Netzen zu routen. Normalerweise, so wie es jeder von zu Hause kennt, auf der einen Seite das Internet und auf der anderen Seite die heimischen Geräte
  • Es kann aber (wie bei der TI, aber bspw. auch beim InterData Service VPN) Situationen geben, wo bestimmte Ziele aus Sicht des Router zwar nicht lokal angeschlossen sind, aber eben auch nicht im Internet erreicht werden sollen, sondern dass es hierfür einen definierten Punkt im lokalen Netzwerk gibt, der die Verantwortung für die Erreichbarkeit eben dieses Netzwes trägt.
  • In so einem Fall konfiguriert man auf dem Default Gateway entsprechende Routen. Bezogen auf das Beispiel, welches gleich angeführt wird, sollten auf dem Default Gateway folgende Infos konfiguriert werden.
    • Pakete mit dem Ziel 100.102.0.0/15 erreichst du über 10.1.2.150
    • Pakete mit dem Ziel 188.144.0.0/15 erreichst du über 10.1.2.150
    • Exkurs – Ein anderer Klassiker wäre das Service VPN: Ziele zu 192.168.0.0/24 erreichst du über 10.1.2.68 – Exkurs Ende
    • Damit ist erst einmal sichergestellt, dass das Gateway selbst theoretisch Verbindungen in die TI aufbauen könnte, was aber irrelevant ist, da das Gateway keinerlei Dienste der TI selber nutzt
    • ABER das Gateway kann damit halt auch Pakete auf den richtigen Weg bringen, die ein Client dem Router sendet. Internetverkehr raus ins Internet – Service VPN zugriffe zu unserem openVPN Gateway – TI Ziele zum Konnektor
  • Beispiel, damit es besser zu fassen ist:
    • Ein Client will mit der TI kommunizieren. Client IP bspw. 10.1.2.3/24. Konnektor IP bspw. 10.1.2.150/24. Damit sind Konnektor und Client im selben Subnetz.
    • Beispiel Zieladresse: 100.102.1.2/15 -> Das Ziel liegt damit außerhalb des lokalen gemeinsam Netzes von Client und Konnektor
    • Für den Konnektor selbst stellt dies kein Problem dar.
      • Er hat auf der einen Seite einen Netzwerkanschluss im lokalen Netz und adressiert alle Komponenten im lokalen Netz direkt (also ohne Gateway)
      • Zusätzlich hat er das Default Gateways, welches er immer dann nutzt, wenn er etwas außerhalb des lokalen Netzwerkes – genauer gesagt ein Ziel, für welches er keine explizite Erreichbarkeitsinformation in der Routingtabelle hat – erreichen möchte.
        Das klassische Beispiel ist der sog. VPN Konzentrator, den der Konnektor erreichen muss, um den Tunnel in die TI herzustellen
        Sobald der Tunnel hergestellt ist, bekommt der Konnektor weitere Erreichbarkeitsinformationen für die TI (dynamisch) zugewiesen, sodass:
      • Für die eigentlichen TI Ziele vom Konnektor nicht mehr das Default Gateway verwendet wird, sondern der Konnektor alle Pakete zur TI (für das Gateway unsichtbar) verpackt und im Tunnel zum VPN Konzentrator sendet
      • Dadurch ist für die Kommunikation zwischen dem Konnektor selbst und der TI alles im grünen Bereich. Pakete zur TI und zurück nutzen immer den Tunnel
    • Für die Clients sieht die Welt aber anders aus
      • Hinweg
        • Es gibt hier nur die Information des lokalen Netzwerks – dadurch kann eine Kommunikation zum Konnektor (also im Beispiel 10.1.2.3 <->10.1.2.150) direkt erfolgen (ohne Gateway)
        • Da für die Clients aber das Netzwerk der TI (100.102.0.0/15 und 188.144.0.0/15) ein entferntes (nicht lokales) Netzwerk ist und der Client keine explizite Routinginformation hat, nutzt er das Default Gateway als Ziel seiner Pakete in Richtung TI
        • Bei Einsatz eines schlichten Routers (mit erfassten Routen zur TI) stellt dies kein Problem dar. Er erkennt anhand des Paketes, dass das Ziel eine TI Adresse ist und leitet das Paket gemäß seiner Routingtabelle nicht direkt in das Internet, sondern zum konfigurierten Konnektor. Dieser packt das Paket in den Tunnel, womit es (unsichtbar) nochmals durch das Gateway läuft und beim TI VPN Konzentrator aus dem Tunnel fällt.
        • Der Rest ist Routing, welches wir in keiner Weise beeinflussen können.
      • Rückweg
        • Für uns ist als erster Punkt hier der Ausgang des VPN Tunnels am Konnektor relevant. Die Antwort der TI muss halt auf dem Konnektor in diesem Tunnel ankommen
        • Nun entscheidet der Konnektor was er mit dem Paket macht. Da das Ziel (für die Antwort) der Client, also die Adresse 10.1.2.3/24 ist, weiß der Konnektor, dass er das Paket direkt dem Client weiterleiten kann OHNE das Deafult Gateway zur Hilfe zu nehmen!
      • Dem bis hier benannten schichten Default Gateway ist das alles völlig egal. Es sieht zwar nur die Pakete vom Client zur TI und nicht die Antworten aus der TI, aber für reines Routing ist das vollkommen in Ordnung.
      • Im Ergebnis ist hier aber ein asynchrones Routing entstanden, sprich eine Verbindung läuft auf dem Hinweg über ein oder mehrere andere Geräte, als es auf dem Rückweg der Fall ist
    • Und das Problem?
      • Eine Firewall mit stateful inspection, schaut sich nun wirklich jedes Paket an und prüft bei TCP Verbindungen (was der Großteil der TI Kommunikation ist, bspw. den vollständigen Verbindungsaufbau. und dieser Verbindungsaufbau besteht aus mindestens drei Paketen
        1. Client initiiert eine Verbindung (sog. SYN)
        2. Server (also Ziel) bestätigt die Verbindungsanfrage (sog. SYN/ACK)
        3. Client bestätigt und beginnt mit der Kommunikation (ACK)
      • Fehlt eines der Pakete, ist eine Firewall bockig und erklärt den Verbindungaufbau als nicht sicherheitskonform. Sprich die ACK Pakete werden verworfen, weil nur ein SYN vom Client gesehen wurde, nicht aber das SYN/ACK vom Server
      • Es gibt noch weitere Prüfungen auf der FW, aber dieses Beispiel, dass jedwede TCP Kommunikation unseres Beispiels unterbindet, macht es eigentlich am deutlichsten

Lösungsmöglichkeiten

Was kann man also tun?

1. Auf den Einsatz einer Firewall verzichten
   Eine Option, die in den wenigsten Fällen realistisch ist
2. Eine Firewall verwenden, deren Konfiguration es erlaubt, genau dieses asynchrone Verhalten zu akzeptieren, also bspw. für Pakete, deren Quelle und Ziel am gleichen Interface liegen, die Firewall zu deaktivieren.
   Bedeutet Traffic vom / zum Internet wird weiter normal überwacht (Quelle LAN IF – Ziel WAN IF)!
   Traffic zur TI wird nicht mehr überwacht, da der Client als Quell IF das LAN hat und das Ziel in die auf dem Default Gateway (also hier der Firewall) hinterlegte Route zum Konnektor zeigt, welcher auch über das LAN IF erreichbar ist
   Die Ausprägung dieser Option kann verschiedenste Ausprägungen haben und hängt von der Implementierung auf der FW ab. Zuständig ist der Betreiber der FW.
3. Konfiguration der Routen zur TI auf jedem Client direkt zum Konnektor, also das Umgehen des Gateways (der Firewall) für den Weg zur TI, womit die FW gar keine Pakete mehr zwischen Client und TI sieht und damit auch nichts mehr unterbindet.
   Diese Option kann in InterARZT über Service für Windows APs automatisch gesetzt werden
4. Man verlagert den Konnektor in ein eigenes Netzwerk und somit an ein separates Interface der Firewall
   Damit erzwingt man, dass Hin- und Rückpakete immer durch die FW laufen und das Problem ist damit auch gelöst

praktische Überlegungen

• Lösungen, die man nur auf wenigen zentralen Komponenten realisieren muss, sind Lösungen auf allen Clients vorzuziehen
  • Das hat den Vorteil, dass es keine seltsamen Effekte beim Austausch von Clients gibt und das auch der Implementierungsaufwand geringer ausfällt
  • Damit wäre man typischerweise bei den Lösungen 2 und 4
• Je nachdem ob man den Verkehr zur TI gerne vollständig über die Firewall leiten möchte (Lösung 4) und den Aufwand zur einmaligen Trennung des Praxisnetzes in verschiedene Sicherheitszonen hinnimmt oder
• ob man eine schnelle Lösung sucht und den eigentlichen TI Verkehr nicht als FW relevant einstuft (Lösung 2) und somit nur an der Komponente FW eine Änderung vornimmt kann man agieren
• Wenn beides nicht gewünscht ist, können wir nur noch die Routen auf den Clients setzen und damit die FW für den TI Traffic vollständig umgehen.