BGP Prefix ve AS_PATH Filtreleri Nasıl Planlanır?

Sesli Dinle — Makale

BGP prefix filtreleri IP adres bloklarını, AS_PATH filtreleri ise duyurunun geçtiğini bildirdiği ASN’lerin sırasını denetler. Bu yerel politika kuralları, bir komşudan hangi rotaların kabul edileceğini ve o komşuya hangilerinin duyurulacağını sınırlar. Planın temeli, her komşuluk için beklenen rota kapsamını önceden tanımlamak ve bu kapsam dışında kalan duyuruları reddetmektir.

Gelen politika, komşudan öğrenilen rotalardan hangilerinin BGP karar sürecine katılabileceğini belirler. Giden politika ise yerel yönlendiricinin hangi rotaları komşuya aktarabileceğini seçer. Bu iki yön ayrı ele alınmadığında yanlış bir varsayılan rota kabul edilebilir, yetkisiz bir prefix dışarı duyurulabilir veya ağ istemeden iki dış ağ arasında trafik taşıyan bir transit ağ haline gelebilir.

Buradaki filtreler, paketleri inceleyen güvenlik duvarı ACL’leri (Access Control List) değildir. Üreticiden bağımsız bir politika, prefix, prefix uzunluğu ve AS_PATH gibi BGP rota öznitelikleri üzerinden tanımlanır. Ürün komutları, onaylanan mantığın ilgili platformdaki karşılığıdır.

Prefix ve AS_PATH Filtreleri Hangi Bilgiyi Denetler?

Bir BGP rota filtreleme politikası tek bir kontrol türüne dayanmaz. Prefix filtresi hangi adres bloğunun ve hangi prefix uzunluğunun kabul edilebilir olduğunu, AS_PATH filtresi ise AS_PATH içinde görülen otonom sistem sırasının yerel beklentilerle uyuşup uyuşmadığını değerlendirir. Maksimum prefix sınırı ve RPKI doğrulaması da farklı riskleri kapsayan tamamlayıcı kontrollerdir.

Aşağıdaki karşılaştırma, bu katmanların aynı politika içinde hangi görevi üstlendiğini gösterir.

Politika sırası uygulamaya göre değişebilse de karar mantığı açık olmalıdır: rota önce kapsam, komşu ilişkisi ve doğrulama koşullarından geçer; bütün zorunlu koşullar sağlanmadan kabul veya duyuru izni verilmez. Ürünün kural işleme sırası, varsayılan davranışı ve birden fazla eşleşmeyi nasıl birleştirdiği uygulama öncesinde ayrıca doğrulanmalıdır.

Gelen ve Giden Rota Politikaları Arasındaki Ayrım

Inbound (gelen) ve outbound (giden) filtreler aynı veri kaynaklarından yararlanabilir, ancak farklı sonuçlar üretir. Bir prefixin komşudan alınmasına izin vermek, aynı prefixin başka bir komşuya aktarılmasına otomatik olarak izin verildiği anlamına gelmez.

Gelen Rota Politikası

Gelen politika, komşudan beklenen rota kapsamını tanımlayarak başlar. Müşteriden yalnız müşteriye ve varsa onun alt müşterilerine ait yetkilendirilmiş IP prefixleri; internet servis sağlayıcısından sözleşmeye göre varsayılan, kısmi veya tam tablo; doğrudan trafik değişimi yapılan eş ağdan ise o ağa ve müşterilerine ait beklenen rotalar kabul edilir.

Prefix kuralları yalnız ağ adresini değil, kabul edilebilecek daha özel duyuruların sınırını da belirtmelidir. Yerel AS'ye ait prefixlerin yanlış komşudan geri gelmesi, küresel yönlendirmeye uygun olmayan özel amaçlı aralıklar, ağların birbirine bağlandığı IXP’lerin (Internet Exchange Point) ortak yerel ağına ait beklenmeyen prefixler ve talep edilmemiş varsayılan rota ayrı reddet koşulları olarak ele alınabilir. Bu veri kümeleri değişebildiği için güncel kaynak, yenileme sıklığı ve otomasyon arızasındaki davranış da planın parçasıdır.

AS_PATH tarafında müşterinin doğrudan komşu ASN'si, yetkilendirilmiş alt müşteri ASN'leri ve beklenen yol uzunluğu incelenebilir. Yerel ASN'nin yolda bulunması, müşteriden bir internet servis sağlayıcısı veya eş ağ ASN'sinin gelmesi ya da tanımsız özel ASN kullanımı şüpheli kabul edilebilir. IXP üyeleri arasında BGP yollarını dağıtan route server, genellikle kullanıcı paketlerini kendi üzerinden taşımaz. Şeffaf AS_PATH kullanan route server bağlantısında ilk ASN, route server’a değil duyuruyu ileten üyeye ait olabilir. Trafiğin gönderileceği yönlendiriciyi belirten NEXT_HOP adresi de ilgili üyeyi gösterir. Bu nedenle ilk ASN ve NEXT_HOP kontrolleri bu modele göre planlanmalıdır.

Giden Rota Politikası

