Magic Transit

Magic Transit nedir?

Cloudflare’in çoğu güvenlik ürünü bir hostname’in önüne geçer: ornek.com için nameserver’ları Cloudflare’e yöneltirsin, HTTP istekleri kenarda sonlandırılır, temizlenir ve yeniden kurulup origin’e gönderilir. Bu model HTTP olmayan hiçbir şeyi kapsamaz.

Magic Transit farklı bir katmanda çalışır. Korunan şey bir site değil, IP adres bloğunun tamamı.

“Magic Transit is a network security and performance solution that offers Distributed Denial of Service (DDoS) protection, traffic acceleration, and more for on-premises, cloud-hosted, and hybrid networks.”

“Magic Transit delivers its connectivity, security, and performance benefits by serving as the front door to your IP network. This means it accepts IP packets destined for your network, processes them, and then outputs them to your origin infrastructure.”

Kendi /24’ünü Cloudflare BGP ile duyurur. İnternet’in tamamı o bloğa giden paketleri artık Cloudflare’e teslim eder. Cloudflare paketleri kenarda süzer ve geriye kalanı bir GRE veya IPsec tüneliyle sana indirir. Oyun sunucusu, VoIP, SSH, veritabanı portu, kendi VPN’in — hepsi aynı korumanın altına girer, çünkü koruma protokolü değil paketi görür.

Bunun bedeli var ve gizlenmemeli: Enterprise-only, self-serve değil.

“Magic Transit is not a self-serve product. Start by engaging with our team.”

Nasıl çalışır?

Trafik Cloudflare’e nasıl geliyor

BGP ile. Kendi prefix’ini duyurursun (BYOIP) veya Cloudflare’den IP kiralarsın.

Duyuruyu dört ayrı yöntemle kontrol edebilirsin: Addressing API, route reflector’larla BGP peering (141.101.67.22 CDG · 162.158.160.22 SIN · 173.245.63.66 IAD — “For maximum resiliency, we recommend peering with all three”), Network Flow ile trafik eşiğine bağlı otomatik tetikleme, veya Magic Transit sanal ağ routing tablosuyla BGP.

Trafik sana nasıl dönüyor

Cloudflare’in tünel uçları anycast’tir. GRE için bu doğal, çünkü GRE stateless. IPsec için Cloudflare özel bir şey yapıyor:

“one Cloudflare server handles the initial negotiation, then propagates the tunnel details (traffic selectors, keys, etc.) across all Cloudflare data centers. The result is that any Cloudflare server can handle traffic for that IPsec tunnel.”

Bunun bir yan etkisi var ve onboarding’de sık batırıyor: paketler farklı sunuculardan geldiği için anti-replay penceresi bozulur. Cloudflare bu ayarı varsayılan olarak kapatıyor ve kapatılması gereken cihazları adıyla sayıyor: Cisco Meraki, Velocloud, AWS VPN Gateway.

MSS clamp — onboarding’in en sık battığı adım

Kapsülleme paketi büyütür, MTU değişmez, aradaki fark büyük paketlerin sessizce düşmesi olarak geri gelir.

1500 bayt MTU
 − 20 bayt IPv4 başlığı
 −  4 bayt GRE başlığı
──────────────────────
1476 bayt tünel MTU
 − 40 bayt TCP/IP başlığı
──────────────────────
1436 bayt MSS

Failover — sayılarla

Tünel sağlığı üç durumlu: healthy, degraded, down.

Route silinmiyor, cezalandırılıyor:

“The values for failure penalties are intentionally extreme so that they always exceed the priority values assigned during routing configuration.” “Applying a penalty instead of removing the route altogether preserves redundancy.”

Ve en uç durumda:

“Cloudflare always attempts to send traffic over available tunnel routes with the highest priority… even when all configured tunnels are in an unhealthy state.”

Route önceliği

