Ağ Tünelleme: GRE, VXLAN, Geneve ve Overlay Ağ Teknolojileri

Ağ Tünelleme: GRE, VXLAN, Geneve ve Overlay Ağ Teknolojileri

Modern veri merkezi ve bulut ağları, fiziksel altyapı (underlay) üzerinde mantıksal ağlar (overlay) oluşturmak için tünelleme protokollerini kullanır. Tünelleme, bir paket başlığını başka bir protokolün başlığı içine sararak (encapsulation) iki ağ arasında uçtan uca bir kanal kurmaya yarar. Bu rehber, üretim ortamında karşılaşacağınız L3 tünelleme protokollerinden (GRE, IPIP, SIT) L2 overlay protokollerine (VXLAN, Geneve, NVGRE), VPN çözümlerinden (IPsec, WireGuard, OpenVPN) Linux ip link ile pratik tünel yönetimine kadar geniş bir alanı network engineer perspektifinden ele alır.

Buyukweb VDS bağlamı: KVM tabanlı VDS'lerinizde root erişim ile ip_tunnel, ip6_tunnel, vxlan, gre, wireguard ve ipip çekirdek modüllerinin tamamını yükleyebilirsiniz. Bu rehberdeki komutları doğrudan denemek için /vds-sunucu sayfamıza göz atabilirsiniz. Site-to-site senaryolar için /vpn-1-baglanti, /vpn-3-baglanti, /vpn-5-baglanti paketlerimiz son kullanıcı VPN ihtiyaçlarına yönelik tasarlanmıştır.

Tünelleme Neden Gerekli? Underlay vs Overlay

Klasik IP yönlendirmesinde paket A noktasından B noktasına ulaşmak için aradaki yönlendiriciler tarafından yorumlanır; her hop'ta TTL azalır, başlık alanları okunur. Underlay ağ budur: fiziksel/sanal yönlendiriciler ve anahtarlar.

Overlay ağ ise underlay üzerine kurulan mantıksal bir topolojidir. Underlay paketin fiziksel taşıyıcısıdır; overlay paketler kendi başlıklarıyla underlay paketlerinin içine sarılır (encapsulation). Sonuç: aynı fiziksel ağ üzerinde birbirinden izole edilmiş, kendi adres uzayına sahip, yerel ağ gibi davranan sanal ağlar oluşturulabilir.

[ Orijinal paket: payload ]
        ↓ encapsulation
[ Overlay header | Orijinal paket ]
        ↓ encapsulation (transport)
[ IP header | UDP/Protokol | Overlay header | Orijinal paket ]
        ↓ underlay üzerinden gönderim
[ Ethernet | IP | UDP/Protokol | Overlay | Original payload ]

Tünelleme/overlay teknolojilerinin tipik kullanım alanları:

• Veri merkezi multi-tenant: Aynı fiziksel ağ üzerinde binlerce kiracının izole L2 segmentleri (VXLAN/Geneve/EVPN)
• Site-to-site VPN: Şube ofisini merkez ofisine veya bulut VPC'sine güvenli bağlama (IPsec, GRE-over-IPsec, WireGuard)
• Remote access VPN: Tek bir kullanıcının kurumsal ağa güvenli bağlanması (OpenVPN, WireGuard, IKEv2)
• Konteyner ağları: Kubernetes pod-to-pod iletişimi (Calico VXLAN/IPIP, Cilium, Flannel VXLAN)
• IPv6 geçiş: IPv4-only altyapı üzerinden IPv6 trafiği taşımak (6in4/SIT, 6rd, 6to4)
• SDN kontrol düzlemi: Open vSwitch + VXLAN/Geneve ile programlanabilir ağlar
• Telco MPLS hizmetleri: VPLS, VPWS gibi pseudowire çözümleri

Tünelleme vs Encapsulation: Header in Header

Encapsulation, bir protokol başlığının başka bir protokol başlığı içine alınması işlemidir. Tünelleme iki uçta encapsulation/decapsulation yapan iki noktanın birbirine bağlandığı encapsulation türüdür: A noktası paketi sarar, B noktası açar. Aradaki underlay sadece dış başlığa bakar.

Bir VXLAN paketinin yığını şuna benzer:

