Trennung von lokalen Netzen mit Schnittstellen-Tag vs. Routing-Tabelle

[Hagen2000]

Neben unserem INTRANET gibt es ein zweites IP-Netzwerk, welches nur auf das Internet zugreifen darf, also wie ein klassisches Gastnetz.
Dieses ist mit einem eigenen Schnittstellen-Tag versehen, so dass das Advanced Routing and Forwarding (ARF) - wenn ich es richtig verstanden habe - für die Trennung der beiden Netze sorgt. Ein Zugriff aus dem Gastnetz in das INTRANET sollte somit nicht möglich sein.
Tests mit ping zeigen auch, dass die Richtung Gastnetz -> INTRANET nicht funktioniert, umgekehrt schon.

Betrachtet man die aktuelle FIB mit ipv4-route, so erscheinen nun alle Routen, die eigentlich nur für das INTRANET gelten sollen, auch für das Gastnetz. Das liegt m.W. daran, dass alle Routen das Tag 0 haben und somit übergreifend gelten.

Aber eigentlich ist das doch suboptimal, schaut es doch so aus, als ob das Gastnetz ebenfalls auf alle Routen zugreifen könnte. Sollte nicht besser das INTRANET ebenfalls ein von 0 abweichendes Schnittstellen-Tag erhalten?

Welche Vor- und Nachteile haben die beiden Varianten (also INTRANET hat Tag 0 oder Tag <> 0)?

[backslash]

Hi Hagen2000

Welche Vor- und Nachteile haben die beiden Varianten (also INTRANET hat Tag 0 oder Tag <> 0)?

Hier einem kurz un knapp die ARF-Sichtbarkeitsregeln:

• ein Netz mit Tag 0 kann alle Netze sehen
• ein Netz von Typ DMZ kann von allen Netzen gesehen werden
• für alle anderen Tags gilt: Netze mit unterschiedlichen Tags können sich nicht sehen

Die Sichtbarkeiten werden in der FIB dadurch abgebildet, daß es für jedes Tag eine in sich abgeschlossene Routing-Tabelle gibt, in der alle Routen stehen, die aus dem jeweiligen Netz gesehen werden können, d.h.

• In der Tabelle für Tag 0 stehen ALLE Netze und alle statisch konfigurierten Routen
• in den Tabellen aller anderen Tags stehen nur
  • alle Netze mit dem gleichen Tag
  • alle Netze vom Typ DMZ
  • alle statisch konfigurierten Routen mit dem selben Tag
  • alle statisch konfigurierten Routen mit dem Tag 0

Da kann man aber weder von Vor- noch von Nachteilen sprechen - was du wählst ist abhängig von dem was du willst.
Schließlich kannst du sie Sichtbarkeiten auch in einem "flachen Netz" (nut Tag 0) über (beliebig komplexe) Firewallregeln abbilden. Da zeigt sich dann auch sofort der definitive Vorteil des ARF: Bei sinnvoller Wahl der Interface-Tags brauchst du zur Trennung keine (zusätzlichen) Firewallregeln...

Gruß
Backslash

[Hagen2000]

In unserer Routing-Tabelle gibt es Einträge der Form "Subnetz -> VPN-Gegenstelle". Da sie das Tag 0 haben, erhält nun auch das Gastnetz diese Route. In der Tat ist die FIB für das Gastnetz identisch mit der des INTRANETs (konsistent zu Deiner Funktionsbeschreibung).

In der Firewall wiederum steht sinngemäß "ANYHOST darf mit der VPN-Gegenstelle kommunizieren". Somit kann das Gastnetz mit der VPN-Gegenstelle kommunizieren (mal abgesehen von Rückrouten und erforderlichen VPN-Netzwerkbeziehungen)? Oder verhindert das noch irgendein Mechanismus?

Die Quelle ANYHOST weiter einzuschränken wird schwierig, wenn ich über den LANCOM-Router wieder ins Internet zu prinzipiell beliebigen Adressen routen will (für die Antwortpakete).

Letztlich muss ich doch dem INTRANET ein Schnittstellen-Tag <> 0 zuweisen, damit ich überhaupt Routen definieren kann, die nur für das INTRANET gelten.

[backslash]

Hi Hagen2000,

