Ich muss folgendes Szenario realisieren: In einem Subnet muss der Zugriff auf einen einzigen Rechner aus einem anderen Subnet erlaubt werden. Dieser Rechner muss dort bleiben und kann nicht das Subnet wechseln.
Ich habe bereits die entsprechenden ACE/ACL-Regeln “Zulassen” für diese eine IP erstellt, doch ich komme trotzdem nicht aus dem Subnetz heraus. Wenn ich den Rechner ins Servernetz hänge, kommt er problemlos in beide Subnetze. Umgekehrt wird der Zugriff untereinder meines Wissens nur vom Layer3-Switch geregelt, oder? Oder mischt die linuxmuster-Firewall da auch nocht mit?
Ich habe heute etwas mit den ACE-Regeln experimentiert und festgestellt, dass die Regeln nicht so greifen wie ich mir das vorgestellt habe. Wenn ich z.B. eine Regel erstelle, die den Zugriff auf eine bestimmte IP verbieten / erlauben soll, passiert das nicht. Ich habe z.B. dss Servernetz in den Regeln für dieses VLAN blockiert und musste dann feststellen, dass der Zugriff trotzdem weiterhin klappt. Wenn ich eine IP zulasse, komme ich umgekehrt trotzdem nicht auf den Rechner im anderen Subnetz. Daher die Frage, ob die Firewall des Servers auch noch mitmischt???
Schöne Grüße
Michael
Also wir haben hier den Cisco SG300. Ich bin bisher immer nach der Anleitung im Wiki vorgegangen, um das Subnetting einzustellen. Daher kann ich die Stelle, von der du sprichst so nicht finden. Die ACE sind jeweils an ein VLAN gebunden. Kannst du’s noch genauer sagen?
Eine Zeichnung könnte ich anfertigen – bin aber nicht ganz sicher, was da alles drauf soll. Das Netzwerk ist mittlerweile groß
Michael
hier geht es um die Problematik, dass ein L3 -Switch im Gegensatz zu einer Firewall nicht stateful arbeitet. Daher müssen für alle Antwortpakete Regeln erstellt werden. Im Falle der Anleitung ist dies nicht notwendig, da aus dem Servernetz (VLAN 11) keine Regel an das Interface gebunden wird und somit alles erlaubt ist.
Beispiel:
Regel 1: VLAN A: 192.168.1.1 --> VLAN B: 192.168.2.1 (Port X) —> ACL für Interface VLAN A
UND
Regel 2: VLAN B: 192.168.2.1 (Port X) --> VLAN A: 192.168.1.1 —> ACL für Interface VLAN B
Hallo @morpweb (deinen Klarnamen kenne ich nicht )
Ok, es soll ja auch so sein, dass jedes grüne Subnetz auf’s Servernetz gelangen kann. Das funktioniert auch soweit. Da VLAN.11 (Servernetz) keine ACE-Regeln hat, funktioniert der “Rückweg” in allen Subnetzen.
Nun will ich erreichen, dass der Rechner 10.30.10.100 (in einem grünen Subnetz) auch aus dem Netz
10.30.20.0/24 erreichbar ist. Das erstere ist ein Server im Lehrernetz, das zweitere ein getrenntes Subnetz für Tablets, die nur für Lehrer da sind. Meine ACE im Layer3-Switch lautet daher so:
Die Regel 92 sollte meiner Meinung nach dafür sorgen, dass die “Subnetz-Grenze durchbrochen” wird und ich auf die IP im anderen Subnetz zugreifen kann. Das funtioniert aber nicht. (Ich bin mir bei der Platzhaltermaske im Ziel-IP-Bereich übrigens nicht sicher, wie die aussehen muss, wenn es nur EIN Rechner ist: 0.0.0.0 oder 0.0.0.255?)
Leider funktioniert das so aber nicht. Ich erreiche den Rechner nicht. Zusätzlich habe ich daher auf dem IPFire eine Regel erstellt, die fast genauso wie Regel 92 aussieht. Trotzdem weiterhin ohne Erfolg.
Hast du eine weitere Idee, woran es scheitert? Sowas ist ja auch ganz gerne mal ein Gateway-Problem … also: die Daten kommen zwar an – aber nicht zurück??
Du benötigst noch eine Regel, die die Antworten des Rechners 10.30.10.100/32 in das 10.30.20.0/24 zulässt, falls es auf dem VLAN Interface des 10.30.20.0/24 (VLAN X) Netzes eine gebundene ACL gibt, weil ein L3-Switch nicht stateful arbeitet. → Regel 92 in die andere Richtung! Die ACL des VLAN X Interfaces muss um diese Regel erweitert werden.
Danke – jetzt ist es klar. Und jetzt weiß ich auch, wo mein Denkfehler die ganze Zeit lag … der Rückweg läuft ja gar nicht über das Servernetz (VLAN.11) sondern über das VLAN.50 (bei dir X) … Natürlich!
Ich setze das gleich mal so um.
[etwas später] … hmm - die Theorie ist jetzt klar; in der Praxis klappt es leider immernoch nicht. Die zweite Regel habe ich für das andere VLAN genau umgekehrt angelegt. Ein tracepath auf die IP sagt aber nur
1: localhost
1: gateway
1: gateway
2: no reply …
6: no reply.
Es stimmt also leider noch etwas anderes nicht
Michael
Hallo @morpweb!
Ja, in diesem Fall fällt die Zeichnung allerdings sehr klein aus, denn bisher sind es nur zwei VMs, die beide auf einem Proxmox-Server laufen. Die eine hängt in VLAN.60 und die andere in VLAN.50. That’s all – dazwischen ist der Hypervisor und der Layer3-Swtich.
Ich hatte zwischendurch auch wieder den hinteren Eintrag ;1;0 in der subnets-Datei ausprobiert, aber auch der hat nicht geholfen. Der IPFire logged ebenfalls nichts. Es ist wahrscheinlich nur noch eine Kleinigkeit … aber wo/wie danach suchen?
Vielleicht ist es aber doch ein Gateway-Problem, denn wenn ich die Seite aufrufe, gibt es im Browser kein “Verbindung konnte nicht aufgebaut werden” sondern es lädt und lädt und lädt … dazu dieser Screenshot:
a) Was sagt denn ein ping?
b) Hat der Zielrechner ein Default GW gesetzt? Ist es Pingbar?
c) Was sagt denn ein tcpdump am Zielrechner. Kommen Pakete an?
Die Sache sollte aus meiner Sicht so klappen. Weder Server noch Firewall sind in die Kommunikation involviert.
Hi.
ping kommt nicht an
Da beide Rechner ihre IP via dhcp bekommen (sind beide in der workstations-Datei eingetragen), bekommen sie auch ihr GW vom Server. Das ist dann ja die jeweilige .254-Adresse für das Subnet; also 10.30.20.254 für den einen und 10.30.10.254 für den anderen (sind natürlich beide auf dem L3-Switch eingetragen).
Der Zielrechner ist im anderen Subnet ein Win10-Server (10.30.10.100). Der kann die Kommunikation natürlich noch selbst verweigern??
Michael
Hi.
Ok, das kann es auch noch sein.
Ist die per default so eingestellt, dass alles (aus anderen Subnetzen) gedropped wird? Sonst müsste ja irgendeine Meldung im Browser erscheinen??
(Kann aber gerade nicht selbst genauer nachsehen – bin unterwegs…)
Hi.
Gerade habe ich die Windows-Firewall (kompletten Dienst unter Win10) abgeschaltet, um zu schauen, ob es das war. Leider komme ich weiterhin nicht durch. Fehlt da nicht doch noch irgendeine (statische) Route vom einen zum anderen Netz? Bei den ACE/ACL stelle ich ja nur die “Erlaubnis” ein aber nicht die Routen selbst?!?
Ok, jetzt bin ich etwas schlauer aber immernoch nicht am Ziel.
Ich habe zum Testen eine neue ACE erstellt, die alles zulässt (Protokoll beliebig, Quelle beliebig, Ziel beliebig) und habe diese Regel an meine beiden VLANs 50 und 60 gebunden. Und siehe da: Sie können sich pingen! Es muss also offenbar keine weitere Route her. Das Prinzip funktkioniert.
Daher ist jetzt klar, dass es an meinen ACE-Regeln liegen muss, die im Moment eingetragen sind. Ich sehe den Fehler aber weiterhin nicht – wahrscheinlich mittlerweile Betriebsblindheit
Es ist ja hoffentlich nicht so, dass die Prioritäten in beiden VLANs die gleichen Nummern haben müssen oder sowas?!?
Hier nochmal die beiden Screenshots.
Das ist VLAN.60, das zusätzlich auf die IP 10.30.10.100 zugreifen können soll:
sehe da auch keinen Fehler. Regel 91 und 11 sind meiner Meinung nach nicht notwendig. Ich würde versuchen, für Regel 95 und 20 die Protokollierung zu aktivieren, um die abgelehnten Pakete zu sehen.
Hi,
Ok, das kann ich machen. Regel 91 und 11 hatte ich reingenommen, damit das Subnet auch untereinander andere Clients sehen kann. Meiner Meinung nach ging das ohne diese Regeln vorher nicht.
Ich berichte weiter … und hoffe, dass sich das noch klärt.
Ok, ich habe in dieser Sache nicht locker gelassen und habe die ACE/ACL Regeln hin- und hergewälzt. Nachdem ich damit partout nicht weitergekommen bin, habe ich im Nachbarforum nochmal genauer nachgefragt und siehe da: Es kann auch am Hypervisor liegen. Die (vermutete) Lösung des Problems kommt aber in einen neuen Thread, damit das mehr ins Auge fällt … das Problem haben vermutlich noch andere, die Proxmox einsetzen.
)
