Forwarding modu çoğu zaman kurulum sihirbazında bir kez seçilip unutulur. Oysa bu seçim kullanıcı trafiğinin kablolu ağa nerede çıkacağını, politikanın nerede uygulanacağını ve WAN kesildiğinde şubenin ne kadarının çalışmaya devam edeceğini belirler.
Modların nasıl çalıştığı; DHCP paketinin yolu, VLAN’ın nerede olması gerektiği ve ayarın her üreticide nerede durduğu AP Online Ama İstemci IP Alamıyor yazısında anlatıldı. Kısaca hatırlatmak gerekirse, bridge’de trafik AP’nin switch portundan, tunnel’da tünelin bittiği cihazdan (controller, gateway, FortiGate ya da MX) kablolu ağa çıkar.
Bu yazının konusu mimari karar: hangi SSID hangi modda çalışmalı ve neden? Yedi ölçüte bakacağız: roaming, politika noktası, merkezi darboğaz, MTU, WAN dayanıklılığı, broadcast ve misafir trafiği.
Senaryo
| Yer | Ağ |
|---|---|
| Merkez | VLAN 20 personel 10.0.20.0/24, VLAN 60 misafir 10.0.60.0/24, controller 10.0.50.2, DHCP ve DNS 10.0.30.11, firewall 203.0.113.1 |
| Şube | 10.2.0.0/16; AP’ler 10.2.50.0/24, kullanıcılar 10.2.10.0/24; merkeze IPsec tüneliyle bağlı |
Aynı iki SSID, iki yerde dört ayrı karar gerektirir:
| SSID | Yer | Belirleyici soru |
|---|---|---|
| FC-Personel | Merkez | Kullanıcılar katlar arasında dolaşıyor; VLAN 20 her kata taşınabiliyor mu? |
| FC-Misafir | Merkez | Misafir trafiği kampüs ağına girmeden merkezde denetlenmeli mi? |
| FC-Personel | Şube | WAN kesilirse şube çalışmaya devam etmeli mi? |
| FC-Misafir | Şube | Misafir internete merkezden mi, şubeden mi çıkmalı? |
Roaming: VLAN nerede biter?
İstemci AP değiştirdiğinde IP adresini koruyabilir mi? Bridge’de bunun cevabı kablolu ağın tasarımındadır. Yeni AP istemciyi aynı VLAN’a ve aynı alt ağa bırakıyorsa adres korunur. Katlar ayrı L3 alt ağlarındaysa istemci yeni adres almak zorundadır. Aruba bunu “hard roam” olarak adlandırır: istemci yeni IP ve gateway alır, açık oturumlar kopar.
Tunnel’da iki AP aynı roaming alanındaysa, yani aynı controller’a ya da aynı gateway kümesine tünel kuruyorsa, trafik aynı yerde kablolu ağa çıkar ve VLAN değişmez. Farklı controller’lara ya da kümelere bağlı AP’ler arasında bu garanti yoktur. Aruba AOS 10’da kesintisiz roaming için tek koşul, iki AP’nin de aynı birincil gateway kümesine bağlı olmasıdır.
Bridge’de roaming alanını büyütmek, VLAN’ı da büyütmek demektir. Aruba, kendi AOS 10 bridge roaming tasarımı için ortak yönetim ve kullanıcı VLAN’ları boyunca doğrulanmış üst sınırı 500 AP ve 5.000 bridge istemci olarak verir. Bu, genel bir Wi-Fi sınırı değil, o tasarıma ait bir değerdir. Daha büyük ağlar için gateway kümesiyle merkezi VLAN’ları ya da L3 ile ayrılmış birden çok alanı önerir; alanlar arası geçiş yine hard roam olur. Meraki’de L3 roaming için trafik bir MX concentrator’da toplanır.
Merkez personel için: VLAN 20 core’daki tek SVI’dan tüm erişim switch’lerine trunk ile taşınıyorsa bridge yeterlidir. Kat başına ayrı alt ağ tasarlanmışsa ya tunnel seçilir ya da katlar arası hard roam kabul edilir.
Politika nerede uygulanır?
Bridge’de politika AP’de ya da kenarda uygulanır. Aruba’da bridge modda kimlik doğrulayıcı AP’dir; istemcinin VLAN’ına ve rolüne AP karar verir. Cisco FlexConnect local switching’de ACL’ler Flex Profile ile AP’ye gönderilir. Trafik AP’den çıktıktan sonra core’daki ACL’lere ve firewall’a kadar kampüs ağında taşınır.
Tunnel’da trafiğin tamamı merkez cihazdan geçer. Aruba’da kimlik doğrulayıcı gateway’dir. Fortinet’te tunnel moddaki SSID, FortiGate’te bir arayüz olur ve trafik FortiGate politikasından geçer.
Merkez misafir için: Tunnel, misafir trafiğini kampüs VLAN’larına hiç dokunmadan merkezdeki gateway’e ya da firewall’a taşır. Cisco’nun şube tasarım rehberindeki örnekte de personel SSID’leri yerelde, misafir SSID’si ise DMZ’deki bir controller’a tünellenir. Bridge de geçerli bir seçenektir; bu durumda VLAN 60’ın iç ağdan ayrılması kablolu tarafın işidir (Segmentasyon ve DMZ).
Şube misafir için: Merkeze tünellemek, misafir internetini WAN ve VPN üzerinden merkezdeki firewall’a taşır; bant genişliği ve MTU bedeli vardır. Yerel çıkış ise şubede firewall ve segmentasyon ister.
Tünelin maliyeti: darboğaz ve MTU
Merkezi darboğaz: Tunnel’da controller ya da gateway tüm istemci trafiğinin toplandığı noktadır. Cisco bu yüzden tünelli ölçümlerde controller’ın kendisinin darboğaz olabileceğini belirtir. Merkez cihazın kapasitesi, uplink’i ve lisansı tasarıma girer. Bu modda iPerf3 sunucusunun nereye konacağı PHY hızı ve iPerf3 yazısında.
MTU: Tünel her pakete dış IP ve tünel başlığı ekler. Yol MTU’su 1500 baytsa istemcinin tam boyutlu paketi tünele sığmaz; ya yolun MTU’su büyük olmalı ya da paket parçalanmalı veya küçültülmelidir.
Üreticiler bu konuda farklı sınırlar koyar:
- Huawei: S5700/S6700 V200R022C00 WLAN-AC rehberine göre tunnel forwarding modunda AC ve AP kablosuz veri için IP parçalamayı desteklemez. Yol MTU’su bu modda doğrudan bir tasarım koşuludur.
- Cisco: AP’ler CAPWAP yol MTU’sunu keşfeder. Bu keşif yalnızca 576, 1005 ve 1485 değerlerini dener ve AP ile WLC arasındaki CAPWAP yolunun MTU’sunu bulmak içindir; istemci paketine kalan yükü veren genel bir tünel hesabı değildir. Cisco’nun 17.9.3 ile hazırladığı belgeye göre IOS AP’lerde bu değerlere Ethernet başlığı dahil değildir, AP-COS’ta dahildir.
- Meraki: Yerelinde Auto VPN’li bir MX bulunan sitede SSID’yi ayrıca bir concentrator’a tünellemek “çift tünel” oluşturur. Meraki bu kurulumu önermez ve MTU sorunlarına işaret eder.
Şubedeki AP merkeze IPsec üzerinden bağlanıyorsa IPsec de kendi başlığını ekler. Tunnel kararı verilmeden önce WAN yolunun MTU’su bilinmelidir.
Controller ya da WAN giderse ne olur?
Şube için bridge’in en sık söylenen avantajı WAN kesintisine dayanıklılıktır. Ama bu “her şey çalışır” anlamına gelmez. Mevcut istemcileri yeni istemcilerden ayırmak ve her bağımlılığın nerede durduğuna bakmak gerekir.
- Mevcut istemciler: Bridge’de veri trafiği controller’dan geçmediği için şube içi trafik devam edebilir. Cisco’ya göre standalone moddaki FlexConnect AP son bilinen yapılandırmayla çalışmaya devam eder ve local switching istemcileri etkilenmez. Fortinet’e göre bridge moddaki FortiAP’ye bağlı istemciler kablosuz ve kablolu ağa erişmeyi sürdürür.
- Yeni istemciler: Kimlik doğrulama merkezdeki RADIUS’a gidiyorsa yeni istemci bağlanamaz. Yerel bir çözüm önceden kurulmalıdır: Cisco’da şubedeki bir RADIUS sunucusu, Fortinet’te
local-standalone, Huawei’de AP üzerinde yerel kimlik doğrulama (aşağıda). - DHCP: Şubenin DHCP’si merkezdeyse yeni istemci adres alamaz, mevcut istemcinin kira yenilemesi başarısız olur.
- DNS: İç DNS merkezdeki 10.0.30.11 ise ad çözümü durur.
- İnternet: Şubenin internete çıkışı da merkezdeki firewall üzerindense internet erişimi kesilir.
Tunnel’da ise veri trafiği merkezdeki tünel ucuna ulaşamadığı için şubedeki tünelli SSID WAN kesintisinden doğrudan etkilenir.
Şube personel için: Bridge, yalnızca yerel kimlik doğrulama, yerel DHCP ve DNS ve gerekiyorsa yerel internet çıkışıyla birlikte planlanırsa WAN kesintisine dayanıklıdır.
Broadcast ve ölçek
Bridge’de broadcast ve multicast çerçeveleri VLAN’ın tamamına yayılır ve VLAN’daki her cihaz bunları işlemek zorundadır. Roaming için VLAN’ı büyütmek bu yükü de büyütür. Tunnel’da bu trafiği gateway taşır. Aruba AOS 10’da her AP için bu görevi üstlenen gateway, broadcast ve multicast trafiğini o AP’nin tüneliyle gönderir.
Huawei, aynı AP’de direct forwarding ve tunnel forwarding VAP’lerinin birlikte kullanılmasını önermez; direct forwarding VAP’indeki kullanıcılar multicast trafiği iki yoldan birden alabilir.
Karar akışı ve karma çözümler
Seçim SSID başına yapılabilir; aynı ağda iki modun birlikte kullanılması yaygındır:
- Cisco: FlexConnect AP’de her WLAN local ya da central switching olabilir.
- HPE Aruba: Mixed modda istemcinin VLAN’ı bridge ya da tunnel’a karar verir. Bridge ve tunnel istemciler için ayrı VLAN’lar gerekir; aynı VLAN hem bridge hem tunnel olamaz.
- Huawei: Tunnel modundaki VAP’te
split-tunnel aclile ACL’nin eşleştiği trafik doğrudan forwarding ile çıkar (WLAN AC V200R019C00). - Meraki: Teleworker senaryosunda split tunnel, seçilen trafiği VPN’den, kalanını yerel ağdan gönderir.
Bizim senaryomuz için sonuç:
| SSID | Yer | Öneri | Gerekçe |
|---|---|---|---|
| FC-Personel | Merkez | Bridge | VLAN 20 tüm katlarda; politika core ve firewall’da |
| FC-Misafir | Merkez | Tunnel ya da ayrılmış VLAN ile bridge | Misafir trafiği kampüs ağına girmeden denetlenir |
| FC-Personel | Şube | Bridge + yerel bağımlılıklar | WAN kesintisinde mevcut ve yeni istemciler için plan |
| FC-Misafir | Şube | Yerel çıkış varsa bridge, yoksa tunnel | Tunnel’da WAN bant genişliği ve MTU kontrol edilir |
Aynı karar dört üreticide
Aşağıdaki bilgiler resmî dokümanlardan alındı ve laboratuvarda denenmedi. Ayarın üreticide nerede yapıldığı AP Online Ama İstemci IP Alamıyor yazısında.
Huawei
Huawei’nin AC ve Fit AP V200R010C00 yapılandırma rehberindeki şube örneğinde VAP direct forwarding kullanır ve VAP profiline keep-service enable allow new-access eklenir. AP’de yerel kimlik doğrulama tanımlanır. Böylece WAN kesilip AC ile bağlantı koptuğunda şube kullanıcıları 802.1X ile AP üzerinden bağlanabilir. Rehber bu süredeki mevcut oturumların durumunu ve tunnel forwarding davranışını açıklamaz; bu yüzden bu konularda bir şey söylemiyoruz.
Tunnel modunda kablosuz veri için IP parçalama desteklenmez (V200R022C00) ve aynı AP’de direct ve tunnel VAP’lerini karıştırmak önerilmez.
Cisco Catalyst 9800 ve Meraki
Catalyst 9800: Local mode AP’de trafik merkezde (central switching), FlexConnect’te WLAN başına yerelde ya da merkezde çıkar. Cisco’nun FlexConnect şube rehberine göre:
- Standalone moddaki AP son bilinen yapılandırmayla çalışır; local switching istemcileri devam eder.
- Yeni 802.1X istemcileri, şubede erişilebilir bir RADIUS sunucusuyla doğrulanabilir.
- WAN yolunun MTU’su en az 500 bayt olmalıdır; veri için en fazla 300 ms, veri ve ses için 100 ms gidiş-dönüş gecikmesi önerilir.
Meraki: SSID bridge, NAT ya da bir MX concentrator’a tünelli olabilir. WPA2-Enterprise tünelli SSID’de kimlik doğrulayıcı MX’tir. Concentrator yedekliliği için MX’ler HA çifti olarak kurulur. Meraki’ye göre MX Dashboard ağından kaldırılırsa SSID’ler bağlantıyı korumak için otomatik olarak bridge moda geçer. Bu bir yapılandırma değişikliğinin sonucudur; WAN kesintisinde uygulanan bir davranış değildir.
HPE Aruba Networking (AOS 10)
Bridge’de kimlik doğrulayıcı ve rol kararı AP’de, tunnel ve mixed’de gateway’dedir. Tunnel profili isteğe bağlı olarak ikincil bir gateway kümesine geçebilir. Bridge roaming için verilen 500 AP / 5.000 istemci değeri, Aruba’nın ortak VLAN’larla kurulan bridge roaming tasarımına aittir. Bridge ile tunnel istemcileri aynı VLAN’ı paylaşamaz.
Fortinet
Tunnel modunda SSID FortiGate’te bir arayüzdür ve trafik FortiGate politikasından geçer. FortiAP 7.4.4 yapılandırma rehberine göre:
- Bridge moddaki FortiAP controller ile bağlantısını kaybederse bağlı istemciler kablosuz ve kablolu ağa erişmeyi sürdürür.
local-standalone, controller erişilemezken uygun koşullarda yeni istemci bağlantılarına izin verir: SSID bridge modda olmalı, güvenlik modu rehberde desteklenenlerden biri olmalı ve seçenek açılmalıdır. Varsayılan olarak kapalıdır.- Local bridge, wireless mesh özellikleriyle birlikte kullanılamaz.
Karşılaştırma
| Kesintide yeni istemci | Karma seçenek | Dikkat | |
|---|---|---|---|
| Huawei | keep-service enable allow new-access + AP’de yerel kimlik doğrulama |
split-tunnel acl |
Tunnel’da kablosuz veri için IP parçalama yok |
| Cisco 9800 | Şubede RADIUS ile 802.1X | WLAN başına local / central | WAN MTU en az 500 bayt, gecikme sınırları |
| Meraki | Bu yazıda doğrulanmadı | Teleworker split tunnel | Auto VPN’li sitede çift tünel önerilmez |
| HPE Aruba | Bu yazıda doğrulanmadı | Mixed mod, ayrı VLAN’larla | 500 AP / 5.000 istemci yalnızca bridge roaming tasarımı için |
| Fortinet | local-standalone, desteklenen güvenlik modlarıyla |
Bu yazıda doğrulanmadı | Local bridge mesh ile kullanılamaz |
Sonuç
Bridge ile tunnel arasındaki seçim bir performans ayarı değil, trafiğin ve politikanın nerede yaşayacağına dair bir mimari karardır. Bridge kenarda çıkar, ölçeklenir ve şubede WAN kesintisine dayanıklı olabilir; ama roaming alanı ve broadcast yükü VLAN tasarımına bağlıdır, dayanıklılık da DHCP, DNS, RADIUS ve internet bağımlılıkları kadar sağlamdır. Tunnel roaming’i ve merkezi denetimi kolaylaştırır; bedeli merkezde kapasite, yolda MTU ve WAN’a bağımlılıktır. Karar SSID başına verilir.
Kaynaklar
- HPE Aruba Networking: AOS 10 Forwarding modes of operation
- Cisco: Understand FlexConnect on 9800 Wireless Controller
- Cisco: Catalyst 9800 FlexConnect Branch Deployment Guide
- Cisco: Understand CAPWAP AP PMTU Discovery
- Cisco: Wi-Fi 6/6E ve Wi-Fi 7 Throughput Testing
- Huawei: AC ve Fit AP V200R010C00 yapılandırma rehberi, WAN kimlik doğrulama kaçışı örneği
- Huawei: WLAN AC V200R019C00, split-tunnel
- Huawei: S5700/S6700 V200R022C00 WLAN-AC, Licensing Requirements and Limitations
- HPE Aruba Networking Central: AOS 10 tunnel forwarding (GRE ve IPsec)
- Meraki: SSID Tunneling and Layer 3 Roaming
- Fortinet: FortiAP 7.4.4, How to configure a FortiAP local bridge
- Fortinet: FortiAP 7.4.4, Configuring WPA2-Personal security (tunnel SSID ve politika)