8
Problem mit Access-Listen (TPLink-Switch-TL-SG3428)
Ich möchte eine Verbindung auf einem Layer 3-Switch von tp-link verhindern:
Quelle 192.168.40.3 angeschlossen an Gi1/0/1 im vlan40 (int vlan 40: 192.168.40.220/24)
Ziel 192.168.41.1 angeschlossen an Gi1/0/17 im vlan41 (int vlan 41:192.168.41.220/24).
Da das Binden an das vlan-Interface 40 nicht funktioniert hat und ich das Handbuch leider nicht eindeutig ist, habe ich alle anderen Bindings auch hinzugefügt:
Aber selbst das führt zu keiner Wirkung.
Da es meine erste ACL auf einem Switch dieses Herstellers ist, bin ich nicht sicher, ob ich nicht irgendwas vergessen habe.
Muss ich evtl. das Feature "ACL" irgendwo global erstmal einschalten?
Oder ist die ACL-Logik einfach anders als bei Cisco?
Vielen Dank für Eure Unterstützung
Quelle 192.168.40.3 angeschlossen an Gi1/0/1 im vlan40 (int vlan 40: 192.168.40.220/24)
Ziel 192.168.41.1 angeschlossen an Gi1/0/17 im vlan41 (int vlan 41:192.168.41.220/24).
access-list create 500
access-list ip 500 rule auto deny logg ena protocol 6 sip 192.168.40.3 sip-mask 255.255.255.255 dip 192.168.41.1 dip-mask 255.255.255.255
access-list ip 500 rule auto permit logg disDa das Binden an das vlan-Interface 40 nicht funktioniert hat und ich das Handbuch leider nicht eindeutig ist, habe ich alle anderen Bindings auch hinzugefügt:
access-list bind 500 interface vlan 40
access-list bind 500 interface vlan 41
access-list bind 500 interface gi 1/0/1
access-list bind 500 interface gi 1/0/17Aber selbst das führt zu keiner Wirkung.
Da es meine erste ACL auf einem Switch dieses Herstellers ist, bin ich nicht sicher, ob ich nicht irgendwas vergessen habe.
Muss ich evtl. das Feature "ACL" irgendwo global erstmal einschalten?
Oder ist die ACL-Logik einfach anders als bei Cisco?
Vielen Dank für Eure Unterstützung
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2411764169
Url: https://administrator.de/forum/problem-mit-access-listen-tplink-switch-tl-sg3428-2411764169.html
Ausgedruckt am: 25.12.2024 um 15:12 Uhr
8 Kommentare
Neuester Kommentar
Nein, die ACL Logik an sich ist nicht anders als bei Cisco und eigentlich hast du alles richtig gemacht mit Ausnahme der Bindung der ACL auf die physischen Interfaces, das ist falsch. Zum eigentlichen Fehler kommen wir später...
Die physischen Interfaces eines L3 Switches arbeiten rein im Layer 2 Mode, kennen also nur Mac Adressen und wissen nix von IP.
Das routende IP Interface ist immer das korrespondierende VLAN Interface, denn das hält die IP Adresse und ist ausschliesslich für das IPv4 Forwarding zuständig und dort muss dann auch die ACL hin da die ja auf IP Adressen filtert !
Deine ACL 500 ist also per se syntaktisch richtig, denn sie blockiert alles was mit einer
Absenderhost IP 192.168.40.3/32 auf die Zielhost IP 192.168.41.1/32
geht. Soweit so gut...
Bedenke das ACL's nicht stateful sind und immer nur INBOUND gelten, sprich also VOM Draht INS Interface hinein und es gilt: First match wins bedeutet das nach einem Hit der Rest der ACL nicht mehr abgearbeitet wird.
Wenn du einmal genau hinsiehst wirst du deinen Kardinalsfehler auch selber sehen ! 🧐
Du nutzt für beide Interfaces die gleiche ACL 500. Für das VLAN 40 IP Interface passt das ja noch aber für das VLAN 41 Interface ist diese Regel unsinnig und deshalb wirkungslos, denn dort können niemals IP Adressen mit einer .40.x Absender IP (Source) auftauchen sondern immer nur mit .41.x da ja VLAN 41 !
Deshalb greifen deine 500er Regeln dort nicht. Du benötigst also 2 ACL's.
So wäre es richtig:
ACL 540
DENY host source 192.168.40.3/32 destination 192.168.41.1/32
PERMIT source 192.168.40.0/24 any
ACL 541
DENY host source 192.168.41.1/32 destination 192.168.40.3/32
PERMIT source 192.168.41.0/24 any
Diese bindest du dann auf die VLAN IP Interfaces: //
access-list bind 540 interface vlan 40
access-list bind 541 interface vlan 41 /
So wird ein Schuh draus ! 😉
Die physischen Interfaces eines L3 Switches arbeiten rein im Layer 2 Mode, kennen also nur Mac Adressen und wissen nix von IP.
Das routende IP Interface ist immer das korrespondierende VLAN Interface, denn das hält die IP Adresse und ist ausschliesslich für das IPv4 Forwarding zuständig und dort muss dann auch die ACL hin da die ja auf IP Adressen filtert !
Deine ACL 500 ist also per se syntaktisch richtig, denn sie blockiert alles was mit einer
Absenderhost IP 192.168.40.3/32 auf die Zielhost IP 192.168.41.1/32
geht. Soweit so gut...
Bedenke das ACL's nicht stateful sind und immer nur INBOUND gelten, sprich also VOM Draht INS Interface hinein und es gilt: First match wins bedeutet das nach einem Hit der Rest der ACL nicht mehr abgearbeitet wird.
Wenn du einmal genau hinsiehst wirst du deinen Kardinalsfehler auch selber sehen ! 🧐
Du nutzt für beide Interfaces die gleiche ACL 500. Für das VLAN 40 IP Interface passt das ja noch aber für das VLAN 41 Interface ist diese Regel unsinnig und deshalb wirkungslos, denn dort können niemals IP Adressen mit einer .40.x Absender IP (Source) auftauchen sondern immer nur mit .41.x da ja VLAN 41 !
Deshalb greifen deine 500er Regeln dort nicht. Du benötigst also 2 ACL's.
So wäre es richtig:
ACL 540
DENY host source 192.168.40.3/32 destination 192.168.41.1/32
PERMIT source 192.168.40.0/24 any
ACL 541
DENY host source 192.168.41.1/32 destination 192.168.40.3/32
PERMIT source 192.168.41.0/24 any
Diese bindest du dann auf die VLAN IP Interfaces: //
access-list bind 540 interface vlan 40
access-list bind 541 interface vlan 41 /
So wird ein Schuh draus ! 😉
So wie deine ACL 540 ist, hatte ich es zuerst auch.
Auch nur auf dem VLAN-Interface 40 gebunden.
Für meinen Geschmack hätte das auch reichen sollen.
Das hatte nur leider NULL Effekt.
Daher habe ich - aus purer Verzweiflung - alle anderen Interfaces auch probiert.
Das das eher Unsinn war, ist mir schon klar. Aber Versuch macht kluch ...
Ergebnis: Auch nicht besser.
Hast du noch andere Ideen?
Global irgendwas "einschalten" muss ich für solche ACLs nix, oder?
Auch nur auf dem VLAN-Interface 40 gebunden.
Für meinen Geschmack hätte das auch reichen sollen.
Das hatte nur leider NULL Effekt.
Daher habe ich - aus purer Verzweiflung - alle anderen Interfaces auch probiert.
Das das eher Unsinn war, ist mir schon klar. Aber Versuch macht kluch ...
Ergebnis: Auch nicht besser.
Hast du noch andere Ideen?
Global irgendwas "einschalten" muss ich für solche ACLs nix, oder?
Hab jetzt mal spaßhalber das hier auf int vlan 40 und 41 gebunden:
access-list create 500
access-list ip 500 rule 10 deny logging disable
Nach meinem Verständnis sollte gar nix mehr zwischen den beiden VLANs geroutet werden.
Ich kann aber immer noch alles machen.
Nur shutdown auf dem Interface hätte das wohl verhindert
Wo ist mein Denkfehler?
access-list create 500
access-list ip 500 rule 10 deny logging disable
Nach meinem Verständnis sollte gar nix mehr zwischen den beiden VLANs geroutet werden.
Ich kann aber immer noch alles machen.
Nur shutdown auf dem Interface hätte das wohl verhindert
Wo ist mein Denkfehler?
Per se ist alles richtig. Das User Handbuch beschreibt IP basierte ACLs im Part 27, Seite 798
Die Aussage im Handbuch das die ACL dann auf das VLAN Interface gebunden wird und inbound arbeitet ist absolut klar:
"You can bind the ACL to a port or a VLAN. The received packets on the port or in the VLAN will then be matched and processed according to the ACL rules. An ACL takes effect only after it is bound to a port or VLAN."
Einen etwas unklaren Punkt gibt es aber generell zu den ACLs:
Im Vorwort (Overview, Seite 792) zum Part 27 steht das zwingend eine "Time Range" zur ACL definiert sein muss.
Es ist bei deinem o.a. Verhalten zu vermuten das diese Time Range bei dir fehlt und die ACL deshalb NICHT aktiviert ist.
Wenn es das nicht sein sollte musst du einen TP-Link Support Call aufmachen.
Die Aussage im Handbuch das die ACL dann auf das VLAN Interface gebunden wird und inbound arbeitet ist absolut klar:
"You can bind the ACL to a port or a VLAN. The received packets on the port or in the VLAN will then be matched and processed according to the ACL rules. An ACL takes effect only after it is bound to a port or VLAN."
Einen etwas unklaren Punkt gibt es aber generell zu den ACLs:
Im Vorwort (Overview, Seite 792) zum Part 27 steht das zwingend eine "Time Range" zur ACL definiert sein muss.
Es ist bei deinem o.a. Verhalten zu vermuten das diese Time Range bei dir fehlt und die ACL deshalb NICHT aktiviert ist.
Wenn es das nicht sein sollte musst du einen TP-Link Support Call aufmachen.
Finde ich zwar strange, hab' es aber eben probiert.
Auch keine Wirkung.
Die Counter bleiben auch auf 0.
Auch keine Wirkung.
Die Counter bleiben auch auf 0.
Dann ist das wohl ein Bug in der TP-Link Firmware des Switches. Hast du die auf das aktuellste Firmware Image geflasht ?
Da musst du dann einen Case mit der TP-Link Hotline aufmachen. Syntaktisch hast du alles richtig gemacht. Du könnest nochmal einen Auszug deiner CLI Konfig dieser Interfaces und ACLs posten nur um das nochmal zu kontrollieren.
Bedenke das in den ACLs immer die Reihenfolge stimmen muss ! Die DENY Regel muss immer als Erste dort stehen was du aber ja eigentlich auch gemacht hast.
Da musst du dann einen Case mit der TP-Link Hotline aufmachen. Syntaktisch hast du alles richtig gemacht. Du könnest nochmal einen Auszug deiner CLI Konfig dieser Interfaces und ACLs posten nur um das nochmal zu kontrollieren.
Bedenke das in den ACLs immer die Reihenfolge stimmen muss ! Die DENY Regel muss immer als Erste dort stehen was du aber ja eigentlich auch gemacht hast.
Hat sich seit heute erledigt.
Die Firmware ist wirklich buggy.
Ich habe jetzt eine Beta eingespielt und sofort ging das anfängliche Regelwerk einwandfrei (Die Regeln aus der Frage waren nur ein kleiner Auszug).
https://static.tp-link.com/upload/beta/2021/202108/20210825/TL-SG3428v2_ ...
Gefunden habe ich das in einem anderen Forum:
https://community.tp-link.com/en/business/forum/topic/273612
Der Support hat mir auch bestätigt, dass das eine Datei von denen ist.
Traurig nur, dass die nicht wussten, dass diese Beta mir geholfen hätte.
@aqui: Vielen lieben Dank für deine Unterstützung!
Die Firmware ist wirklich buggy.
Ich habe jetzt eine Beta eingespielt und sofort ging das anfängliche Regelwerk einwandfrei (Die Regeln aus der Frage waren nur ein kleiner Auszug).
https://static.tp-link.com/upload/beta/2021/202108/20210825/TL-SG3428v2_ ...
Gefunden habe ich das in einem anderen Forum:
https://community.tp-link.com/en/business/forum/topic/273612
Der Support hat mir auch bestätigt, dass das eine Datei von denen ist.
Traurig nur, dass die nicht wussten, dass diese Beta mir geholfen hätte.
@aqui: Vielen lieben Dank für deine Unterstützung!
Vielen lieben Dank für deine Unterstützung!
Immer gerne... 😊Bei diesen Chinesen Kisten darf man eben nicht zu anspruchsvoll sein was Funktion und Firmware Support und vor allem Hotline Support anbetrifft.
Besonders traurig da das ja eine wichtige Funktion ist und das die diese Firmware noch nicht einmal in ihrem offizellen Support Portal pflegen. Hier hilft es manchmal auf die US oder die original China Support Seite zu schauen.
Du solltest da zyklisch immer mal reinschauen, denn mit einer Beta Firmware sollte man eigentlich nicht produktiv gehen !
"You get what you pay for...!" Wie immer.
Aber klasse wenns nun rennt wie es soll. Case closed !
