BGP Tünel Nedir? GRE ile DDoS Korumalı IP Anonsu Rehberi

BGP tünel, kendi ASN'inizle anons ettiğiniz IP bloğunun trafiğini, bir koruma ağı üzerinden GRE tüneli içinde taşıdığınız bir yöntemdir. BGP oturumu tünelin içinde kurulur. IP bloğunuz koruma ağından anons edilir, saldırı trafiği orada ayıklanır ve temiz trafik GRE ile size iletilir. Bu yazıda mantığı, Linux, MikroTik ve Juniper için örnek yapılandırmaları ve en çok sorun çıkaran konuyu (MTU/MSS) adım adım anlatıyoruz.

Yazıdaki IP ve ASN'ler dokümantasyon aralıklarındandır: müşteri ASN'i AS64496, prefix 192.0.2.0/24 ve 2001:db8:1234::/48, müşteri tünel ucu 203.0.113.10, karşı uç 198.51.100.1. Gerçek değerleri kendi ortamınıza göre değiştirin.

BGP tünel nasıl çalışır?

Klasik BGP'de upstream'inizle fiziksel veya L2 bir bağlantı üzerinden oturum kurarsınız. Trafiğiniz doğrudan size gelir. Saldırı hattınızı doldurursa filtreleme için çok geç kalınmış olur.

BGP tünelde akış şöyledir:

1. IP bloğunuz için ROA ve IRR kayıtları, ASN'inizi origin olarak gösterir.
2. İnternete bloğunuzu koruma sağlayan ağ anons eder (ör. NixGuard Edge kullanımında AS40368).
3. Saldırı trafiği o ağda filtrelenir.
4. Temiz trafik, sizinle koruma ağı arasındaki GRE tüneline girer.
5. BGP oturumu bu tünelin iç IP'leri arasında kurulur; blok oturum üzerinden anons edilir ve koruma ağı bu bloğu size yönlendirir.

Avantajı, kendi veri merkezinizde, kolokasyonda ya da başka bir sağlayıcıdaki sunucuda olsanız bile korumadan yararlanabilmenizdir. Tünel üzerinden çalıştığı için fiziksel çapraz bağlantı gerekmez. Şart, kendi ASN'iniz ve IP bloğunuzun olması ve tünel ucunuzun internetten erişilebilir bir genel IP'ye sahip olmasıdır.

Başlamadan önce kontrol listesi

• ASN ve prefix kaydı: Blok, RIR kayıtlarında sizin adınıza görünmeli.
• RPKI ROA: 192.0.2.0/24 için origin AS64496 olan bir ROA oluşturun. maxLength, anons edeceğiniz uzunlukla uyumlu olmalı.
• IRR route/route6 nesnesi ve gerekiyorsa AS-SET kaydı.
• Genel IP'li bir tünel ucu: Linux sunucu, MikroTik veya Juniper. NAT arkasındaki uçlarda GRE sorun çıkarır.
• GRE (IP protokol 47) izni: Uç noktadaki güvenlik duvarında karşı uçtan gelen GRE'ye izin verin.

Linux: GRE tüneli ve BIRD 2

Tüneli oluşturun:

ip link add gre-nix type gre local 203.0.113.10 remote 198.51.100.1 ttl 255
ip addr add 169.254.10.2/30 dev gre-nix
ip link set gre-nix mtu 1476 up

# korunacak servis IP'si (blok içinden)
ip addr add 192.0.2.10/32 dev lo

sysctl -w net.ipv4.conf.all.rp_filter=2
sysctl -w net.ipv4.conf.gre-nix.rp_filter=2

Güvenlik duvarında GRE ve BGP'ye izin verin:

iptables -A INPUT -p gre -s 198.51.100.1 -j ACCEPT
iptables -A INPUT -i gre-nix -p tcp --dport 179 -j ACCEPT

BIRD 2 yapılandırması (/etc/bird/bird.conf):

router id 203.0.113.10;

protocol device {}

protocol static announce4 {
    ipv4;
    route 192.0.2.0/24 blackhole;
}

filter nix_out_v4 {
    if net = 192.0.2.0/24 then accept;
    reject;
}

filter nix_in_v4 {
    if net = 0.0.0.0/0 then accept;
    reject;
}

protocol kernel {
    ipv4 { import filter nix_in_v4; export none; };
}

