Laboratori di rete Docs Apri simulatore →

ACL per WLAN sull'AP: filtrano il traffico dei client wireless

I campi aclIn/aclOut del profilo policy, precedentemente archiviati come riferimenti inerti, ora filtrano effettivamente il traffico del client wireless. Costruisci una WLAN ospite con aclIn: GUEST_BLOCK_INTERNAL che nega il traffico dai client verso 10.0.0.0/8; Il tentativo di PHONE di raggiungere un IP aziendale viene interrotto all'AP (PacketDropped contrassegnato con il nome ACL) mentre scorre il traffico Internet pubblico.

Apri questo laboratorio nel browser →

Gratis · senza installazione · senza account

Scenario

Le reali implementazioni wireless Cisco applicano ACL per WLAN. I telefoni vocali ottengono un ACL che consente SIP/RTP e nega il TCP generale. I client guest ottengono un ACL che consente a HTTP/HTTPS di accedere a intervalli pubblici e nega l'accesso alla rete interna. Gli ACL fanno riferimento al profilo policy e si applicano al piano dati: - aclIn: traffico DAL client wireless AL lato cablato (uplink). Valutato al momento dell'incapsulamento dell'AP. - aclOut: traffico DAL lato cablato AL client wireless (downlink). Valutato al momento dell'incapsulamento del WLC prima dell'invio nel tunnel. Slice M collega i campi IR aclIn/aclOut esistenti nel percorso dati effettivo. Flusso di risoluzione: 1. Il client wireless emette un pacchetto (o il downlink arriva al WLC). 2. Trovare l'AP unito → controller unito → tag policy → prima voce WLAN/policy → profilo policy → nome aclIn (uplink) o aclOut (downlink). 3. Cercare l'ACL denominato sull'accessLists del controller. 4. Valutare il pacchetto interno rispetto alle voci dell'ACL. 5. Autorizza → continua (incapsula e inoltra). Nega → emetti PacketDropped con il motivo wlan-acl: '<NAME>' denied …, salta l'incapsulamento. Cosa è differito: - Applicazione solo FlexConnect: gli AP reali in modalità di commutazione centrale vengono applicati al WLC; Gli AP FlexConnect vengono applicati localmente. Entrambi i simulatori si riducono a "valutare una volta al momento dell'emissione" e il verdetto è lo stesso. - Corrispondenza con stato: TCP established funziona (il valutatore ACL lo supporta già), ma il filtraggio completo in grado di riconoscere il collegamento è il livello successivo. - ACL basate sul tempo: i riferimenti all'intervallo di tempo funzionano (IR esistente), ma la rivalutazione a metà flusso non è modellata.

Topologia

2 × router, 1 × controller wireless, 1 × switch, 1 × access point, 1 × client wifi · Cisco IOS-XE-style

Cosa farai

  1. Prova engine.emitWirelessClientPacket({ deviceId: 'GUEST_PHONE', dst: parseIPv4('10.40.0.5') }). La destinazione 10.40.0.5 rientra nella regola deny ip any 10.0.0.0/8, quindi l'ACL si attiva sull'AP e il pacchetto non raggiunge mai il cavo. Pcap non dovrebbe mostrare alcun frame di uplink CAPWAP-Data; un evento PacketDropped contrassegnato con AP1 trasporta reason: "wlan-acl: 'GUEST_BLOCK_INTERNAL' denied …".

Apri questo laboratorio nel browser →

Altri laboratori su questo tema

Questo laboratorio in altre lingue

Per-WLAN ACLs at the AP — filter wireless client trafficPro-WLAN-ACLs am AP – filtern den Datenverkehr von drahtlosen ClientsACL por WLAN en el AP: filtra el tráfico de clientes inalámbricosACLs por WLAN no AP — filtre o tráfego do cliente sem fioACL par WLAN au niveau du point d'accès: filtre le trafic des clients sans filएपी पर प्रति-डब्ल्यूएलएएन एसीएल - वायरलेस क्लाइंट ट्रैफ़िक को फ़िल्टर करेंAP 处的每 WLAN ACL — 过滤无线客户端流量AP での WLAN ごとの ACL — ワイヤレス クライアント トラフィックをフィルタリングしますAP의 WLAN별 ACL — 무선 클라이언트 트래픽 필터링ACL для каждой WLAN на точке доступа — фильтрация трафика беспроводных клиентов.AP'deki WLAN başına ACL'ler — kablosuz istemci trafiğini filtreleyinACL trên mỗi mạng WLAN tại AP - lọc lưu lượng máy khách không dây