Veri merkezlerinde ağı sadece bölmek yeterli değildir. Bir ağdaki sorun diğer ağları etkilememelidir. Bunun için trafiğin hangi ağdan çıkacağı ve hangi yolu izleyeceği baştan net olmalıdır. Aksi halde küçük bir yapılandırma hatası tüm sistemi etkileyebilir.
Bu rehberimizde Ubuntu 24.04 üzerinde ağ yapısını daha düzenli ve kontrollü hale getireceğiz. Netplan ile temel ağ yapısını kuracağız. Ardından VRF kullanarak ağları birbirinden ayıracağız. Son olarak FRR ile trafiğin nasıl yönleneceğini dinamik olarak yöneteceğiz.
Ağ Tasarım ve Katman Mantığı
Ağ tasarımı bir sistemin temel taşıdır. Doğru tasarım yapılmadığında sistem büyüdükçe karmaşıklık ve güvenlik açıkları artar.
Katman 2 Tasarımı
Katman 2 seviyesinde hedef, fiziksel altyapıyı mantıksal bölümlere ayırmaktır. Bizim senaryomuzda üç temel VLAN grubu bulunmaktadır:
- VLAN 10/20/30: Mikroservisler ve konteynerler için iç ağ bölgeleri.
- VLAN 4001-4003: Gateway, Router ve ISP gibi dış dünyaya açılan uplink hatları.
Bizim senaryomuzda üç temel VLAN grubumuz bulunuyor. İlk grubumuz yönetim trafiği için ayrılmış durumda. İkinci grubumuz iç ağdaki konteyner trafiğini taşıyor. Üçüncü grubumuz ise dış dünyaya açık olan servisler için kullanılıyor. Bu ayrım sayesinde bir ağdaki güvenlik açığı diğerlerini doğrudan etkilemiyor.
*Katman 2 seviyesinde routing yapılmaz. Sadece trafiğin doğru kapıya ulaşması sağlanır.
Katman 3 Tasarımı
Standart bir Linux kurulumunda tüm trafik tek bir ana kapıdan geçer. VRF (Virtual Routing and Forwarding) kullanarak sistem içinde bağımsız sanal yönlendiriciler oluşturuyoruz.
- Güvenlik ihlalleri ilgili VRF içinde hapsedilir.
- Kernel seviyesinde tam izolasyon sağlanır.
- Aynı IP blokları farklı VRF’lerde çakışmadan kullanılabilir.
Neden ayrı VM yerine VRF?
Her ağ bölgesi için ayrı bir sanal makine kurmak mümkün olsa da, tek bir sistem üzerinde VRF kullanmak kaynak verimliliği, yönetilebilirlik ve çekirdek seviyesinde izolasyon açısından daha doğru bir yaklaşımdır.
Mesela bir web sunucunuz PUB VRF hacklenirse, saldırganın iç ağdaki veritabanına INT VRF routing üzerinden sızmasını donanımsal bir firewall varmışçasına engellemiş olursunuz
Netplan Yapılandırması
Ubuntu 24.04’te tüm ağ yapılandırması /etc/netplan/ altındaki YAML dosyalarıyla yapılır. Bu bölümde fiziksel kartlar, VLAN’lar, bridge’ler ve VRF bağlaması birlikte kurgulanır.
Netplan Dosyasını Oluşturalım
sudo nano /etc/netplan/01-netcfg.yamlFiziksel Kartları Tanımlayalım
Fiziksel kartlara doğrudan IP vermiyoruz. Bunları yalnızca VLAN taşıyıcısı olarak kullanıyoruz.
ethernets:
ens18: {} # Dış dünya (Gateway / Router)
ens19: {} # İç ağ (konteyner / VM trafiği)VLAN Yapılarını Oluşturalım
vlans:
vlan10: { id: 10, link: ens19 }
vlan20: { id: 20, link: ens19 }
vlan30: { id: 30, link: ens19 }
vlan4001: { id: 4001, link: ens18 }
vlan4002: { id: 4002, link: ens18 }
vlan4003: { id: 4003, link: ens18 }*Bu ID’ler switch tarafındaki trunk yapılandırmasıyla birebir uyumlu olmalıdır.
Bridge Yapılarını Kurmak
Bridge’ler, konteynerlerin veya sanal makinelerin bağlandığı mantıksal switch’lerdir.
bridges:
br10:
addresses: [10.10.0.1/24, "2001:DB8:1234:A000::1/64"]
interfaces: [vlan10]
br20:
addresses: [10.11.0.1/24, "2001:DB8:1234:B000::1/64"]
interfaces: [vlan20]
br30:
addresses: [10.9.0.1/24, "2001:DB8:1234:9000::1/64"]
interfaces: [vlan30]
br4002:
addresses: ["FE80::4002:3/64"]
interfaces: [vlan4002]
br4003:
addresses: ["FE80::4003:3/64"]
interfaces: [vlan4003]VRF Tanımı ve Bridge’lere Bağlama
vrfs:
INT:
table: 120
interfaces: [br4002, br20]
PUB:
table: 130
interfaces: [br4003, br30]Bu noktadan sonra
- INT VRF → iç trafik
- PUB VRF → dışa açık trafik
tamamen ayrı routing tablolarında çalışır.
Yapılandırmayı Uygulama
sudo netplan applyFRR (Free Range Routing) Yapılandırması
Netplan altyapıyı kurar, FRR ise trafiğin nasıl akacağını belirler. FRR, Ubuntu’yu gerçek bir kurumsal router haline getirir.
FRR Kurulumu
curl -s https://deb.frrouting.org/frr/keys.gpg | sudo tee /usr/share/keyrings/frrouting.gpg
echo deb '[signed-by=/usr/share/keyrings/frrouting.gpg]' https://deb.frrouting.org/frr $(lsb_release -s -c) frr-stable | sudo tee /etc/apt/sources.list.d/frr.list
sudo apt update
sudo apt install frr frr-pythontoolsServislerin Aktif Edilmesi
/etc/frr/daemons dosyasında ilgili protokolleri yes konumuna getirelim.
bgpd=yes
ospfd=yes
ospf6d=yes
staticd=yesBurada ospf6d protokolü IPv6 yönlendirmesi için hayati önem taşır. IPv4 için ospfd yeterlidir ancak güncelde IPv6 her zaman önceliklidir.
FRR Yönlendirme Ayarları
FRR yapılandırması Cisco cihazlara çok benzer bir kabuk olan vtysh üzerinden yapılır. Burada en önemli kural her VRF için bağımsız bir OSPF süreci başlatmaktır. Yönlendiricimizin diğer cihazlarla konuşabilmesi için komşuluk kurması gerekir. Bunun için vtysh içerisinde arayüz bazlı tanımlamalar yapıyoruz.
ipv6 forwarding
!
vrf INT
ipv6 route 2001:db8:1234:2000::/60 blackhole
exit-vrf
!
interface br20
ipv6 ospf6 area 1
ipv6 ospf6 network broadcast
ipv6 ospf6 passive
exit
!
router ospf6 vrf INT
ospf6 router-id 10.2.0.1
redistribute static
area 1 stub
exitSık Sorulan Sorular
Bu yapı hangi senaryoda kullanılmalı?
Bu mimari küçük ve tek ağlı sistemlerde gereksiz karmaşıklık yaratır. Tek VLAN, tek uplink ve statik routing yeterliyse VRF fayda sağlamaz. DNS ve izleme servisleri ek yapılandırma gerektirir.
Bu nedenle basit ve ölçeklenmeyecek altyapılarda bu yapı önerilmez.
VRF kullanmazsan ne bozulur?
VRF kullanılmadığında tüm ağ trafiği tek bir yönlendirme tablosunda toplanır.
- Asimetrik routing ve geri dönüş problemleri
- Farklı uplink’lerin birbirinin trafiğini etkilemesi
- Firewall ve policy kurallarının karmaşıklaşması
- Aynı IP bloklarının tekrar kullanılamaması
VRF olmadan ağ, mantıksal olarak ayrılmış görünür ama çekirdek seviyesinde izole değildir.
Bu mimari hangi ölçekte mantıklı, nerede overkill?
Bu yapı aşağıdaki senaryolarda mantıklı ve önerilir.
- 3+ VLAN ve birden fazla uplink bulunan sistemler
- Çoklu müşteri veya çoklu ağ bölgesi barındıran altyapılar
- IPv6 kullanılan veya kullanılacak olan ortamlar
- Konteyner, mikroservis ve edge router senaryoları
- BGP veya dinamik routing planlanan yapılar
Ancak şu durumlarda overkill kabul edilebilir.
- Tek uplink, tek ağ, statik routing yeterliyse
- Geliştirme veya kısa ömürlü test ortamlarıysa
- Ağ ekipmanları ve Linux routing bilgisi sınırlıysa