protocol bgp nixcon4 {
    local 169.254.10.2 as 64496;
    neighbor 169.254.10.1 as 40368;
    ipv4 {
        import filter nix_in_v4;
        export filter nix_out_v4;
    };
}

Oturum doğrudan bağlı iç IP'ler arasında olduğundan multihop gerekmez. Statik blackhole rotası, BIRD'ün bloğu anons edebilmesi için tabloda bir rota bulundurur. Gerçek trafik, lo üzerindeki /32 gibi daha spesifik yerel adreslerle karşılanır.

Çıkış trafiğinin de tünelden gitmesini istiyorsanız kaynak tabanlı yönlendirme kullanın:

ip rule add from 192.0.2.0/24 table 100
ip route add default via 169.254.10.1 dev gre-nix table 100

Kontrol:

birdc show protocols nixcon4
birdc show route export nixcon4
ip -s tunnel show gre-nix

MikroTik (RouterOS v7)

/interface gre add name=gre-nix local-address=203.0.113.10 remote-address=198.51.100.1 mtu=1476 keepalive=10s,10
/ip address add address=169.254.10.2/30 interface=gre-nix

/ip route add dst-address=192.0.2.0/24 blackhole
/ip firewall address-list add list=my-prefixes address=192.0.2.0/24

/routing filter rule add chain=nix-out rule="if (dst == 192.0.2.0/24) { accept }"
/routing filter rule add chain=nix-out rule="reject"
/routing filter rule add chain=nix-in rule="if (dst == 0.0.0.0/0) { accept }"
/routing filter rule add chain=nix-in rule="reject"

/routing bgp connection add name=nixcon as=64496 router-id=203.0.113.10 \
    local.address=169.254.10.2 local.role=ebgp \
    remote.address=169.254.10.1 remote.as=40368 \
    output.network=my-prefixes output.filter-chain=nix-out input.filter=nix-in

/ip firewall filter add chain=input protocol=gre src-address=198.51.100.1 action=accept place-before=0
/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn out-interface=gre-nix action=change-mss new-mss=1436 passthrough=yes
/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn in-interface=gre-nix action=change-mss new-mss=1436 passthrough=yes

Juniper (Junos)

GRE için MX serilerinde tünel servisleri (gr- arayüzü) etkin olmalıdır. Örneğin: set chassis fpc 0 pic 0 tunnel-services bandwidth 10g.

set interfaces gr-0/0/10 unit 0 tunnel source 203.0.113.10
set interfaces gr-0/0/10 unit 0 tunnel destination 198.51.100.1
set interfaces gr-0/0/10 unit 0 family inet mtu 1476
set interfaces gr-0/0/10 unit 0 family inet address 169.254.10.2/30

set routing-options autonomous-system 64496
set routing-options router-id 203.0.113.10
set routing-options static route 192.0.2.0/24 discard

set policy-options policy-statement NIX-EXPORT term 1 from route-filter 192.0.2.0/24 exact
set policy-options policy-statement NIX-EXPORT term 1 then accept
set policy-options policy-statement NIX-EXPORT term 2 then reject
set policy-options policy-statement NIX-IMPORT term 1 from route-filter 0.0.0.0/0 exact
set policy-options policy-statement NIX-IMPORT term 1 then accept
set policy-options policy-statement NIX-IMPORT term 2 then reject

set protocols bgp group NIXCON type external
set protocols bgp group NIXCON peer-as 40368
set protocols bgp group NIXCON local-address 169.254.10.2
set protocols bgp group NIXCON neighbor 169.254.10.1 import NIX-IMPORT
set protocols bgp group NIXCON neighbor 169.254.10.1 export NIX-EXPORT

SRX'te TCP MSS'i set security flow tcp-mss gre-in mss 1436 ve set security flow tcp-mss gre-out mss 1436 ile ayarlayın. Interface seviyesinde tcp-mss desteği platforma göre değişir; kendi platformunuzun belgesine bakın.

MTU ve MSS: neden bu kadar önemli?

GRE, her pakete ek başlık ekler. IPv4 üzerinde GRE için bu 24 bayttır (20 bayt dış IP + 4 bayt GRE). Alt ağ MTU'su 1500 ise:

