VLAN ve Network Bonding Rehberi

Modern veri merkezi ve kurumsal ağ yapılarında yalın bir IP atamasının ötesine geçmek kaçınılmazdır. Uygulama trafiğini yönetim trafiğinden ayırmak, veritabanı segmentini son kullanıcıdan izole etmek veya fiziksel bir kablo/kart arızasında bağlantıyı hiç düşürmeden devam ettirmek istiyorsanız, **VLAN** ve **Network Bonding** kavramları masaya yatırılması gereken iki temel yapı taşıdır. Bu yazı, Linux tarafında her iki teknolojinin nasıl çalıştığını, hangi senaryolarda hangi modların seçilmesi gerektiğini ve bonding + VLAN kombinasyonunun üretim ortamlarında nasıl güvenli şekilde devreye alınacağını uçtan uca ele alır.

VLAN Nedir, Neden İhtiyaç Duyulur?

**VLAN** (Virtual Local Area Network), IEEE 802.1Q standardı ile tanımlanan, fiziksel olarak tek bir switch veya kablo üzerinden birden fazla **mantıksal ağ** geçirmeyi sağlayan bir teknolojidir. Aynı fiziksel hat üzerinden "Yönetim", "Müşteri Trafiği", "Veritabanı Ağı" gibi birbirinden tamamen izole broadcast domainleri taşıyabilirsiniz. VLAN'lar, trafiği L2 seviyesinde ayırır; aynı fiziksel altyapıyı paylaşsalar bile bir VLAN'daki cihaz diğerinin broadcast paketlerini görmez, dolayısıyla gereksiz trafik, güvenlik sızıntısı ve yönetim karmaşası ortadan kalkar.

Kurumsal ölçekte VLAN kullanmanın üç temel gerekçesi vardır:

1. **Segmentasyon ve güvenlik:** Veritabanı sunucusunu sadece uygulama sunucusunun görmesi, son kullanıcı trafiğinin veritabanına hiçbir şekilde ulaşamaması gerekir. VLAN'lar arasına konacak bir güvenlik duvarı katmanı ile bu kontrolü merkezi olarak sağlarsınız.

2. **Broadcast domain daraltma:** Yüzlerce cihazın olduğu düz bir ağda ARP, DHCP ve diğer broadcast trafiği gereksiz yere büyür. VLAN'lar bu trafiği küçük, yönetilebilir gruplara böler.

3. **Coğrafi esneklik:** Aynı VLAN'a bir binanın farklı katlarındaki, farklı binalardaki veya hatta farklı şehirlerdeki switch portlarını dahil edebilirsiniz. Fiziksel olarak ayrı yerlerdeki cihazlar mantıksal olarak aynı ağda olur.