Giden politika için en güvenli başlangıç, her komşuya duyurulabilecek prefixlerin açık listesidir. Bir uç ağ normalde yalnız kendi yerel prefixlerini dışarı aktarır. Transit hizmeti veren bir ağ, eş ağlara ve internet servis sağlayıcılarına normalde kendi prefixleri ile yetkili müşterilerinden öğrendiği yolları duyurur. Müşterilere giden duyurularda ise sözleşmeye göre varsayılan rota, seçilmiş yollar veya diğer ağlardan öğrenilmiş yolları da içeren tam tablo sunabilir. Eş ağdan veya internet servis sağlayıcısından öğrenilen rotaların başka bir eşe ya da internet servis sağlayıcısına gönderilmesi, planlanmamış transit ve rota sızıntısı oluşturabilir.

AS_PATH koşulları, komşuya duyurulması düşünülen rotanın hangi ilişkiden öğrenildiğini ayırmaya yardımcı olabilir. Örneğin bir ağ transit hizmeti sunmuyorsa, yerel olarak üretilmeyen ve yetkili müşterilerden öğrenilmeyen rotalar giden politikada reddedilebilir. Ancak rota seçimi, yerel üretim biçimi, birden fazla prefixi tek üst prefixte özetleme ve ASN ekleme aşaması ürünlere göre farklı görünebildiğinden koşul, komut sözdizimi yerine beklenen mantık ve örnek rotalar üzerinden tanımlanmalıdır.

Varsayılan rota yalnız belirli müşteri veya yedeklilik tasarımında gerekliyse duyurulmalıdır. Genel bir izin kuralının içinde 0.0.0.0/0 veya ::/0'ın istemeden eşleşmesi engellenmeli, varsayılan rota kararı ayrı bir politika maddesi olarak tutulmalıdır.

Prefix Listesini Yetki Kayıtlarından Oluşturma

Prefix listesi, elle yazılmış dağınık satırlar yerine izlenebilir bir yetki envanterinden üretilmelidir. Kaynağın güncelliği, kimin onay verdiği ve değişikliğin hangi komşuları etkilediği bilinmeden otomasyon kullanmak, eski veya eksik veriyi hızla yayabilir.

1. Yetki envanterini oluşturun: Yerel IPAM (IP Address Management) kayıtlarını, tahsis belgelerini, müşteri yetkilendirmelerini, prefix ile köken ASN bilgisini tutan IRR veritabanı kayıtlarını ve RPKI ROA durumunu aynı kayıt üzerinde ilişkilendirin.
2. Prefixleri normalleştirin: IPv4 ve IPv6'yı ayırın, çakışan veya kapsanan kayıtları belirleyin ve her prefix için köken ASN ile komşuluk rolünü kaydedin.
3. Uzunluk politikasını tanımlayın: Yalnız tam eşleşme mi, belirli bir sınıra kadar daha özel duyurular mı kabul edileceğini prefix bazında belirtin. Daha özel duyurular için çok geniş bir izin vermek, listenin yetkilendirilmemiş alt blokları da kapsamasına neden olabilir.
4. Özel durumları ayırın: Varsayılan rota, belirli hedeflere gelen trafiği bilerek düşüren blackhole hizmetine ait duyurular, geçici taşıma düzenleri ve bakım duyuruları normal izin listesinin içine gizlenmemelidir.
5. Politika sürümlerini kaydedin: Kaynak veri, oluşturulan politika, onaylayan kişi ve yürürlüğe giriş zamanı birlikte kaydedilmelidir. Aynı girdinin aynı çıktıyı üretmesini ve önceki sürümün yeniden uygulanabilmesini sağlayın.
6. Veri kaynağı güncellenemezse izlenecek yolu belirleyin: Eski doğrulanmış listenin korunması, değişikliğin durdurulması veya politikanın varsayılan reddetme davranışını koruması gibi seçeneklerden birini önceden belirleyin.

IRR veya başka bir kayıt kaynağı tek başına kusursuz kabul edilmemelidir; kayıtlar eksik, eski veya hatalı olabilir. Otomatik üretilen prefix listeleri, sahiplik ve RPKI verisiyle karşılaştırılmalı, beklenen değişiklik farkı sorumlu ekip tarafından incelenmeden topluca etkinleştirilmemelidir.

AS_PATH Filtrelerinde Komşu Rolü ve Yol Uzunluğu

AS_PATH filtresi planlanırken önce düzenli ifade değil, kabul edilmesi gereken ilişki tanımlanır. Üreticiye özgü sözdizimi ancak bu mantık onaylandıktan sonra hazırlanmalıdır.