• Düşük değer kazanır.
• Değerler eşitse ECMP devreye girer (hash: kaynak+hedef IP, TCP/UDP’de portlar da).
• Longest-prefix match her şeyi yener: “A more specific static route (like /30) always takes precedence over a less specific one (like /29), regardless of tunnel priority.”
• Eşitlikte statik route BGP’yi yener.
• Route eşleşmezse: public adres İnternet’e çıkar, private adres (RFC 1918 / CGNAT) düşürülür.

DDoS katmanları ve çalışma sırası

“1. DDoS managed rulesets → 2. Advanced TCP Protection → 3. Advanced DNS Protection → 4. Cloudflare Network Firewall”

• Network-layer managed ruleset — “always enabled and cannot be turned off”. Yalnızca Magic Transit ve Spectrum Enterprise müşterileri hassasiyet ve aksiyonu değiştirebiliyor.
• Advanced TCP Protection (flowtrackd) — “a stateful TCP inspection engine used to detect and mitigate sophisticated out-of-state TCP attacks such as randomized and spoofed ACK floods or SYN and SYN-ACK floods.” Veri merkezleri arasında bağlantı takip edebiliyor.
• Advanced DNS Protection — “the protection system only analyzes DNS over UDP (it does not include DNS over TCP).”
• Programmable Flow Protection — UDP yükünü eBPF ile inceleyen, beta ve ayrı eklenti.

Advanced sistemler yeni müşterilerde otomatik olarak Monitor modunda açılıyor ve eşikleri yedi günlük trafiğin 95. persentilinden hesaplayıp her 10 dakikada yeniden hesaplıyor. Dürüst not, Cloudflare’in kendi cümlesi: “Customer visibility into the calculated thresholds is not available.”

Ne zaman kullanılır, ne zaman kullanılmaz

Uygun olduğu işler

• HTTP olmayan servisleri korumak: oyun sunucusu, VoIP/SIP, SSH, RDP, veritabanı portları, kendi VPN’in
• Kendi IP bloğunu koruyarak taşınmak — müşterilerin IP’yi biliyorsa değiştirmek istemezsin
• Bir veri merkezinin veya şube ağının tamamını tek kapıdan geçirmek
• Saldırı anında hızlı devreye alma: “Cloudflare can significantly accelerate this timeline during active-attack scenarios.”
• On-demand model: normalde kendi ISP’nden akan trafiği yalnızca saldırı sırasında Cloudflare’e çevirmek

Uygun olmadığı işler

• Tek bir web sitesi korumak. /24’ün, BGP’n ve Enterprise sözleşmen yoksa bu ürün senin için değil — WAF, DDoS for Web ve CDN zaten aynı korumayı HTTP katmanında ücretsiz veriyor.
• Çin. Tek cümlelik ve net: “Cloudflare’s China Network does not yet support Magic Transit.”
• Hızlı sonuç isteyen projeler. Pre-flight sonrası bile “Cloudflare applies configurations to the global network, which takes around one day to roll out.” CNI eklersen “typically takes two to four weeks”. Türkiye’de gerçekçi bir proje 4–8 hafta.
• Türkiye’de veri yerelleştirme gerekçesiyle. Regional Services’in Turkey bölgesi yalnızca HTTPS içindir; Magic Transit bu özelliği hiç kullanmaz (aşağıda ayrıntı).
• L7 koruma beklentisi. Magic Transit paket katmanında çalışır; HTTP isteğinin içindeki SQL injection’ı görmez. Onun için ayrıca WAF gerekir.
• Fragmentli trafiğe kural yazmak. Cloudflare parçaları birleştirip inceliyor, ama “you cannot create firewall rules for fragments.”

Somut örnekler

1. Oyun sunucusu — UDP flood altında

Bir oyun sunucusu UDP 7777’de çalışıyor. CDN/WAF bu trafiği hiç görmez. Magic Transit ile /24’ün duyurulur, UDP flood kenarda süzülür, temiz paketler GRE tünelinden iner.

Network Firewall’da minimal izinli protokol kümesi (dokümandaki örnek): {ESP, TCP, UDP, GRE, ICMP}. HOPOPT (protokol 0) bloklanması öneriliyor.