In der Firewall wiederum steht sinngemäß "ANYHOST darf mit der VPN-Gegenstelle kommunizieren". Somit kann das Gastnetz mit der VPN-Gegenstelle kommunizieren (mal abgesehen von Rückrouten und erfoderlichen VPN-Netzwerkbeziehungen)? Oder verhindert das noch irgendein Mechanismus?

Was die Routen auf auf deiner Seite angeht: nein

Aber: es gibt ja noch die VPN-Netzbeziehungen - und wenn du die nicht auf das Gastnetz ausgedehnt hast (ich hoffe du hast wegen "ANYHOST" da nicht "0.0.0.0/0 " in die Regeln aufgenommen), werden Pakete vom Gastnetz in den Tunnel vom VPN verworfen, da für sie keine Regeln existieren und somit keine SAs ausgehandelt werden können. Ein "show vpn" (auf dem CLI) zeigt dir die existierenden Regeln an, ein "show vpn sadb" zeigt die ausgehandelten SAs

Desweiteren gibt es ja auch noch auf der anderen Seite des VPN-Tunnels eine Routing-Tabelle - in der sollte dein Gastnetz auch nicht auftauchen (es sei denn du hättest eine Default-Route auf den VPN-Tunnel gelegt). Somit wird spätestens dort der Zugriff vom Gastnetz aus unterbunden, denn es können keine Antworten zurück geroutet werden. Ist die Gegenseite ein LANCOM, wird zudem das IDS der Firewall anschlagen - es sei denn du hättest es deaktiviert"

Es gibt also noch genügend Stellen, die das unterbinden - die du aber natürlich auch alle "aushebeln" kannst. Eine sichere Netzkonfiguration geschieht nunmal nicht automatisch - die Firmware kann dich aber z.B. mit ARF dabei unterstützen.

Wenn nu nicht willst, daß die Route zum VPN in der Routing-Tablle deines Gastnetz auftaucht, mußt du deinem Intranet ein anderes Tag als 0 geben. Dann mußt du aber, wenn du doch Zugriff von deinem Intranet auf das Gatsnetz haben willst, eine Firewallregel erstellen, die den Traffic passend umtaggt:

Code: Alles auswählen

Name:        "ALLOW INTRANET->GASTNETZ"
Routing-Tag: Tag des Netzes "GASTNETZ"
Aktion:      "ACCEPT"
Quelle:      lokales Netz "INTRANET"
Ziel:        lokales Netz "GASTNETZ"
Ziel-Dienste: wie gewünscht...

Es geht halt nur "bequem" oder "sicher"...

Gruß
Backslash

[Hagen2000]

Um die Sicherheit geht es mir vorrangig, aber dazu muss man halt auch die Details kennen und verstehen. Deine Ausführungen dazu sind sehr hilfreich. Und Gastnetz und Intranet sollen in diesem Fall vollständig isoliert voneinander sein.

[Hagen2000]

Kurzes Feedback:
Das hat prima geklappt, die Routing-Tabellen schauen nun sauber, d.h. voneinander getrennt aus.
Das INTRANET hat nun ein Schnittstellen-Tag <> 0 und die zugehörigen Routing-Regeln verwenden dieses Tag als Routing-Tag.

Zusätzlich musste ich noch Pakete, die über VPN-Verbindungen reinkommen und weiter geroutet werden sollen, über Firewall-Regeln mit dem Routing-Tag des INTRANETs versehen.

[backslash]

Hi Hagen2000

Zusätzlich musste ich noch Pakete, die über VPN-Verbindungen reinkommen und weiter geroutet werden sollen, über Firewall-Regeln mit dem Routing-Tag des INTRANETs versehen.

du könntest auch der VPN-Verbindung selbst das Tag geben - dazu ist die WAN-Tag-Tabelle (Kommunikation -> Gegenstellen -> WAN-Tag-Tabelle) da. Dort macht du einen Eintrag mit dem Namen der VPN-Verbindung und weist dieser das Tag des INTRANET zu. Den Rest läßt auf 0.0.0.0 (wird nur für RAS-Einwahlen gebraucht). Das erspart dir dann die umtaggenden Firewall-Regeln...

Gruß
Backslash

[Hagen2000]

Die Tabelle hatte ich auch gesehen, aber jetzt ist es etwas feiner granuliert: Es werden nämlich nur die Pakete durch meine Firewall-Regel mit einem Routing-Tag versehen, die an externe Ziele weiter geroutet werden dürfen. Alle anderen Pakete bleiben dann zwangsweise auf das INTRANET beschränkt oder werden geblockt.