GRE anahtarı (key) kullanırsanız 4 bayt daha eklenir. Alt ağ MTU'su 1500'den küçükse (ör. PPPoE) değerleri buna göre düşürün.

Belirti tipiktir: BGP oturumu kurulur, ping çalışır, küçük sayfalar açılır, ama büyük dosya indirmeleri veya TLS el sıkışmaları takılır. Sebep, DF biti set edilmiş büyük paketlerin tünelde düşmesi ve ICMP "fragmentation needed" mesajlarının filtrelenmesidir (PMTUD black hole).

MTU doğrulaması için DF bitiyle test edin. 1476 MTU için en büyük ICMP veri boyutu 1476 − 28 = 1448 bayttır:

ping -M do -s 1448 169.254.10.1   # geçmeli
ping -M do -s 1449 169.254.10.1   # geçmemeli

Linux'ta yönlendirme yapan bir sunucuda MSS'i sıkıştırın:

iptables -t mangle -A FORWARD -o gre-nix -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1436
iptables -t mangle -A FORWARD -i gre-nix -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1436

Servis sunucunun kendisinde çalışıyorsa SYN-ACK'in MSS'i, o bağlantı için kullanılan rotanın MTU'suna göre belirlenir. Dönüş yolu tünele gitmiyorsa 1460 duyurulabilir. Bu yüzden kaynak tabanlı yönlendirmeyi doğru kurun veya OUTPUT zincirine de benzer bir MSS kuralı ekleyin. Ayrıca güvenlik duvarında ICMP tip 3 kod 4 (IPv4) ve ICMPv6 "Packet Too Big" mesajlarını engellemeyin.

Sık yapılan hatalar ve çözümleri

• Oturum Idle/Active'te kalıyor: Önce GRE'nin karşılıklı geçtiğini doğrulayın (tcpdump -ni eth0 proto 47). Protokol 47 engelleniyor, tünel uç IP'leri yanlış veya uç NAT arkasında olabilir.
• Oturum Established ama trafik gelmiyor: rp_filter katı moddadır (1), IP forwarding kapalıdır veya servis IP'si sunucuda tanımlı değildir.
• Prefix anons edilmiyor: Tabloda eşleşen rota yoktur. Statik blackhole veya discard rotasını ve export filtresini kontrol edin.
• Prefix dışarıdan görünmüyor: ROA'daki origin AS veya maxLength yanlıştır, IRR nesnesi eksiktir ya da blok doğrulanmamıştır. RPKI-invalid bir rota birçok ağda reddedilir.
• Tünel ucuna tünel içinden rota öğrenilmiş: Tünel hedef IP'si, tünelin kendisinden öğrenilen bir rota üzerinden gidiyorsa tünel kendi içine düşer ve döngü oluşur. Karşı uç adresi için her zaman statik, dış arayüzden giden bir rota tutun.
• Çıkış trafiği düşüyor: Kaynak IP'si korunan bloktan olan paketleri farklı bir upstream'e gönderirseniz, o upstream uRPF/kaynak filtresi uygulayabilir. Çıkışı tünelden verin veya bunu önceden planlayın.
• Büyük paketlerde takılma: Yukarıdaki MTU/MSS bölümüne bakın.

Doğrulama

1. birdc show protocols (veya /routing bgp session print, show bgp summary) ile oturum Established olmalı.
2. Anons edilen rotayı export çıktısında görün.
3. Nixcon looking glass'ından (lg.nixcon.com.tr) İzmir, Frankfurt ve ABD noktalarında BGP rota, ping ve traceroute sorgusu yapın. Bloğunuzun doğru origin ASN ile göründüğünü kontrol edin.
4. Dışarıdan mtr ile servis IP'nize bakın ve büyük bir dosya indirerek MTU sorununu eler.
5. Akış verisiyle gelen trafiği izlemek istiyorsanız flow tabanlı izleme, saldırı tespitini ve doğru zamanda karşı adım atmayı kolaylaştırır.

Kendi router'ınız yoksa

Tünel ucunu çalıştıracak bir router ya da sunucunuz yoksa, ASN'inizi ve bloğunuzu doğrudan sanal sunucudaki BGP oturumundan anons edebilirsiniz. Bunun için BGP destekli VDS sunucular uygun bir başlangıçtır. DDoS korumasız ya da korumalı anons seçenekleri vardır ve kurulum otomatik yapılır.