Anfängerfrage Port freigeben (?)
-
Hi,
nein es sind VMs auf dem selben Host,aber diese nicht. Allerdings aber am selbigen Switch.
Geht dies dann trotzdem?
D.h. ich füge eine virtuelle Netzwerkkarte der Firewall zu und adressiere die interne IP mit der anderen VM?
-
Du bemühst dich in deinen Postings nicht gerade um eine klare Ausdrucksweise!
Was heißt denn in dem Teil
@Fiddler:nein es sind VMs auf dem selben Host,aber diese nicht. Allerdings aber am selbigen Switch.
nun "aber diese nicht"? Hast du nun 2 Virtualisierungsserver, oder doch nur einen, auf dem alle 3 VM laufen?
Wenn alle VMs auf einem gemeinsamen Host laufen, kannst du 2 zusätzliche virtuelle Netze hinzufügen, um eine saubere Trennung zu bekommen, so wie vmbr0 ein virtuelles Netz (eigentl. die Bridge im Netz) ist. Diese erfüllen dieselben Zwecke wie die geplanten VLANs.
Diese beiden Netze müssen "isoliert" sein, dürfen natürlich nicht mit eth0 gebrückt werden, sonst stehen die VMs im WAN.Wenn die Firewall auf einem anderen physischen Host läuft, kommst du um VLANs für dieses Vorhaben nicht herum.
-
Es sind 2 Virtualisierungsserver.
Somit benötige ich VLANs,…gibt es hier eine grobe Vorgehensweise? Das Interface wie oben beschrieben vlanX auf vtnet0 ist bereits erstellt. Nun muss dieses doch zugewiesen werden oder nicht? Muss dieser Tag in der VM der Netzwerkkarte geschehen oder wo?
-
Also das aus der Nase ziehen von Informationen ist bei dir wirklich stark ausgeprägt. Lass doch mal die Hosen runter, wie der ganze Kram aussieht, dann kann man auch komplett helfen und nicht immer nur 2 Meter weit.
Hast du bspw. VMware als Hypervisor, dann läuft der ganze Netzwerkrempel über vSwitche bzw. distributed Switche. Dann müssen sowohl die vSwtiche/dSwitche als auch die physikalischen Switche an denen die Hypervisoren mit ihren Karten dran hängen das VLAN kennen und entsprechend konfiguriert haben. Wenn das sauber erledigt ist, muss auch die VM selbst (also das OS INNERHALB der VM) nicht mit VLAN Tags rumkaspern, da das dann über die d/vSwitche und normalen Switche schon ordentlich getaggt wird. Ist das nicht der Fall und alles nur ganz plump und platt gebridget, dann muss das OS in der VM selbst eben Taggen. Allerdings möchte man das eigentlich sinnvollerweise vermeiden, denn sonst ist es nicht wirklich komfortabel möglich, ne VM von einem VLAN ins andere zu hängen und man muss noch zusätzlich am Tagging rumfummeln anstatt nur neue IPs zu vergeben.
Grüße
-
OK…kapiert.
Jetzt meine Frage :
Ich möchte das die Interface untereinander nicht kommunizieren,aber jedes mal eine Regel zu erstellen wie Bsp.
Block IPv4 * OPT1 net * LAN * * none
und umgekehrt pro Interface ist ja relativ lästig.
Kann man nicht sagen,dass jedes Interface nur WAN darf und nie mit anderen Interface kommunizieren darf?
Die Regel habe ich schon angepasst,dann funktioniert aber irgendwie kein Internet mehr. :-\
-
Kann man nicht sagen,dass jedes Interface nur WAN darf und nie mit anderen Interface kommunizieren darf?
Doch, genau mit solchen Regeln. Was für dich "halt einfach nur WAN" ist, ist bei anderen eben leider komplizierter, weil sie bspw. mehrere WANs haben, mehrere LANs und man nicht so ohne weiteres nen Knopf bauen kann, dass niemand nichts machen darf.Anyway du kannst ja trotzdem hergehen und alle lokalen Netze in ein einziges Alias packen und dann überall die gleiche Regel reinpacken. Kommt ein Netz dazu musst du nur das Alias anpassen und gut. Da Pakete vom gleichen Netz ins gleiche Netz nie über die Firewall laufen sollten, sollte es auch kein Problem darstellen, alle LANs ins gleiche Alias zu packen.
Und dann einfach eine Regel "Block alles from <if_network>to DeinAlias * * none".
Andere Alternative wäre ein Alias mit allen/einem großen Netzsegment zu definieren und das generell zu blocken. Wenn alle Deine Netze bspw. aus dem Bereichn 10.x.y.0/24 sind, dann blockst du eben obendrüber einmal 10/8 und gut.
Man kann also schon den Großteil mit einer einzigen Regel abdecken, man muss eben wissen+definieren, was man eigentlich will.
Grüße
Jens</if_network> -
Seh ich genauso.
Man muss eh jedes Interface anpacken, da Diese per default nix dürfen (Ausser LAN).
Ich hab mir ein Alias "Private Networks" erstellt und habe somit mit einer Rule pro Interface meine Netze untereinander getrennt.Aber moment mal. Es gibt doch noch unter Interfaces den Punkt "Block private networks" wenn du den auf die jeweilige Lan Interfaces setzt, sparst du dir die Regel. Nur ändern oder verschieben lassen sich diese dann nicht mehr, solltest du irgendwann doch was Freischalten wollen.
-
Ja, Zielsetzung ist einfach,dass alle Interface LAN,OPT1,OPT2 nie mit anderen in Berührung kommen sollen.
D.h. wenn ich bei jedem Interface "Block private networks" das setze,spare ich mir die Regel,da kein Zugriff auf das andere Interface besteht? -
So ist es. Aber bedenke, dass solange der Haken gesetzt ist, können keine Ausnahmen erstellt werden und alle Privaten IP-Ranges (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 u. 127.0.0.0/8) werden somit nicht mehr erreichbar sein.
Wenn diese Clients nur ins Internet sollen, sollte es jedenfalls funktionieren. -
Ich hab mir ein Alias "Private Networks" erstellt und habe somit mit einer Rule pro Interface meine Netze untereinander getrennt.
Blockt das dann nicht auch alle Geräte, die daran hängen und eine private IP haben? Dann würde gar nichts gehen. Ich hab das noch nicht getestet und die Haken bislang nur an der WAN gesetzt.
@Fiddler
Allen Interfaces den Zugang zum Internet zu gewähren und gleichzeitig gegenseitigen Traffic zu unterbinden stellt für eine Regel eine Herausforderung dar, weil der Adressbereich des WWW einen sehr großen Umfang hat. Also setzt man eine Pass-rule für "any". Den gegenseitigen Verkehr müsstest du dann mit Block-Regeln unterbinden.Wenn du nicht gerne Regeln konfigurierst, kannst du das Ganze aber auch mit einer einzigen lösen. Dazu musst du aber eine Floating rule setzen, in der du alle Interfaces auswählst, auf welchen sie gelten soll. Wenn du deine Netze nicht per Netzadresse und Maske definieren kannst, weil so verstreut, musst du dafür erst einen Alias anlegen, in dem alle eingetragen sind und diese in der Regel verwenden.
Die Regel könnte so aussehen:Proto Source Port Destination Port Gateway Queue Schedule Description
pass * * * !<deine nezte="">* * * none Allow WWWRegeln auf den Interfaces werden standardmäßig vorrangig behandelt! D.h. trifft eine zu werden die Floatings nicht mehr beachtet. Soll eine floating rule aber den Vorzug haben, muss die "Quick" Option gesetzt werden.</deine>
-
Blockt das dann nicht auch alle Geräte, die daran hängen und eine private IP haben? Dann würde gar nichts gehen. Ich hab das noch nicht getestet und die Haken bislang nur an der WAN gesetzt.
~~Den Haken habe ich bis jetzt auch nur an einem WAN IF gesetzt, es entspicht aber, bis auf die Loopback Adressen, meiner Rule in meinem Secondary LAN.
Und nein, da es sich um eine In-Regel handelt, greift 1. die Regel nicht im eigenen LAN und 2. wird bei einer internen Kommunikation Lan1-Client1 zu Lan1-Client2 der direkte Weg benutzt und geht daher nicht über den Router bzw. FW.
Es werden zur Komunikation inerhalb eines LANs theoretisch nichtmal IP-Adressen benötigt, aber das ist ne andere Geschichte.~~ -
–-STOPP--
@viragomann hat Recht !Ich hatte einen Gedankenfehler.
Ja man blockt sein eigenes NETZ. Also nicht durchführen.
Bei meiner Rule ist das Private Network auf der Destination Seite und nicht auf der Source ! -
Ich hab mir ein Alias "Private Networks" erstellt und habe somit mit einer Rule pro Interface meine Netze untereinander getrennt.
Blockt das dann nicht auch alle Geräte, die daran hängen und eine private IP haben? Dann würde gar nichts gehen. Ich hab das noch nicht getestet und die Haken bislang nur an der WAN gesetzt.
@Fiddler
Allen Interfaces den Zugang zum Internet zu gewähren und gleichzeitig gegenseitigen Traffic zu unterbinden stellt für eine Regel eine Herausforderung dar, weil der Adressbereich des WWW einen sehr großen Umfang hat. Also setzt man eine Pass-rule für "any". Den gegenseitigen Verkehr müsstest du dann mit Block-Regeln unterbinden.Wenn du nicht gerne Regeln konfigurierst, kannst du das Ganze aber auch mit einer einzigen lösen. Dazu musst du aber eine Floating rule setzen, in der du alle Interfaces auswählst, auf welchen sie gelten soll. Wenn du deine Netze nicht per Netzadresse und Maske definieren kannst, weil so verstreut, musst du dafür erst einen Alias anlegen, in dem alle eingetragen sind und diese in der Regel verwenden.
Die Regel könnte so aussehen:Proto Source Port Destination Port Gateway Queue Schedule Description
pass * * * !<deine nezte="">* * * none Allow WWWRegeln auf den Interfaces werden standardmäßig vorrangig behandelt! D.h. trifft eine zu werden die Floatings nicht mehr beachtet. Soll eine floating rule aber den Vorzug haben, muss die "Quick" Option gesetzt werden.</deine>
Verstehe ich nicht ganz..wie soll deise Regel den Traffic untereinander verbieten?
-
Verstehe ich nicht ganz..wie soll deise Regel den Traffic untereinander verbieten?
Weil da steht !Deine_Netze (also NICHT deine Netze, ergo überallhin, aber NICHT in deine anderen VLANs erlauben).
-
Verstehe ich nicht ganz..wie soll deise Regel den Traffic untereinander verbieten?
Weil da steht !Deine_Netze (also NICHT deine Netze, ergo überallhin, aber NICHT in deine anderen VLANs erlauben).
Aber dann muss ich ja trotzdem jeweils eine Regel erstellen,da bei Destination nur ein Objekt ausgewählt werden kann (?).
-
Aber dann muss ich ja trotzdem jeweils eine Regel erstellen,da bei Destination nur ein Objekt ausgewählt werden kann (?).
Erst erstellst du dir für all deine Netze einen Alias. Steht doch schon merhmals oben im Text. Dann reicht eine einzige Regel.
-
bei Destination nur ein Objekt ausgewählt
Ja. Ein OBJEKT. Das da heißt "Single IP OR ALIAS" und ein Alias kann mehrere Netze umfassen. Entweder man trägt eben in selbiges Alias alle einzelnen Netze händisch ein wie schon mehrfach beschrieben - und wenn dann ein neues dazu kommt, muss es eben in das ALias wieder eingetragen werden oder man definiert das Alias gleich so groß, dass alle jetzigen und zukünftigen Netze eben Bestandteil davon sind. Bampf. :)
-
Hi,
sorry…aber irgendwie verstehe ich's nicht ganz bzw. bekomme es nicht hin :-(