+----------------------------------+
| Outer Ethernet Header            |  ← Underlay L2
+----------------------------------+
| Outer IPv4/IPv6 Header           |  ← Underlay L3 (VTEP IP'leri)
+----------------------------------+
| Outer UDP Header (dst 4789)      |  ← Transport
+----------------------------------+
| VXLAN Header (8 byte, VNI 24-bit)|  ← Overlay tanımlayıcı
+----------------------------------+
| Inner Ethernet Header            |  ← Overlay L2 (tenant MAC)
+----------------------------------+
| Inner IPv4/IPv6 Header           |  ← Tenant L3
+----------------------------------+
| Inner Payload (TCP/UDP + data)   |
+----------------------------------+

Underlay'in görevi sadece dış başlığa göre paketi hedef VTEP'e ulaştırmak. İçerideki kiracı trafiğinden underlay tamamen habersizdir. Bu ayrım decoupling sayesinde overlay topolojisini fiziksel altyapıdan bağımsız değiştirebilirsiniz.

L3 Tünelleme Protokolleri

GRE (Generic Routing Encapsulation, RFC 2784)

GRE, iki IP noktası arasında protokol-bağımsız bir tünel kurar. IP başlığı içine yerleştirilir; IP protokol numarası 47 ile tanımlanır. UDP/TCP üzerinden değil, doğrudan IP üzerinden çalışır.

GRE'nin güçlü yanları:

• Multicast taşıma yapabilir (IPsec saf hâliyle yapamaz)
• Routing protokollerini (OSPF, EIGRP, BGP) tünel üzerinden geçirebilir
• Basit, taşınması ucuz, geniş uyumlu
• Cisco ve Linux başta olmak üzere her platformda destek

Zayıf yanları:

• Şifresiz: trafik açık metin, mahremiyet için IPsec ile birleştirilir (GRE-over-IPsec)
• NAT geçişi sorunlu: NAT cihazları GRE'yi her zaman doğru taşımayabilir; mod nat-helper veya GRE PAT gerekir
• 24 byte ek başlık (4 byte GRE + 20 byte outer IPv4) → MTU hesabında dikkat

# Linux'ta GRE tüneli oluşturma — uçnokta A
ip tunnel add gre1 mode gre remote 198.51.100.20 local 203.0.113.10 ttl 64
ip link set gre1 up
ip addr add 10.10.10.1/30 dev gre1
ip route add 192.168.20.0/24 dev gre1

# Uçnokta B (simetrik)
ip tunnel add gre1 mode gre remote 203.0.113.10 local 198.51.100.20 ttl 64
ip link set gre1 up
ip addr add 10.10.10.2/30 dev gre1
ip route add 192.168.10.0/24 dev gre1

# GRE keepalive (Cisco standardı; Linux native değil ama BFD ile sağlanır)
# Linux tarafında BFD daemon kullanmak yaygın yöntem

# Tüneli kontrol et
ip tunnel show
ip -d link show gre1

mGRE ve DMVPN kavramı: Multipoint GRE, tek bir tünel arayüzünün birden fazla uzak noktayı taşımasına izin verir; NHRP (Next Hop Resolution Protocol) ile dinamik peer keşfi yapılır. Hub-and-spoke ile dynamic spoke-to-spoke senaryoları DMVPN mimarisinin temelini oluşturur. Linux dünyasında OpenNHRP projesi bu işlevin açık kaynak alternatifidir.

IPIP (IP-in-IP, RFC 2003)

GRE'den daha basit: 4 byte ek başlığa bile gerek yok, dış IPv4 başlığı doğrudan iç IPv4 paketini taşır. IP protokol numarası 4.

# IPIP tüneli
ip tunnel add ipip1 mode ipip remote 198.51.100.20 local 203.0.113.10
ip link set ipip1 up
ip addr add 10.20.20.1/30 dev ipip1

IPIP'in yaygın kullanım alanlarından biri Kubernetes CNI'larıdır (Calico'nun IPIP modu). Multicast taşıyamaz; sadece unicast IPv4 taşır.

SIT / 6in4 (RFC 4213)

IPv6 paketlerini IPv4 underlay üzerinden taşımak için kullanılır. Simple Internet Transition anlamına gelen SIT, IPv6 dağıtımının kademeli olduğu dönemde IPv6-only adaların IPv4 İnternet üzerinden konuşması için tasarlandı. IP protokol numarası 41.

# 6in4 tüneli (IPv6 over IPv4)
ip tunnel add sit1 mode sit remote 198.51.100.20 local 203.0.113.10
ip link set sit1 up
ip -6 addr add 2001:db8:cafe::1/64 dev sit1
ip -6 route add 2001:db8:beef::/64 dev sit1

IP6IP4, IP6IP6, IP4IP6

IPv6 underlay üzerinde IPv4 taşımak için IP4IP6 (RFC 2473), her iki yönde de IPv6 için IP6IP6. Modern dağıtımlar tüm bu varyantları ip-link(8) üzerinden destekler.

# IPv6 underlay üzerinde IPv4 taşıma
ip -6 tunnel add ipip6 mode ipip6 remote 2001:db8::20 local 2001:db8::10
ip link set ipip6 up
ip addr add 10.30.30.1/30 dev ipip6

L2 Overlay Protokolleri

VXLAN (RFC 7348)

Virtual eXtensible LAN, modern veri merkezi overlay'inin de facto standardıdır. L3 underlay üzerinde L2 segmentleri taşır; her segment 24-bit VNI (VXLAN Network Identifier) ile tanımlanır. Bu 16 milyondan fazla mantıksal ağ demektir — klasik 802.1Q VLAN'ın 4094 sınırının binlerce katı.

Paket yapısı:

Outer MAC | Outer IP | Outer UDP (dst 4789) | VXLAN (8B) | Inner Ethernet | Inner IP | Payload
                                                    ↑
                                              VNI: 24-bit

VXLAN, VTEP (VXLAN Tunnel Endpoint) adı verilen uçnoktaları kullanır. VTEP fiziksel sunucu, hipervizör, ToR switch veya bir Linux bridge olabilir. Trafik VTEP'lerde encapsulate/decapsulate edilir.

Kontrol düzlemi seçenekleri:

1. Multicast tabanlı: BUM (Broadcast/Unknown unicast/Multicast) trafiği underlay multicast grubuna gönderilir. PIM-SM gerektirir; modern ortamlarda nadiren tercih edilir.
2. Head-end replication / unicast static: Her VTEP, diğer VTEP'lerin listesini bilir; BUM trafiğini her birine ayrı kopya ile gönderir.
3. EVPN-VXLAN (BGP control plane): BGP EVPN adres ailesi (RFC 7432, RFC 8365) ile MAC ve IP adresleri kontrol düzleminde dağıtılır. MAC-VRF ile L2 izolasyon, IP-VRF ile L3 izolasyon. Üretim ortamlarında en gelişmiş çözüm. FRRouting, GoBGP, ticari NOS'lar bunu destekler.

# Linux'ta VXLAN — multicast tabanlı, VNI 100
ip link add vxlan100 type vxlan id 100 dstport 4789     group 239.1.1.100 dev eth0 ttl 32
ip link set vxlan100 up

# Bridge'e ekle (L2 bağlama için)
ip link add br0 type bridge
ip link set vxlan100 master br0
ip link set br0 up

# Unicast head-end (multicast yoksa) — peer'leri elle ekle
ip link add vxlan100 type vxlan id 100 dstport 4789 dev eth0 nolearning
bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 198.51.100.20
bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 198.51.100.30

# FDB'yi gözlemle
bridge fdb show dev vxlan100

# VXLAN istatistikleri
ip -s link show vxlan100

# Tüneli kaldır
ip link del vxlan100

VXLAN MTU notu: VXLAN encapsulation 50 byte ek başlık ekler (14 outer Eth + 20 outer IPv4 + 8 UDP + 8 VXLAN). Underlay MTU 1500 ise overlay MTU 1450 olur. Underlay'i jumbo frame (1600+ veya 9000) yaparak overlay'de standart 1500 MTU sağlanır.

Geneve (Generic Network Virtualization Encapsulation, RFC 8926)

Geneve, VXLAN'ın halefi olarak tasarlandı. Ana farkı TLV (Type-Length-Value) tabanlı genişletilebilir başlık: VXLAN'ın sabit 24-bit VNI'sının yanına metadata ekleyebilirsiniz. NSX, Open vSwitch, modern SDN denetleyicileri bunu kullanır.

Outer MAC | Outer IP | Outer UDP (dst 6081) | Geneve (8B+ TLV) | Inner ...

# Linux Geneve tüneli
ip link add geneve1 type geneve id 1000 remote 198.51.100.20
ip link set geneve1 up
ip addr add 10.40.40.1/30 dev geneve1

Geneve'nin TLV'leri sayesinde her paketin yanında session-id, security label, hatta bağlam bilgisi taşınabilir. NSX-T örneğinde mikrosegmentasyon politika işaretleri Geneve TLV'leriyle paketlere bindirilir.

NVGRE (RFC 7637)

Microsoft öncülüğünde tasarlanan NVGRE, GRE üzerinde overlay yapar. 24-bit VSID (Virtual Subnet ID) GRE Key alanında taşınır. Hyper-V Network Virtualization'da yaygındı; sektörel gelişme VXLAN/Geneve yönüne kayınca kullanım azaldı.

Outer MAC | Outer IP | GRE (24-bit VSID) | Inner Ethernet | Inner IP | Payload

STT (Stateless Transport Tunneling)

VMware'ın eski Open vSwitch günlerinde önerdiği bu protokol, TCP başlık biçimini taklit ederek NIC offload özelliklerinden faydalanmayı amaçlıyordu. Tarihsel ilgi dışında üretim kullanımı yok; Geneve standardı geldikten sonra terk edildi.

VPN Tünelleme Protokolleri

IPsec (RFC 4301-4309)

IPsec, ağ katmanında şifreleme ve kimlik doğrulama sağlayan protokol takımıdır: ESP (Encapsulating Security Payload), AH (Authentication Header), IKEv2 (Internet Key Exchange v2).

İki çalışma modu:

Mod	Encapsulation	Kullanım
Transport mode	Sadece payload şifrelenir, IP başlığı korunur	Host-to-host
Tunnel mode	Tüm IP paketi yeni IP başlığı içine sarılır + şifrelenir	Site-to-site, gateway-to-gateway

ESP vs AH:

• ESP (IP protocol 50): Şifreleme + (opsiyonel) kimlik doğrulama. Pratik uygulamada hâkim.
• AH (IP protocol 51): Sadece kimlik doğrulama, şifreleme yok. NAT geçemez (immutable header alanları). Modern dağıtımlarda nadiren kullanılır.

IKEv2 + ESP kombinasyonu güncel pratik. Anahtar değişimi UDP 500 (IKE) ve UDP 4500 (NAT-T) üzerinden yapılır. NAT-Traversal sayesinde IPsec NAT arkasından geçebilir; ESP paketleri UDP 4500 içine sarılır.

# strongSwan ile IKEv2 site-to-site (özet)
# /etc/swanctl/swanctl.conf
connections {
    site-to-site {
        version = 2
        local_addrs = 203.0.113.10
        remote_addrs = 198.51.100.20
        proposals = aes256-sha256-modp2048
        local { auth = psk; id = vds-bursa.example.com }
        remote { auth = psk; id = vds-istanbul.example.com }
        children {
            net-net {
                local_ts = 10.10.10.0/24
                remote_ts = 10.20.20.0/24
                esp_proposals = aes256gcm16-modp2048
                start_action = trap
            }
        }
    }
}

secrets {
    ike-psk { secret = "uzun-rastgele-paylasilan-anahtar" }
}

# Politika ve SA'ları yükle
swanctl --load-all
swanctl --list-sas
swanctl --list-conns

SPD (Security Policy Database) ve SAD (Security Association Database) kavramları IPsec'in çekirdek veri yapılarıdır. ip xfrm komutu Linux çekirdeğindeki bu veritabanlarını gösterir.

ip xfrm policy
ip xfrm state

WireGuard (Linux 5.6+ native)

WireGuard, modern, sade ve hızlı VPN protokolüdür. Curve25519 (anahtar değişimi), ChaCha20-Poly1305 (şifreleme + auth), BLAKE2s (hash), HKDF (anahtar türetme) gibi güncel kriptografik primitif'leri kullanır. Kod tabanı IPsec/OpenVPN'e kıyasla çok küçüktür (~4000 satır), denetlenebilirliği yüksektir.

# WireGuard Linux native — sunucu tarafı
modprobe wireguard
ip link add wg0 type wireguard

# Anahtar üret
umask 077
wg genkey | tee server-private.key | wg pubkey > server-public.key

# Yapılandırma uygula
wg set wg0 listen-port 51820 private-key ./server-private.key
ip addr add 10.50.50.1/24 dev wg0
ip link set wg0 up

# Peer ekle (istemci)
wg set wg0 peer <CLIENT_PUBKEY> allowed-ips 10.50.50.2/32 endpoint 198.51.100.5:51820

# Mevcut peer'leri ve transferi gör
wg show wg0

# wg-quick (config dosyasıyla)
# /etc/wireguard/wg0.conf
[Interface]
Address = 10.50.50.1/24
ListenPort = 51820
PrivateKey = <SERVER_PRIVKEY>

[Peer]
PublicKey = <CLIENT_PUBKEY>
AllowedIPs = 10.50.50.2/32

# Servis aktif
wg-quick up wg0
systemctl enable wg-quick@wg0

WireGuard'ın peer-based modeli IPsec'in karmaşık SA/SPD eşleşmesinden farklıdır: her peer bir public key + allowed IP listesiyle tanımlanır. Anahtar değiştirme, NAT keepalive (PersistentKeepalive), MTU ayarı (varsayılan 1420) basittir.

OpenVPN

OpenVPN, TLS tabanlı, OpenSSL kütüphanesini kullanan, UDP veya TCP üzerinde çalışan, sertifika tabanlı VPN çözümüdür. Standart port UDP 1194. tun (L3) veya tap (L2) sanal arayüz oluşturur.

# easy-rsa ile PKI (özet)
make-cadir ~/easy-rsa
cd ~/easy-rsa
./easyrsa init-pki
./easyrsa build-ca nopass
./easyrsa build-server-full server nopass
./easyrsa build-client-full client1 nopass
./easyrsa gen-dh

# OpenVPN sunucu yapılandırması (özet)
# /etc/openvpn/server.conf
port 1194
proto udp
dev tun
ca   /etc/openvpn/pki/ca.crt
cert /etc/openvpn/pki/issued/server.crt
key  /etc/openvpn/pki/private/server.key
dh   /etc/openvpn/pki/dh.pem
server 10.60.60.0 255.255.255.0
keepalive 10 60
cipher AES-256-GCM
auth SHA256
tls-version-min 1.2

systemctl enable --now openvpn-server@server

WireGuard ile karşılaştırma:

• WireGuard daha düşük gecikme, daha basit konfigürasyon, daha az CPU yükü
• OpenVPN daha esnek (TCP fallback, HTTP proxy üzerinden çalışabilir, mTLS ile katı kimlik doğrulama)
• OpenVPN sertifika iptal listesi (CRL), TLS handshake özelleştirmesi gibi kurumsal özelliklere sahip

L2TP/IPsec, SSTP, PPTP — Tarihçe

Protokol	Durum	Not
PPTP	Eskimiş, güvensiz	MS-CHAPv2 saldırılabilir; 2012'den beri pratikte kırılmış. Kullanmayın.
L2TP/IPsec	Çalışır ama hantal	L2TP kendi başına şifresiz; IPsec ile sarılması gerekir. Çift encapsulation maliyeti.
SSTP	Microsoft'a özgü	TCP 443 üzerinden TLS, firewall geçişi için elverişli. Linux desteği sınırlı.

Modern üretim ortamlarında WireGuard ve IKEv2/IPsec yeterlidir.

SDN, Overlay ve SD-WAN

SDN (Software-Defined Networking) overlay teknolojilerinden bağımsız bir kavramdır: kontrol düzleminin (control plane) veri düzleminden (data plane) ayrılması. OpenFlow gibi protokoller veya BGP EVPN gibi yöntemlerle kontrol merkezileştirilir.

SD-WAN, üzerine kurulduğu underlay (MTPL, İnternet, LTE) hangisi olursa olsun, şifreli overlay tüneller ile siteleri birbirine bağlayan ürün kategorisidir. Tipik olarak IPsec, GRE-over-IPsec veya WireGuard tabanlı tüneller üzerine application-aware politika, link kalitesi izleme, dinamik path seçimi ekler. Açık kaynak alternatifler: flexiWAN, Tinc, Wesher mesh çözümleri.

MPLS Pseudowire: Telco Bağlamı

MPLS (Multiprotocol Label Switching) servis sağlayıcı omurgalarında yaygın. Pseudowire kavramı, MPLS underlay üzerinde L2 servisleri taşımayı sağlar:

• VPWS (Virtual Private Wire Service): Noktadan noktaya L2
• VPLS (Virtual Private LAN Service): Çok noktalı L2 (sanki tek bir LAN)
• EVPN (Ethernet VPN): Modern yaklaşım, BGP kontrol düzlemi, MPLS veya VXLAN data düzlemi

Buyukweb VDS müşterilerinin doğrudan MPLS yapılandırması yapmasına nadiren gerek olur; servis sağlayıcı tarafında çalışır. Kavramsal farkındalık iletişimde fayda sağlar.

Linux ip-link Tunnel Yönetimi: Pratik Komutlar

Tüm modern tünel tipleri ip link veya ip tunnel ile yönetilir.

# Yüklü tünel modüllerini kontrol et
lsmod | grep -E 'gre|ipip|sit|vxlan|geneve|wireguard'

# Modülleri elle yükle
modprobe gre
modprobe ip_tunnel
modprobe ip6_tunnel
modprobe vxlan
modprobe geneve
modprobe wireguard

# Mevcut tüm tünelleri listele
ip tunnel show
ip -d link show type vxlan
ip -d link show type wireguard
ip -d link show type geneve

# FDB (forwarding database — VXLAN için kritik)
bridge fdb show dev vxlan100
bridge fdb add 02:00:00:00:00:01 dev vxlan100 dst 198.51.100.20

# Tünel istatistikleri
ip -s -s link show dev wg0

# Tüm tünelleri kaldır
ip link del vxlan100 2>/dev/null
ip tunnel del gre1   2>/dev/null

MTU, MSS ve Path MTU Discovery

Tünelleme her durumda paket boyutu problemi yaratır. Underlay paketinin standart 1500 byte MTU'su varken overlay encapsulation ek başlık ekler:

Tünel	Outer overhead	Overlay MTU (1500 underlay)
GRE (IPv4)	24 byte (4 GRE + 20 IP)	1476
IPIP	20 byte	1480
SIT (6in4)	20 byte	1480
WireGuard	60-80 byte	1420 (tipik)
VXLAN	50 byte	1450
Geneve (no TLV)	50 byte	1450
IPsec ESP (AES-GCM tunnel)	50-90 byte	~1410

PMTUD (Path MTU Discovery) sorunsalı: ICMP "Fragmentation Needed" mesajları yolda firewall'lar tarafından düşürüldüğünde PMTUD black hole oluşur. Paket gönderici büyük paketlerin neden başarısız olduğunu anlayamaz. Çözümler:

# TCP MSS clamping — paket içindeki TCP MSS değerini PMTU'ya zorla
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN     -j TCPMSS --clamp-mss-to-pmtu

# Ya da sabit değerle
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN     -j TCPMSS --set-mss 1380

# Tünel arayüzünde MTU sabit ayarı
ip link set wg0 mtu 1420
ip link set vxlan100 mtu 1450

Kernel offload etkileşimi: GSO (Generic Segmentation Offload), TSO (TCP Segmentation Offload), GRO (Generic Receive Offload) modern NIC'lerde paketleri NIC seviyesinde böler/birleştirir. Tünel arayüzlerinde bu offload'ların doğru çalışması için ethtool -K ile tünel-aware GSO/GRO açılmalı:

# Underlay NIC'te kontrol et
ethtool -k eth0 | grep -E 'tx-gre|tx-udp_tnl|tx-ipxip4|rx-gro'

# VXLAN segmentasyon offload (modern NIC'lerde donanım hızlandırma)
ethtool -K eth0 tx-udp_tnl-segmentation on
ethtool -K eth0 tx-udp_tnl-csum-segmentation on

Encryption + Tunnel Kombinasyonu

Tünelleme protokolü kendiliğinden güvenlik sağlamaz. Şifreleme gerektiğinde stack'lenir:

• GRE-over-IPsec: GRE multicast/routing protokollerini taşır + IPsec şifreleme. Klasik Cisco DMVPN deseni.
• VXLAN over IPsec: Veri merkezleri arası VXLAN trafiği IPsec ile şifrelenir. Bulut entegrasyonlarında yaygın.
• WireGuard: Şifreleme protokolün bizzat içinde — ek katman gerekmez.
• MACsec (IEEE 802.1AE): L2 segment şifrelemesi. Veri merkezi içi tüneller için L2 üzerinden donanım hızlandırmalı şifreleme.

# GRE üstüne IPsec — strongSwan + GRE
# 1. GRE tünelini ayağa kaldır (yukarıdaki örnek)
# 2. IPsec politikasını GRE trafiği için yaz:
#    leftsubnet=203.0.113.10/32, rightsubnet=198.51.100.20/32
#    proto=gre  (ESP IPsec ile GRE'yi sar)

Use Case Senaryoları

Veri Merkezi: VXLAN + EVPN Multi-Tenant

Bileşen	Rol
Spine/Leaf underlay	BGP-EVPN ile dağıtılmış MAC öğrenme
Leaf VTEP'ler	VXLAN encapsulation/decapsulation
MAC-VRF / IP-VRF	Tenant izolasyonu
Type 2 / Type 5 routes	MAC ve prefix advertisement

FRRouting ile Linux tabanlı leaf VTEP yapılandırması mümkündür; ticari NOS'larla (SONiC, Cumulus alternatifleri) yaygın kullanılır.

Şube — Merkez Site-to-Site

İki Buyukweb VDS arasında WireGuard ile site-to-site VPN:

# VDS-Bursa (203.0.113.10)
[Interface]
Address = 10.99.0.1/30
ListenPort = 51820
PrivateKey = <BURSA_PRIVKEY>
PostUp = iptables -t nat -A POSTROUTING -o eth0 -s 10.10.0.0/24 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -s 10.10.0.0/24 -j MASQUERADE

[Peer]
PublicKey = <ISTANBUL_PUBKEY>
AllowedIPs = 10.99.0.2/32, 10.20.0.0/24
Endpoint = 198.51.100.20:51820
PersistentKeepalive = 25

# VDS-İstanbul (198.51.100.20) — simetrik konfig
[Interface]
Address = 10.99.0.2/30
ListenPort = 51820
PrivateKey = <ISTANBUL_PRIVKEY>
PostUp = iptables -t nat -A POSTROUTING -o eth0 -s 10.20.0.0/24 -j MASQUERADE

[Peer]
PublicKey = <BURSA_PUBKEY>
AllowedIPs = 10.99.0.1/32, 10.10.0.0/24
Endpoint = 203.0.113.10:51820
PersistentKeepalive = 25

İki VDS'in iç ağları (10.10.0.0/24 ve 10.20.0.0/24) WireGuard tüneli üzerinden birbirine erişir. net.ipv4.ip_forward=1 ve UFW/iptables FORWARD politikalarının ACCEPT olması gerekir.

Kubernetes Pod Ağı

CNI eklentilerinin overlay seçenekleri:

• Calico IPIP: Düşük overhead, hızlı; sadece IPv4
• Calico VXLAN: IPIP'in bloklandığı bulut ortamlarında alternatif
• Cilium: eBPF tabanlı, VXLAN/Geneve destekli, kernel düzeyinde performans
• Flannel VXLAN: En basit kurulum, küçük cluster'lar için yeterli
• Antrea: Open vSwitch + Geneve, NSX uyumlu

# Calico operator install — VXLAN modu örneği
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    ipPools:
      - cidr: 10.244.0.0/16
        encapsulation: VXLAN
        natOutgoing: Enabled

Remote Access VPN

Son kullanıcılara kurumsal ağ erişimi için WireGuard veya OpenVPN. Mobil cihaz desteği, MFA entegrasyonu (RADIUS, OIDC), kullanıcı bazlı policy gibi gereksinimler ürün seçimini etkiler.

Buyukweb VPN paketleri: Son kullanıcı uçtan uca VPN ihtiyacı için /vpn-1-baglanti, /vpn-3-baglanti, /vpn-5-baglanti paketlerimiz. Site-to-site veya enterprise VPN için VDS'iniz üzerinde WireGuard/OpenVPN/strongSwan kurmak en esnek yöntemdir; /paket-karsilastirma sayfasında ihtiyacınıza uygun çözümü değerlendirebilirsiniz.

Bulut Sağlayıcı Tüneller

Bulut omurga ürünleri (Transit Gateway benzeri çözümler, hub-spoke VNet topolojileri) arka planda IPsec, GRE veya proprietary overlay protokolleri kullanır. Yapılandırma sağlayıcıya özgüdür ama temel kavramlar bu rehberle aynıdır.

Güvenlik Hususları

Şifresiz Tünelleri Hatırla

GRE, IPIP, SIT, VXLAN, Geneve şifreli değildir. Trafik açık metin akar; underlay üzerinde dinleyen biri inner paketleri okuyabilir. Güvenli bir kanala ihtiyacınız varsa:

• WireGuard (önerilen modern çözüm)
• IPsec ile sar (GRE/VXLAN-over-IPsec)
• MACsec (sadece L2 segment için)

Tünel Kötüye Kullanımı

Tünelleme ikili kullanımlı bir teknolojidir: meşru iletişim sağlamasının yanında veri sızdırma (data exfiltration) araçlarında da kullanılır. DNS over GRE, ICMP tunneling, HTTPS-over-WireGuard gibi gizli kanal teknikleri saldırganlar tarafından da kullanılır.

Savunma cephesi:

• Egress filtreleme: Çıkışta sadece bilinen protokol/port'lara izin ver. UDP 4789/6081/51820 gibi tünel portlarını gerekli olmadıkça blokla.
• NetFlow/sFlow analizi: Beklenmedik tünel trafiğini izle.
• TLS/IPsec deşifre noktaları kurumsal politikaya göre.

IDS/IPS Görünürlük Kısıtı

Şifreli tünel içinden geçen trafik IDS/IPS için kara kutudur. Suricata, Zeek gibi sensörler tünel açılma noktasına (decap noktası) yerleştirilmelidir. SSL/TLS inspection veya IPsec gateway sonrası decapsulated trafik üzerinde derin paket inceleme yapılır.

Sıkça Sorulan Sorular

GRE ile VXLAN arasındaki temel fark nedir?

GRE bir L3 tüneldir; iki IP noktası arasında genellikle yönlendirme protokollerini ve nokta-nokta trafiği taşır. VXLAN bir L2 overlay'idir; çoklu uçnoktalar arasında L2 segmentleri (Ethernet broadcast domain'leri) tek bir L3 underlay üzerinde taşır. GRE 4 byte ek başlık ile çalışır; VXLAN UDP 4789 üzerinden 8 byte VXLAN başlığı ekler ve 24-bit VNI ile milyonlarca segment destekler. GRE hub-spoke veya nokta-nokta için, VXLAN multi-tenant veri merkezi için tasarlanmıştır.

WireGuard mı OpenVPN mı tercih etmeliyim?

Yeni bir kurulum yapıyorsanız WireGuard. Daha basit konfigürasyon, daha düşük gecikme, kernel native çalışma, küçük ve denetlenebilir kod tabanı. OpenVPN'i şu durumlarda tercih edin: TCP fallback gerekiyorsa (sıkı firewall arkası), TLS özelleştirmesi (mTLS, CRL) lazımsa, veya mevcut OpenVPN ekosistemine entegrasyonunuz varsa. Performans açısından WireGuard belirgin üstün; modern dağıtımlarda kernel modülü 5.6+ sürümlerinde standarttır.

VXLAN ile MTU sorunu nasıl çözülür?

İki yöntem: (1) Underlay MTU'yu jumbo frame'e (1600+ veya 9000) çıkarın; overlay MTU 1500 kalır. (2) Overlay MTU'yu 1450'ye düşürün; tünel arayüzünde ip link set vxlanX mtu 1450 ve iptables MSS clamping uygulayın. Bulut sağlayıcısında jumbo frame her zaman mümkün değildir; ikinci seçenek daha güvenli. PMTUD black hole'ları önlemek için ICMP unreachable mesajlarına izin verin.

IPsec tunnel mode ile transport mode arasındaki fark?

Transport mode'da orijinal IP başlığı korunur; sadece payload şifrelenir. Host-to-host iletişimde kullanılır (örneğin sunucudan sunucuya direkt). Tunnel mode'da tüm orijinal IP paketi yeni bir IP başlığı içine sarılır ve şifrelenir; gateway-to-gateway site-to-site VPN bağlantılarında standarttır. Çoğu pratik VPN konfigürasyonu tunnel mode + ESP + IKEv2 kullanır.

Kubernetes için hangi overlay önerilir?

Kullandığınız bulut/altyapıya bağlı. Bare-metal cluster'larda Calico (IPIP veya VXLAN) ya da Cilium (eBPF) yaygın seçimdir. IPIP'in altyapı seviyesinde bloklandığı ortamlarda VXLAN modunu seçmek gerekir. Cilium büyük cluster'larda ve gözlemlenebilirlik gerektiren ortamlarda öne çıkar; eBPF ile kernel düzeyinde paket işleme yaparak performans avantajı sağlar. Flannel basit kurulum ve küçük cluster'lar için yeterlidir; ağ politikası gerektirmiyorsanız hızlı bir seçim olur.

---

İlgili Büyükweb Hizmetleri

• Tam Yetki VDS Sunucu — KVM root erişim, GRE/VXLAN/WireGuard çekirdek modüllerinin tamamı
• VPN 1 Bağlantı — son kullanıcı VPN ihtiyaçları için temel paket
• VPN 3 Bağlantı — küçük ekipler için çoklu bağlantı
• VPN 5 Bağlantı — daha geniş ekipler için
• Paket Karşılaştırma — VDS, hosting ve VPN paketlerini yan yana karşılaştırın

Tünelleme ve VPN yapılandırması ile ilgili sorularınız için 0850 302 60 70 numaralı destek hattımızı arayabilir, iletişim sayfamızdan yazabilirsiniz. Bursa Pendc Tier 3 veri merkezimizden barındırma hizmeti sunuyoruz.