2. On-demand: normalde kendi ISP’n, saldırıda Cloudflare

Network Flow ile trafik eşiği izlenir, eşik aşılınca prefix duyurusu otomatik açılır:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes/$BGP_PREFIX_ID" \
  --request PATCH --json '{ "on_demand": { "advertised": true } }'

Gereken token izni: Magic Transit Write, IP Prefixes: Write veya IP Prefixes: BGP On Demand Write.

3. Bölgesel yönlendirme

Statik route’lar dokuz bölgeye kısıtlanabilir: AFR, APAC, EEUR, ENAM, ME, OC, SAM, WEUR, WNAM. Avrupa trafiğini Frankfurt veri merkezine, Amerika trafiğini Ashburn’e indirebilirsin.

4. Prefix’i güvenle geri çekmek

Yanlış yapılırsa blackhole üretiyor. Doğru sıra:

1. Aynı uzunlukta prefix’i kendi ISP’nden duyur (“Using identical prefix lengths from both Cloudflare and your ISP prevents path hunting.”)
2. 5–10 dakika bekle
3. Cloudflare’den geri çek
4. “Allow at least 15 minutes before considering the migration complete.”

Demo 1: Ubuntu’da anycast IPsec tünel ucu

Adım 1 — Health check hedefini ayarla

curl --request PUT \
  "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/magic/ipsec_tunnels/$TUNNEL_ID" \
  --header "Authorization: Bearer $CF_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{ "health_check": { "enabled": true, "target": "172.64.240.252",
                              "type": "request", "rate": "mid" } }'

Terminal — curl yanıtında success: true ve health_check bloğunda target: 172.64.240.252 ile type: request alanları okunacak şekilde

Adım 2 — strongSwan kurulumu

sudo apt-get install strongswan -y
strongswan --version
ip -br addr

Terminal — apt çıktısının son satırları, strongswan --version sonucu ve sunucunun public IP'sini gösteren ip -br addr çıktısı

Adım 3 — Anycast için kritik ayarlar

/etc/strongswan.conf:

charon {
    load_modular = yes
    install_routes = no
    install_virtual_ip = no
    plugins { include strongswan.d/charon/*.conf }
}
include strongswan.d/*.conf

/etc/ipsec.conf — bu dosyadaki üç satır demonun özü:

conn %default
    ikelifetime=24h
    rekey=yes
    reauth=no
    keyexchange=ikev2
    authby=secret
    dpdaction=restart
    closeaction=restart

conn cloudflare-ipsec
    auto=start
    type=tunnel
    fragmentation=no
    leftauth=psk
    left=%any
    leftid=<TUNNEL_ID>.<ACCOUNT_ID>.ipsec.cloudflare.com
    leftsubnet=0.0.0.0/0
    right=<CLOUDFLARE_ANYCAST_IP>
    rightid=<CLOUDFLARE_ANYCAST_IP>
    rightsubnet=0.0.0.0/0
    rightauth=psk
    ike=aes256-sha256-ecp384!
    esp=aes256-sha256-ecp384!
    replay_window=0
    mark_in=42
    mark_out=42
    leftupdown=/etc/strongswan.d/ipsec-vti.sh

• keyexchange=ikev2 — zorunlu, IKEv1 desteklenmiyor
• ecp384 — DH group 20, Cloudflare’in tek grup kullanmayı önerdiği grup
• replay_window=0 — anti-replay kapalı. Anycast’te paketler farklı Cloudflare sunucularından geleceği için açık bırakılırsa tünel sürekli flap eder

Terminal — cat /etc/ipsec.conf çıktısı, replay_window=0 ve keyexchange=ikev2 satırları görünür durumda (PSK ekranda olmasın)

Adım 4 — VTI arayüzü ve policy-based routing

/etc/strongswan.d/ipsec-vti.sh (chmod +x unutma):

#!/bin/bash
set -o nounset
set -o errexit
VTI_IF="vti0"
case "${PLUTO_VERB}" in
    up-client)
        ip tunnel add "${VTI_IF}" local "${PLUTO_ME}" remote "${PLUTO_PEER}" mode vti \
          key "${PLUTO_MARK_OUT%%/*}"
        ip link set "${VTI_IF}" up
        ip addr add 172.64.240.252/32 dev vti0
        sysctl -w "net.ipv4.conf.${VTI_IF}.disable_policy=1"
        sysctl -w "net.ipv4.conf.${VTI_IF}.rp_filter=0"
        sysctl -w "net.ipv4.conf.all.rp_filter=0"
        ip rule add from 172.64.240.252 lookup viatunicmp
        ip route add default dev vti0 table viatunicmp
        ;;
    down-client)
        ip tunnel del "${VTI_IF}"
        ip rule del from 172.64.240.252 lookup viatunicmp
        ip route del default dev vti0 table viatunicmp
        ;;
esac

/etc/iproute2/rt_tables sonuna 200 viatunicmp ekle.

PBR neden zorunlu, Cloudflare’in kendi gerekçesi: “Without it, the ICMP replies to the health probes sent by Cloudflare will be returned through the Internet, instead of the same IPsec tunnel.”

sudo ipsec start
sudo ipsec statusall | head -30
ip rule show
ip route show table viatunicmp
ip -s link show vti0

İki bölmeli terminal — solda ipsec statusall çıktısında ESTABLISHED satırı, sağda ip rule show / ip route show table viatunicmp / ip -s link show vti0 çıktıları

Adım 5 — Tünelin gerçekten paket taşıdığını gör

sudo tcpdump -ni any esp -c 20

Aynı anda başka bir bölmede Cloudflare tarafından gelen health check’leri izle:

sudo tcpdump -ni vti0 icmp -c 20

İki bölmeli terminal — solda dış arayüzde ESP paketleri, sağda vti0 üzerinde saniyede birden fazla ICMP health check paketi

Demo 2: MSS clamp’i atla, paketlerin nasıl kaybolduğunu gör

Bu demo tek bir soruyu cevaplıyor: “Küçük istekler çalışıyor, büyük dosya yüklemesi takılıyor” neye benziyor? Magic Transit onboarding’inin en sık battığı adım bu ve Cloudflare bunu “hard-to-debug connectivity issues” diye tarif ediyor.

Magic Transit hesabı gerekmiyor — aynı fiziği iki Ubuntu makinesi (veya bir makine + bir VM) arasında kuracağın GRE tüneliyle birebir üretebilirsin.

Adım 1 — İki uç arasında GRE tüneli kur

A sunucusunda (203.0.113.10):

sudo ip tunnel add gre1 mode gre local 203.0.113.10 remote 198.51.100.20 ttl 255
sudo ip link set gre1 up
sudo ip addr add 10.10.10.1/30 dev gre1
ip -d link show gre1

B sunucusunda (198.51.100.20):

sudo ip tunnel add gre1 mode gre local 198.51.100.20 remote 203.0.113.10 ttl 255
sudo ip link set gre1 up
sudo ip addr add 10.10.10.2/30 dev gre1
ping -c 3 10.10.10.1

Terminal — ip -d link show gre1 çıktısında mtu 1476 değeri ve karşı uca atılan üç başarılı ping

Adım 2 — Küçük paketin çalıştığını, büyüğün düştüğünü kanıtla

ping ile parçalanmayı yasaklayıp (-M do) paket boyutunu artır:

ping -M do -s 1400 -c 2 10.10.10.2     # geçer
ping -M do -s 1448 -c 2 10.10.10.2     # tam sınır: 1448 + 28 = 1476
ping -M do -s 1472 -c 2 10.10.10.2     # düşer — "Frag needed and DF set"

Terminal — üç ping komutunun çıktısı üst üste; sonuncusunda 'Frag needed and DF set (mtu = 1476)' satırı okunacak şekilde

Adım 3 — TCP’de aynı arıza, ama sessiz

ICMP hatayı söylüyor. TCP’de ise bağlantı kurulur, küçük istekler döner, büyük gövde asılı kalır. Gerçek arızanın kılığı bu.

B sunucusunda büyük bir dosya sun:

head -c 5M /dev/urandom > /tmp/buyuk.bin
cd /tmp && python3 -m http.server 8099

A sunucusundan iste:

curl -s -o /dev/null -w 'kucuk: %{http_code} %{time_total}s\n' http://10.10.10.2:8099/
curl -s -o /dev/null -w 'buyuk: %{http_code} %{time_total}s\n' --max-time 20 \
  http://10.10.10.2:8099/buyuk.bin

Aynı anda paketleri izle:

sudo tcpdump -ni gre1 'tcp port 8099' -c 40

İki bölmeli terminal — solda küçük isteğin 200 dönmesi ve büyük dosyanın Operation timed out ile düşmesi, sağda tcpdump çıktısında aynı sekans numarasının tekrar tekrar gönderildiği retransmission satırları

Adım 4 — MSS clamp’i uygula ve düzelt

# Her iki sunucuda da
sudo iptables -t mangle -A FORWARD -o gre1 -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1436
sudo iptables -t mangle -A OUTPUT -o gre1 -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --set-mss 1436
sudo iptables -t mangle -L -n -v

Aynı testi tekrarla:

curl -s -o /dev/null -w 'buyuk: %{http_code} %{time_total}s\n' --max-time 20 \
  http://10.10.10.2:8099/buyuk.bin

Terminal — iptables mangle tablosunda TCPMSS kuralı ve altında büyük dosya isteğinin bu kez 200 ile tamamlanması; süre ve boyut görünsün

Adım 5 — SYN paketindeki MSS değerini gözle doğrula

sudo tcpdump -ni gre1 'tcp[tcpflags] & tcp-syn != 0' -vv -c 4

Çıktıda options [mss 1436,...] görürsün. Clamp’ten önce burada 1460 yazıyordu.

Terminal — tcpdump -vv çıktısında SYN paketinin options bloğunda mss 1436 değeri okunacak şekilde

Ölçüm tablosu

Fiyatlandırma

Magic Transit için yayımlanmış hiçbir sayısal fiyat yok. 1 Eylül 2026’da doğrulandı.

Bulunabilen tek resmî fiyat ifadesi, plan karşılaştırma tablosundaki satır:

Kaynak: cloudflare.com/plans · Erişim: 1 Eylül 2026

Ürün sayfasındaki tek eylem çağrısı “Talk to an expert”. Dokümantasyon tarafında da fiyat yok, yalnızca kapı: “Enterprise-only” ve “not a self-serve product”.

Faturalama hakkında dokümante edilen tek mekanik kural prefix sayımıdır:

“Cloudflare measures the Magic Transit prefix count based on the number of BGP prefixes you define. Each prefix is billed separately, even if they overlap.” “There is no billing limit on the accepted prefix sizes.”

Saldırı trafiği faturaya girmiyor:

“Cloudflare’s billing systems automatically exclude DDoS attack traffic from your usage.”

Lisanslama ve hukuki çerçeve

Magic Transit tescilli bir hizmettir; açık kaynak bileşeni yoktur ve Cloudflare Hizmet Şartlarına tabidir. Kullanımı bir Enterprise sözleşmesi gerektirir.

BGP ve LOA sorumluluğu sende. Cloudflare senin adına prefix duyurabilmek için transit sağlayıcılarına bir yetki belgesi sunuyor:

“Draft a Letter of Agency (LOA) that identifies the prefixes you want to advertise and authorizes Cloudflare to announce them. Our transit providers require the LOA so they can accept the routes we advertise on your behalf.” “If you are an Internet service provider (ISP) and advertising prefixes on behalf of a customer, you need an LOA for the ISP and for the customer.”

Veri yerelleştirme — Türkiye için kritik ayrım. Cloudflare’in Data Localization dokümanı bir Turkey bölgesi listeliyor:

“Turkey — Cloudflare will only use data centers that are physically located within Turkey to decrypt and service HTTPS traffic.”

Ama aynı belgenin Network Services matrisi şunu diyor:

Efsanede ⚫️ şu demek: “Not applicable — this product does not interact with this DLS feature.”

Bölge ataması belgelenmemiş. Magic Transit’in dokuz bölge kodu arasında Türkiye ayrı bir bölge değil; İstanbul trafiğinin EEUR mi ME mi altına düştüğü Cloudflare tarafından yayımlanmıyor. Ölçerek doğrulanabilir: https://cloudflare.com/cdn-cgi/trace çıktısındaki colo alanı, sonra Network Analytics’te Source data center kırılımı.

Sık yapılan hatalar

MSS clamp’i unutmak veya yanlış yere koymak

En pahalı hata. Belirti: küçük istekler çalışır, büyük POST ve TLS handshake takılır. Yön kuralını hatırla — clamp uygulandığı yönün tersindeki paketleri etkiliyor. Tünel içinde tünel varsa clamp hiç işe yaramaz, iç arayüzün MTU’sunu düşürmek gerekir.

ICMP’yi bloklamak

Health check’ler ICMP taşıyor. Network Firewall’da ICMP’yi topluca bloklarsan tünellerin ölür. Doğru sıra: önce Allow · ICMP · Source: Cloudflare IP ranges, sonra block kuralı.

Stateful firewall’ın ICMP Reply’ları düşürmesi

Panel “down” diyor, trafik akıyor, hata oranı %100. Sebep: Palo Alto, Check Point, Cisco ve Fortinet gibi cihazlar eşleşen bir ICMP Request bulamayınca yanıtı “out-of-state” sayıp düşürüyor. Çözüm tek satır: health check tipini Request’e al.

Anti-replay’i açık bırakmak

Anycast IPsec’te paketler farklı Cloudflare sunucularından geliyor; replay penceresi bozulunca tünel sürekli flap eder. Cisco Meraki, Velocloud ve AWS VPN Gateway’de elle kapatmak gerekiyor. DPD aksiyonu da restart olmalı: “This ‘restart’ option ensures that the connection can recover in the event that a Cloudflare server goes offline.”

Yönetim erişimini kilitleyen kural sırası

Kurallar ilk eşleşende duruyor. 10. sıradaki bir catch-all Block varsa, yeni izin kuralı 10’dan önce eklenmeli. Ve değişiklikler hızlı yayılıyor — “Fast propagation of rule changes in less than a minute” — yani hatan da bir dakikada global oluyor.

PBR yerine default route kullanmak

Egress modunda tünel hedefi anycast IP’lerine giden route’lar underlay transit yolundan geçmeli. Aksi hâlde tünel kendi içine yönlenir. Ayrıca: “Cloudflare only accepts egress traffic from authorized prefixes.”

RPKI/ROA’nın onboarding ile uyuşmaması

“When using Route Origin Authorizations (ROAs)… the prefix and originating ASN must match the onboarding submission.” Cloudflare kendi ASN’ini (AS13335) prepend ettiği için ROA’nın origin ASN ile tutarlı olması gerekiyor. Kontrol: rpki.cloudflare.com

“Network Firewall’da allow yazdım ama trafik hâlâ düşüyor”

Dört mitigasyon katmanı var ve Network Firewall sonuncusu. DDoS managed ruleset veya Advanced TCP Protection paketi ondan önce düşürmüş olabilir. Teşhis: Network Analytics → Action = Drop → Mitigation system kırılımı. Her katmanın kendi bypass mekanizması var.

Azure link-local tuzağı

“If the tunnel is to an Azure VPN gateway, the tunnel interface address must not be in the link-local range. Azure will not initiate BGP sessions to peers using link-local addresses. Use an RFC 1918 address.”