Trennung von lokalen Netzen mit Schnittstellen-Tag vs. Routing-Tabelle
Moderator: Lancom-Systems Moderatoren
Trennung von lokalen Netzen mit Schnittstellen-Tag vs. Routing-Tabelle
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)?
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)?
LANCOM 1781VA mit All-IP-Option, LANCOM 1784VA
Hagen
Hagen
Re: Trennung von lokalen Netzen mit Schnittstellen-Tag vs. Routing-Tabelle
Hi Hagen2000
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
Hier einem kurz un knapp die ARF-Sichtbarkeitsregeln:Welche Vor- und Nachteile haben die beiden Varianten (also INTRANET hat Tag 0 oder Tag <> 0)?
- 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
- 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
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
Re: Trennung von lokalen Netzen mit Schnittstellen-Tag vs. Routing-Tabelle
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.
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.
Zuletzt geändert von Hagen2000 am 09 Feb 2024, 18:27, insgesamt 1-mal geändert.
LANCOM 1781VA mit All-IP-Option, LANCOM 1784VA
Hagen
Hagen
Re: Trennung von lokalen Netzen mit Schnittstellen-Tag vs. Routing-Tabelle
Hi Hagen2000,
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:
Es geht halt nur "bequem" oder "sicher"...
Gruß
Backslash
Was die Routen auf auf deiner Seite angeht: neinIn 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?
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...
Gruß
Backslash
Re: Trennung von lokalen Netzen mit Schnittstellen-Tag vs. Routing-Tabelle
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.
LANCOM 1781VA mit All-IP-Option, LANCOM 1784VA
Hagen
Hagen
Re: Trennung von lokalen Netzen mit Schnittstellen-Tag vs. Routing-Tabelle
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.
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.
LANCOM 1781VA mit All-IP-Option, LANCOM 1784VA
Hagen
Hagen
Re: Trennung von lokalen Netzen mit Schnittstellen-Tag vs. Routing-Tabelle
Hi Hagen2000
Gruß
Backslash
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...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.
Gruß
Backslash
Re: Trennung von lokalen Netzen mit Schnittstellen-Tag vs. Routing-Tabelle
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.
LANCOM 1781VA mit All-IP-Option, LANCOM 1784VA
Hagen
Hagen