• Doğrudan komşudan beklenen ilk AS ve route server gibi istisnalar yazılı hale getirilir.
• Müşterinin kendi ASN'si ile yetkilendirilmiş alt müşteri ASN'lerinin kabul edilebilir konumları belirlenir.
• Yerel ASN'nin AS_PATH içinde bulunması reddedilir; bu temel döngü korumasını gevşeten istisnalar ayrıca risk değerlendirmesi gerektirir.
• Özel ASN'lerin hangi özel anlaşmalarda kabul edileceği ve kamuya açık komşuluklara çıkmadan önce nasıl ele alınacağı tanımlanır.
• Beklenmeyen internet servis sağlayıcısı ASN'leri veya eş ağ ASN'leri müşteri yolunda görülüyorsa olası rota sızıntısı göstergesi olarak değerlendirilir.
• Yol uzunluğu sınırı, yalnız komşu tipine göre makul bir koruma olarak kullanılır; aynı ASN’yi AS_PATH içinde tekrarlayarak yol tercihini etkilemeyi amaçlayan AS prepending ve müşterinin transit rolü hesaba katılır.
• ASN değişimi, birleşme, yeni alt müşteri bağlantısı ve route server geçişi gibi olayların filtre güncellemesini nasıl tetikleyeceği belirlenir.

AS_PATH tam yol doğrulaması değildir. Bir BGP duyurusundaki yol bilgisi yerel politika için değerlidir, ancak tek başına prefix kökeninin yetkili olduğunu veya yolun bütün geçişlerinin kriptografik olarak doğrulandığını göstermez. Bu nedenle prefix yetkisi, RPKI köken durumu ve komşu ilişkisinden gelen işletim bilgileri birlikte değerlendirilmelidir.

Varsayılan Rota, Maksimum Prefix ve RPKI Kontrolleri

Varsayılan rota kararı, maksimum prefix sınırı ve RPKI doğrulaması, prefix ve AS_PATH filtrelerini tamamlar. Bu kontroller izin listesinin yerini tutmaz; beklenmeyen durumun etkisini azaltmak veya ek doğrulama sağlamak için kullanılır.

Varsayılan Rota Kararı

IPv4 için 0.0.0.0/0, IPv6 için ::/0 yalnız açık bir hizmet veya yedeklilik ihtiyacı varsa kabul edilmeli ya da duyurulmalıdır. Tam tablo alan bir komşulukta varsayılan rotanın da istenip istenmediği ayrıca yazılmalı; geniş bir prefix eşleşmesine güvenilmemelidir.

Maksimum Prefix Sınırı

Önce sayacın komşudan alınan bütün prefixleri mi, yoksa gelen politikadan geçip kabul edilenleri mi saydığı doğrulanır; bu davranış ürün ve ayara göre değişir. Maksimum prefix değeri, bu sayacın normal düzeyi, beklenen büyüme payı ve yönlendiricinin kapasitesi temel alınarak belirlenir. Eşik çok düşükse meşru büyüme oturumu etkileyebilir; çok yüksekse ani tam tablo duyurusu veya yanlış toplu ilan geç fark edilebilir.

Uyarı eşiği ile kesme eşiği destekleniyorsa ikisi ayrı amaçlarla planlanabilir. Eşik aşıldığında yalnız kayıt üretme, yeni rotaları reddetme veya oturumu kapatma gibi davranışlar ürüne göre değişir; ağ işletim ekibi bu davranışı test ederek alarm, müdahale ve geri açma prosedürünü belgelemelidir.

RPKI Köken Doğrulaması

RPKI tabanlı köken doğrulaması, bir prefixi duyuran köken ASN’nin ROA ile yetkilendirilip yetkilendirilmediğini ve duyurulan uzunluğun izinli olup olmadığını denetler. Geçerli, geçersiz veya bulunamadı sonuçları yerel kabul politikasında ayrı ele alınır. Bulunamadı sonucu, duyuruyu kapsayan doğrulanmış yetki verisi olmadığını belirtir; geçersiz ile aynı anlama gelmez. Bu kontrol AS_PATH içindeki bütün geçişleri doğrulamaz.

BGP Filtre Değişikliğini Test Etme ve Aşamalı Uygulama

Filtre değişikliği, doğru görünen bir kuralın doğrudan bütün komşulara uygulanmasıyla başlamamalıdır. Test paketi, kabul edilmesi ve reddedilmesi beklenen örnek rotaları, mevcut rota sayılarını ve değişiklik sonrası gözlenecek teknik göstergeleri içermelidir.

1. Mevcut gelen ve giden politikayı, alınan, kabul edilen ve duyurulan rota sayılarını komşu ve adres ailesi bazında kaydedin.
2. Yeni kuralları örnek prefixler ve AS_PATH değerleri üzerinde çevrim dışı değerlendirin; sınır uzunlukları, varsayılan rota ve route server istisnalarını özellikle sınayın.
3. Platform destekliyorsa önce yalnız kayıt veya önizleme üreten bir aşama kullanın; reddedilecek rotaların beklenen listeyle uyuştuğunu kontrol edin.
4. Değişikliği tek yön, tek adres ailesi veya düşük etkili bir komşulukta etkinleştirerek kapsamı sınırlayın.
5. BGP oturum durumunu, kabul ve duyuru sayılarını, en iyi yol değişikliklerini, erişilebilirliği ve trafik yönündeki olağan dışı kaymaları izleyin.
6. Önceden belirlenmiş gözlem süresi tamamlanıp başarı koşulları sağlanmadan sonraki komşuya geçmeyin. Beklenmeyen etki oluşursa önceki politika sürümünü yeniden uygulayın.