VLAN'lar trunk (birden fazla VLAN'ı aynı anda taşıyan) ve access (tek VLAN'a hizmet veren) olmak üzere iki port tipi üzerinden çalışır. Bir Linux sunucu trunk portuna bağlandığında, gelen paketin hangi VLAN'a ait olduğunu belirten 4 byte'lık **802.1Q etiketini** okur ve uygun sanal arayüze yönlendirir.

VLAN Etiketleme Mekanizması (802.1Q)

802.1Q etiketi, Ethernet çerçevesinin Source MAC adresinden sonra eklenen 4 byte'lık bir alandır. Bu alanın yapısı şöyledir:

**TPID (Tag Protocol Identifier, 2 byte):** Sabit değer `0x8100`. Bu değeri gören alıcı, "bu çerçeve VLAN etiketli" der.
**PCP (Priority Code Point, 3 bit):** QoS için kullanılır; ses trafiği gibi öncelikli paketler yüksek PCP ile işaretlenir.
**DEI (Drop Eligible Indicator, 1 bit):** Yoğunlukta öncelikle düşürülecek trafiği belirtir.
**VID (VLAN Identifier, 12 bit):** 0–4095 arasında VLAN numarası. **0** ve **4095** rezerve, **1** varsayılan, **4094** eski Cisco protokolüne ait olduğundan pratikte **2–4094** arası kullanılır.

**Native VLAN** kavramı ayrıca dikkat edilmesi gereken bir konudur. Trunk portlar, etiketlenmemiş gelen çerçeveleri "native VLAN" olarak kabul eder. Üretim ortamlarında **native VLAN'ın 1'den farklı bir VLAN olarak ayarlanması ve etiketli hale getirilmesi** en iyi pratiktir; aksi halde "double tagging" saldırılarıyla bir VLAN'dan diğerine trafik sızdırmak mümkün olabilir.

Network Bonding Nedir, Neden Kullanılır?

**Bonding** (veya takım adıyla **NIC teaming**), birden fazla fiziksel ağ kartını tek bir mantıksal arayüzde birleştirir. İki temel faydası vardır:

**Yedeklilik (failover):** Bir kart, kablo veya port arızalandığında trafik diğer karta otomatik olarak geçer; sunucu bağlantı kaybetmez.
**Bant genişliği artırma (load balancing):** Birden fazla kart tek bir IP altında çalışarak toplam throughput'u yukarı çeker.

Linux bonding sürücüsü 7 farklı mod destekler. Üretim ortamlarında karşılaşılan üç ana mod şunlardır:

Mode 0: balance-rr (Round-Robin)

Paketleri sırayla her slave'e yollar. Switch tarafında özel bir yapılandırma gerektirmez ama **paket sırası bozulabilir**; TCP gibi sıra duyarlı protokollerde yeniden gönderimler artar. Modern donanımda önerilmez.

Mode 1: active-backup

Yalnızca bir slave aktif çalışır, diğeri boşta bekler. Aktif slave'in linki düştüğünde, yedek slave birkaç yüz milisaniye içinde devreye girer. **Switch tarafında hiçbir özel yapılandırma gerektirmediğinden**, yönetilmeyen switch'lerin olduğu ortamlarda en güvenli seçimdir. Bant genişliği artışı sağlamaz, yalnızca yedeklilik sağlar.

Mode 4: 802.3ad (LACP)

**LACP** (Link Aggregation Control Protocol), IEEE 802.3ad standardıdır. Sunucu ile switch arasında **LACPDU** kontrol paketleri değiş tokuş edilerek hangi linklerin aggregation'a dahil olacağı dinamik olarak kararlaştırılır. Hem yedeklilik hem bant genişliği sağlar; ancak switch tarafında LACP desteği ve uygun konfigürasyon zorunludur. Üretim ortamlarında LACP desteği olan switch varsa **tercih edilen mod** budur.

Mode 5/6: balance-tlb / balance-alb

TLB (Transmit Load Balancing) sadece gönderim yönünde yük dağıtır; ALB (Adaptive Load Balancing) alma yönünde de ARP negotation ile dağıtım yapar. Switch bağımsız çalışırlar ama gerçek anlamda yedeklilik ve throughput birlikte sağlamazlar, bu yüzden yerlerini genelde mode 1 veya mode 4'e bırakırlar.

Linux Bonding Modları: Karşılaştırma Tablosu

|-----|----|----------------|-------------|----------------|----------------|

Ubuntu / Debian: Netplan ile VLAN Yapılandırması

Ubuntu 18.04 sonrasında varsayılan ağ yapılandırma aracı **Netplan**'dır. VLAN'lar netplan'da `vlans:` anahtarı altında tanımlanır. Örnek olarak tek bir `eth0` arayüzü üzerinden VLAN 10 (uygulama ağı) ve VLAN 20 (veritabanı ağı) tanımlayalım:


# /etc/netplan/01-vlan.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
      dhcp6: false
  vlans:
    vlan10:
      id: 10
      link: eth0
      addresses:
        - 10.10.10.5/24
      routes:
        - to: default
          via: 10.10.10.1
    vlan20:
      id: 20
      link: eth0
      addresses:
        - 10.20.20.5/24

Uygulama ve doğrulama:


sudo chmod 600 /etc/netplan/01-vlan.yaml
sudo netplan apply
ip -d link show vlan10    # VLAN bilgisi: id 10, link eth0
ip addr show vlan10       # IP ataması kontrolü

Bu yapılandırmada `eth0` fiziksel arayüzün kendisine IP atanmaz; yalnızca trunk modunda çalışarak VLAN etiketli trafiği kabul eder. Switch tarafında ilgili portun **trunk modunda** ve VLAN 10 ile VLAN 20 için **tagged** yapılandırılması gerekir. Aksi halde switch VLAN etiketlerini yorumlamaz ve sunucuya ulaşan trafik bozuk olur.

CentOS / RHEL: nmcli ile VLAN Yapılandırması

RHEL tabanlı dağıtımlarda NetworkManager komut satırı aracı `nmcli` en hızlı yoldur:


# VLAN 10 arayüzü oluştur
sudo nmcli con add type vlan con-name vlan10 ifname vlan10 dev eth0 id 10
sudo nmcli con mod vlan10 ipv4.addresses 10.10.10.5/24
sudo nmcli con mod vlan10 ipv4.gateway 10.10.10.1
sudo nmcli con mod vlan10 ipv4.method manual

# VLAN 20 arayüzü oluştur
sudo nmcli con add type vlan con-name vlan20 ifname vlan20 dev eth0 id 20
sudo nmcli con mod vlan20 ipv4.addresses 10.20.20.5/24
sudo nmcli con mod vlan20 ipv4.method manual

sudo nmcli con up vlan10
sudo nmcli con up vlan20
nmcli con show            # aktif bağlantıları listele

Ubuntu / Debian: Netplan ile Bonding

İki fiziksel kartı active-backup modunda bonding yapmak için:


# /etc/netplan/02-bond.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
    eth1:
      dhcp4: false
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses:
        - 10.10.10.5/24
      routes:
        - to: default
          via: 10.10.10.1
      parameters:
        mode: active-backup
        primary: eth0
        mii-monitor-interval: 100
        fail-over-mac-policy: active

Doğrulama:


sudo netplan apply
cat /proc/net/bonding/bond0

`/proc/net/bonding/bond0` çıktısında `Bonding Mode`, `Currently Active Slave`, `MII Status` ve `Slave Interface` satırları görülür. Bu çıktı, bonding'in gerçekten kurulup kurulmadığının ve hangi slave'in aktif olduğunun birinci elden kanıtıdır.

CentOS / RHEL: nmcli ile Bonding


# Bond arayüzü oluştur
sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup
sudo nmcli con mod bond0 ipv4.addresses 10.10.10.5/24
sudo nmcli con mod bond0 ipv4.method manual
sudo nmcli con mod bond0 ipv4.gateway 10.10.10.1

# Slave'leri ekle
sudo nmcli con add type ethernet ifname eth0 master bond0
sudo nmcli con add type ethernet ifname eth1 master bond0

# Aktifleştir
sudo nmcli con up bond0

LACP (Mode 4) Konfigürasyonu

LACP, üretim ortamlarında switch tarafında karşılığı olan bir konfigürasyon gerektirir. Linux tarafında netplan ile LACP bond tanımı:


network:
  version: 2
  renderer: networkd
  ethernets:
    eth0: {dhcp4: no}
    eth1: {dhcp4: no}
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [10.0.0.5/24]
      gateway4: 10.0.0.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

**`lacp-rate: fast`** parametresi, LACP kontrol paketlerinin saniyede bir yerine 30 saniyede bir gönderilmesini sağlar. Switch tarafında da `lacp_rate` ayarının eşleşmesi zorunludur; uyuşmazlık durumunda link her 30 saniyede bir flap eder. **Mismatched LACP rate** en sık karşılaşılan LACP konfigürasyon hatasıdır.

Switch tarafında Cisco IOS örneği:


interface range GigabitEthernet0/1 - 2
 channel-group 1 mode active
 channel-protocol lacp

Bonding + VLAN: Üretim Kombinasyonu

Kurumsal ortamlarda en yaygın senaryo budur: önce bonding ile fiziksel yedeklilik sağlanır, sonra bu bond arayüzü üzerine VLAN'lar kurularak mantıksal segmentasyon elde edilir. Yani bir kablo veya NIC arızasında trafik diğer kola geçer, VLAN yapısı bozulmaz.


# /etc/netplan/03-bond-vlan.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0: {dhcp4: no}
    eth1: {dhcp4: no}
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      parameters:
        mode: active-backup
        primary: eth0
        mii-monitor-interval: 100
  vlans:
    vlan10:
      id: 10
      link: bond0
      addresses: [10.10.10.5/24]
    vlan20:
      id: 20
      link: bond0
      addresses: [10.20.20.5/24]

Bu yapı şu hiyerarşiyi oluşturur: `eth0/eth1` → `bond0` → `vlan10`, `vlan20`. Yani çekirdek seviyesinde önce bond oluşur, ardından bu bond üzerinde VLAN subinterface'leri yaratılır.

Mikrotik Tarafında VLAN ve Trunk

Sunucu tarafını yapılandırdıktan sonra switch/router tarafında da aynı VLAN yapısını kurmak gerekir. RouterOS'ta örnek:


# VLAN arayüzlerini oluştur
/interface vlan add name=vlan10-app interface=ether1 vlan-id=10
/interface vlan add name=vlan20-db interface=ether1 vlan-id=20

# IP atamaları (VLAN tarafı)
/ip address add address=10.10.10.1/24 interface=vlan10-app
/ip address add address=10.20.20.1/24 interface=vlan20-db

# Trunk port (sunucuya giden hat)
/interface bridge port set [find interface=ether2] tagged=bridge-lan

Sunucuya giden port **tagged trunk** olmalı, yani VLAN 10 ve VLAN 20'yi etiketli olarak geçirmelidir. Sunucuya bakan portu access modunda bırakırsanız yalnızca tek VLAN geçer, diğer VLAN'a ulaşamazsınız.

VLAN'lar Arası Erişimi Firewall ile Kontrol Etmek

VLAN'lar L2 seviyesinde izole olsa da aralarındaki trafiği bir **L3 routing cihazı** (router/L3 switch) yönlendirir. Bu routing katmanında güvenlik duvarı kuralları ile hangi VLAN'ın hangi porta hangi VLAN'a erişebileceğini sınırlandırabilirsiniz. Tipik senaryo: uygulama sunucusunun (vlan10) veritabanına (vlan20) yalnızca 3306 portundan ulaşabilmesi, başka hiçbir trafiğin geçmemesi.

Mikrotik örneği:


/ip firewall filter add chain=forward \
  in-interface=vlan10-app out-interface=vlan20-db \
  protocol=tcp dst-port=3306 action=accept comment="App -> DB MySQL"

/ip firewall filter add chain=forward \
  in-interface=vlan10-app out-interface=vlan20-db \
  action=drop comment="App -> DB default deny"

Bu kural çifti "default deny" prensibini uygular: önce spesifik olarak izin verdiğiniz trafiği açarsınız, sonra o VLAN çifti için geri kalan her şeyi düşürürsünüz.

Linux tarafında aynı kontrolü nftables ile yapmak da mümkündür; ancak VLAN'lar arası trafiği yöneten asıl cihaz L3 switch/router olduğu için merkezi yönetim açısından switch üzerinde kurallar koymak daha pratiktir.

Bonding Yedekliliğini Test Etmek

Bonding yapılandırmasının gerçekten yedekli çalıştığını doğrulamadan üretime almak risklidir. Aşağıdaki testler, slave'in arıza simülasyonunu yapar:


# Aktif slave'i "kopar"
sudo ip link set eth0 down

# Bağlantı devam ediyor mu kontrol et
ping -c 5 8.8.8.8

# Aktif slave eth1'e geçti mi?
cat /proc/net/bonding/bond0
# "Currently Active Slave: eth1" satırını görmelisin

# eth0'ı geri aç
sudo ip link set eth0 up

LACP kullanıyorsanız switch tarafında da link down olduğunda ilgili portun LACP partner state'inin **"down"**'a geçtiğini kontrol edin. Sadece Linux tarafında değil, switch üzerinde de link aggregation'ın sağlıklı çalıştığını doğrulamak gerekir.

Yaygın Hatalar ve Çözümleri

**Hata 1: VLAN ID switch'te uyuşmuyor.** Sunucu VLAN 10'a IP atıyor ama switch tarafında ilgili port için VLAN 11 trunk'a alınmış. Çözüm: switch tarafında trunk port yapılandırmasını kontrol edin, doğru VLAN ID'lerinin **tagged** olarak eklendiğinden emin olun.

**Hata 2: LACP rate uyumsuzluğu.** Linux'ta `lacp-rate: fast` ayarlı, switch'te `slow` (varsayılan). Link her 30 saniyede bir flap eder. Çözüm: iki tarafı da aynı değere getirin; üretim ortamında `fast` tercih edilir.

**Hata 3: Bond mode ile switch yapılandırması uyuşmuyor.** Linux'ta `mode: 802.3ad` seçilmiş ama switch tarafında statik EtherChannel (LACP kapalı) yapılmış. Bond asla "up" olmaz. Çözüm: switch tarafında LACP `active` veya `passive` modunu etkinleştirin.

**Hata 4: Slave'lerin hızı/duplex'i farklı.** 1 Gbps ile 10 Gbps kartları bonding'e dahil etmek Linux bonding sürücüsünde mümkün değildir. LACP her iki tarafta aynı hız/duplex ister. Çözüm: aynı hız ve duplex'te NIC'ler kullanın.

**Hata 5: Netplan uygulandı ama değişiklik görünmüyor.** Muhtemelen `renderer` Systemd-networkd yerine NetworkManager olarak kalmış. Çözüm: `netplan --debug generate` ile renderer'ı doğrulayın, gerekirse `network:` altında `renderer: networkd` zorlayın.

Netplan Debug ve Troubleshooting

Üretim ortamında yapılandırma hatalarının hızlı tespiti için:


# Netplan YAML'ı derlerken hata ayıklama
sudo netplan --debug generate

# Yapılandırmanın uygulandığını doğrulama
sudo netplan get

# Tüm arayüzlerin durumu
ip -br addr
ip -d link show bond0
ip -d link show vlan10

# Bonding detayları
cat /proc/net/bonding/bond0

# VLAN istatistikleri
cat /proc/net/vlan/config

`/proc/net/vlan/config` çıktısı, sistemdeki tüm VLAN arayüzlerini ve hangi fiziksel arayüze bağlı olduklarını gösterir. Beklenen VLAN'lar burada görünmüyorsa modül yüklenmemiş veya netplan doğru uygulanmamış olabilir.

Performans İzleme ve Bakım

VLAN ve bonding kurulumu tamamlandıktan sonra izleme tarafında şu metriklere bakılmalıdır:

**Bond slave'lerin link durumu:** `/proc/net/bonding/bond0` çıktısını periyodik olarak toplayın. `link failure count` artıyorsa kablo veya port sorunlu olabilir.
**VLAN trafik istatistikleri:** `ip -s link show vlan10` ile RX/TX hata ve drop sayılarına bakın.
**MTU uyumu:** Bond ve VLAN arayüzlerinin MTU'su trunk üzerinden geçen en büyük frame'e uygun olmalı. Jumbo frame kullanıyorsanız tüm katmanda MTU 9000 olmalı; VLAN etiketi 4 byte eklediği için fiziksel MTU 9004 olmalıdır.

Üretim ortamlarında bu kontrolleri Zabbix, Prometheus + node_exporter veya benzeri izleme araçlarıyla otomatikleştirmek, fiziksel katman sorunlarını bağlantı kopmalarına dönüşmeden önce yakalamayı sağlar.

En İyi Uygulamalar (Best Practices)

1. **Bond modu olarak LACP (mode 4) tercih edin**; switch LACP destekliyorsa hem yedeklilik hem bant genişliği sağlar.

2. **Native VLAN'ı 1'den farklı seçin** ve tagged yapın; double-tagging saldırılarına karşı varsayılan VLAN'ın kullanılması zafiyet oluşturur.

3. **Tüm VLAN'lar arası geçişi bir L3 cihazda firewall kurallarıyla sınırlayın.** Default deny prensibiyle başlayın, spesifik olarak izin verin.

4. **VLAN ID planlaması yaparken 0, 1, 4094, 4095 gibi rezerve değerlerden kaçının; 2–4094 aralığını kullanın.**

5. **Yedekli güç kaynağı olan cihazlarda bile bonding kullanın.** Bir patch panel portu veya transceiver arızalanırsa bonding tek başına bağlantıyı kurtarır.

6. **Netplan değişikliklerini `netplan try` ile uygulayın** (mevcutsa); 120 saniye içinde onaylamazsanız otomatik geri alır.

7. **Bond slave'lerinin hız ve duplex ayarlarının eşleştiğinden emin olun.** Switch tarafında portları `speed auto` yerine sabit `10000 full` gibi değerlere pinlemek tutarlılık sağlar.

8. **Üretimde VLAN trunk değişikliklerini mesai dışı saatlerde ve bakım penceresinde uygulayın.** Yanlış trunk konfigürasyonu sunucunun tamamen erişilemez olmasına yol açabilir.

Sonuç

VLAN ve Network Bonding, modern Linux ağ yapısının iki kritik yapı taşıdır. VLAN, tek fiziksel altyapı üzerinden birbirinden izole birden fazla mantıksal ağ taşımayı sağlayarak segmentasyon, güvenlik ve broadcast kontrolü sunar. Bonding ise fiziksel kartları birleştirerek yedeklilik veya bant genişliği sağlar. Üretim ortamlarında bu iki teknolojinin birlikte kullanımı — yani bonding interface üzerine VLAN'ların kurulması — hem fiziksel hem mantıksal katmanda dayanıklı bir ağ mimarisi oluşturur.

Yazı boyunca ele alınan netplan yapılandırmaları Ubuntu/Debian tarafında, `nmcli` örnekleri ise CentOS/RHEL tarafında hızlı kurulum için yeterli bir temel sunmaktadır. LACP kullanımı, native VLAN etiketleme, VLAN'lar arası firewall kontrolü ve bonding failover testleri üretime geçiş öncesinde mutlaka doğrulanması gereken adımlardır. Doğru yapılandırıldığında, bu iki teknoloji birlikte veri merkezi ağında yüksek erişilebilirlik ve sıkı güvenlik segmentasyonu sağlar; operasyonel karmaşıklığı minimumda tutarken ölçeklenebilir bir temel oluşturur.