ASN ile BGP Prefix Duyurusu Nasıl Planlanır?

Sesli Dinle — Makale

Kendi ASN’niz üzerinden BGP duyurusu yapmak, ASN’yi internette ayrı bir ağ hedefi olarak duyurmak anlamına gelmez. BGP oturumunda bir prefixin erişilebilirlik bilgisi paylaşılır. ASN ise duyurunun geçtiği otonom sistemleri gösteren AS_PATH özniteliğinde, bu prefixin köken otonom sistemini tanımlar.

Duyuru planı yalnız BGP oturumunun kurulmasına dayanmaz. Plan; prefix ve ASN kullanım yetkisini, diğer ağlara erişim sağlayan upstream bağlantısını, iç ve dış yönlendirme politikalarını, RPKI kaydını, izleme yöntemini ve geri alma adımını birlikte kapsamalıdır.

Bu plan yalnız kuruluşun kullanmaya ve duyurmaya yetkili olduğu kaynakları kapsamalıdır. Kaynaklar doğrudan kuruluşa tahsis edilmiş veya kaynak sahibi tarafından açıkça yetkilendirilmiş olabilir. Başkasının prefixini ya da ASN’sini yetkisiz kullanmak hizmet kesintisine ve yönlendirme güvenliği ihlaline yol açabilir.

Kaynak Yetkisini ve Duyuru Kapsamını Doğrulama

BGP oturumu kurulmadan önce hem ASN'nin hem de prefixin kullanım yetkisi belgelenmelidir. RIR’deki (Regional Internet Registry) veya ilgili kaynak yöneticisindeki tahsis kaydı, kuruluş bilgisi, prefix durumu ve yetkili irtibat kişileri birbiriyle tutarlı olmalıdır. İnternet servis sağlayıcısı, kendi kabul sürecine göre ek yetki belgesi veya kayıt güncellemesi isteyebilir.

ASN ve Prefix Kayıtlarının Eşleşmesi

Köken ASN, AS_PATH içinde duyurunun çıktığı otonom sistem olarak görünür. Duyurulacak prefix doğrudan aynı kuruluşa tahsis edilmemişse, kaynak sahibinin açık yetkilendirmesi ve internet servis sağlayıcısının kabulü olmadan işlem yapılmamalıdır. Kaynak kayıtlarını sorgulamak için kullanılan RDAP hizmeti ilk kontrolü destekler; tek başına güncel kullanım ve duyuru yetkisini kesinleştirmez.

Her prefix, ağ adresi ile eğik çizgiden sonraki prefix uzunluğunu birleştiren CIDR gösterimiyle listelenmelidir. Üst blok, alt blok ve geçici daha özel duyurular ayrı satırlarda ele alınmalı; plan dışında kalan hiçbir ağ bloğu dışa aktarım filtresine eklenmemelidir.

Kabul Edilecek Prefix Uzunlukları

İnternette her prefix uzunluğunun tüm ağlar tarafından kabul edileceği varsayılamaz. İnternet servis sağlayıcısı ve diğer ağlar kendi filtreleme sınırlarını uygular; bu nedenle ilan edilecek en genel prefix ile izin verilecek daha özel prefixler sözleşme ve teknik kabul kaydında açıkça belirtilmelidir.

Daha özel prefix, daha küçük bir adres bloğunu kapsar. Aynı hedef adresle eşleşen yollar yönlendirme tablosuna alınmışsa paket iletiminde en uzun prefix eşleşmesi kullanılır; böylece belirli alt ağlara gelen trafik farklı bağlantılara yöneltilebilir. Bu amaçla yapılacak duyuruların hem internet servis sağlayıcısının filtrelerine hem de duyuru yetkisini belirten ROA kayıtlarına uygunluğu önceden doğrulanmalıdır. Aşırı geniş izinler, yanlış bir alt prefixin duyurulması halinde etki alanını büyütebilir.

İnternet servis sağlayıcısı filtrelerini prefix ile köken ASN bilgisini tutan IRR veritabanlarından üretiyorsa, ilgili route veya route6 nesnesinin prefix ve köken ASN bilgisiyle uyumlu olması gerekebilir. Bu kayıt BGP’nin protokol düzeyindeki şartı değildir; internet servis sağlayıcısının yetkilendirme ve filtre üretme sürecinin parçasıdır. Hangi IRR veritabanının esas alındığını internet servis sağlayıcısıyla önceden doğrulayın. Yanlış veya eski IRR verisi, doğru bir BGP yapılandırmasına rağmen prefixin reddedilmesine yol açabilir.

Upstream Bağlantısını ve BGP Oturumunu Tasarlama

Upstream, kuruluşa kendi ağı üzerinden diğer internet ağlarına erişim sunan internet servis sağlayıcısını belirtir. Oturum tasarımı yalnız komşu IP adreslerinden oluşmaz; adres ailesi, ASN bilgileri, bağlantı yedekliliği, oturum koruması ve kabul edilecek rota sayısı da aynı teknik kayıtta bulunmalıdır.

Oturum Bilgileri ve Bağlantı Bağımlılıkları

Her BGP komşuluğu için yerel ve uzak ASN, komşu adresleri, IPv4 ve IPv6 adres aileleri, bağlantı devresi, sorumlu ekipler ve iletişim kanalı belirlenmelidir. TCP erişimi, güvenlik duvarı kuralları ve internet servis sağlayıcısının istediği oturum doğrulama yöntemi bakım penceresinden önce test edilmelidir.

Tek upstream ile duyuru teknik olarak mümkündür, ancak fiziksel devre veya internet servis sağlayıcısı arızasında dış erişim kaybolabilir. Birden fazla upstream kullanılacaksa her oturum için aynı prefixlerin duyurulup duyurulmayacağı, tercih sırası ve arıza halinde beklenen davranış ayrı ayrı tanımlanmalıdır.

Oturum zamanlayıcıları, hızlı arıza algılama seçenekleri ve bakım sırasında uygulanacak yeniden kurma davranışı iki tarafın desteklediği özelliklere göre belirlenmelidir. Daha kısa zamanlayıcılar arızayı daha erken fark edebilir, ancak kararsız bağlantılarda oturum dalgalanmasını artırabilir. Evrensel bir değer yerine devre kalitesi, cihaz kapasitesi ve upstream işletim politikası esas alınmalıdır.

Alınacak Yönlendirme Bilgisinin Seçilmesi

Kuruluş, upstream'den yalnız varsayılan rota, kısmi rota kümesi veya tam internet tablosu alabilir. Seçim; yönlendirici kapasitesi, yedeklilik modeli, trafik mühendisliği ihtiyacı ve operasyon ekibinin izleme yeteneğine bağlıdır.

Tam tablo almak otomatik olarak daha iyi yönlendirme sağlamaz. Bellek, işlemci, yakınsama süresi ve filtreleme yükü artar. Tek çıkışlı yapılarda varsayılan rota yeterli olabilir; çoklu bağlantıda ise daha ayrıntılı yol bilgisi gerekebilir.

İçe ve Dışa Aktarım Politikalarını Açıkça Tanımlama

Farklı otonom sistemler arasındaki eBGP oturumlarında, içe ve dışa aktarım politikaları açıkça tanımlanmadan yollar kabul edilmemeli veya duyurulmamalıdır. Dışa aktarım politikası, yalnız kuruluşun duyurmaya yetkili olduğu prefixlerin beklenen köken ASN ile duyurulmasına izin vermelidir. İçe aktarım filtresi de upstream'den beklenen kapsam dışındaki yolları reddetmelidir.

Politika belgesinde en az şu kararlar yer almalıdır:

• Duyurulacak kesin prefix listesi ve izin verilen en uzun prefix uzunluğu.
• Her upstream için dışa aktarılacak ve içe alınacak adres aileleri.
• Beklenen maksimum prefix sayısı ve bu sınır aşılırsa uygulanacak davranış.
• Çıkış tercihini belirleyen LOCAL_PREF, AS_PATH içinde kendi ASN’sini tekrarlama yöntemi olan prepending, komşuya giriş tercihi öneren MED veya yolları politikaya göre gruplandıran community etiketleri kullanılacaksa amaç ve geri alma koşulu.
• Kuruluşun, iki dış ağ arasındaki trafiği istemeden taşıyan bir transit ağ haline gelmesini engelleyen dışa aktarım sınırları.

Yönlendirme öznitelikleri trafik akışını etkileyebilir, ancak internette kesin sonuç garanti etmez. Komşu ağlar kendi politikalarını uygular. Bu nedenle her politika değişikliği önce dar kapsamda devreye alınmalı ve gerçek trafik etkisi ölçülmelidir.

Duyurulan prefixin kuruluşun iç yönlendirme tablosunda geçerli bir karşılığı bulunmalıdır. BGP oturumu kurulmuş olsa bile, iç ağda hedefe ulaşmayan bir prefix dışarıdan trafik çekerek paketlerin hedefe ulaşmadan düşmesine, yani bir kara delik oluşmasına yol açabilir. Daha küçük prefixlerin tek üst prefixte özetlenmesi, yedek yol ve kullanılmayan adres alanına gelen trafiğin nasıl sonlandırılacağı ağ tasarımında ayrıca belirlenmelidir.

RPKI ve ROA Uyumunu Duyurudan Önce Sağlama

RPKI tabanlı köken doğrulaması, bir prefixi hangi ASN'nin kaynak olarak duyurmaya yetkili olduğunu denetlemek için kullanılır. ROA, prefixi, yetkili köken ASN’yi ve gerekiyorsa izin verilen en uzun prefix uzunluğunu tanımlayan imzalı yetkilendirme kaydıdır.

Yetkili kaynak yöneticisi ROA’yı BGP değişikliğinden önce yayımlamalı; planlanan prefix, köken ASN ve uzunluk eşleşmesi bağımsız doğrulayıcılarda kontrol edilmelidir. Köken ASN yanlış yazılırsa veya duyuru ROA'nın izin verdiğinden daha uzun bir prefix kullanırsa yol RPKI açısından geçersiz değerlendirilebilir. Bazı ağlar bu yolları reddedebilir veya daha düşük öncelikle değerlendirebilir.

maxLength, ROA’daki üst prefix altında izin verilen en uzun prefix uzunluğudur. Değeri artırmak yalnız seçilen bir alt prefixi değil, izin verilen uzunluklara kadar kapsanan bütün alt prefixleri yetkilendirir. Yalnız belirli alt prefixler duyurulacaksa mümkün olduğunda her birini tam uzunluğuyla yetkilendiren kayıtlar kullanılmalıdır. Daha özel duyuru gerekmiyorsa maxLength alanı boş bırakılabilir veya üst prefixin uzunluğuyla aynı tutulabilir; bu durumda yalnız tam eşleşen prefix yetkilidir.

RPKI tabanlı köken doğrulaması, bütün BGP güvenlik sorunlarını çözmez; köken ASN ile prefix ve izin verilen uzunluk eşleşmesini denetler. AS_PATH'in tamamının doğruluğu, oturum güvenliği, prefix filtreleri ve değişiklik kontrolü ayrı önlemler olarak kalır.

BGP Duyurusu İçin Değişiklik Penceresi ve Geri Alma Planı

Duyuru, düşük riskli bir değişiklik penceresinde ve ilgili internet servis sağlayıcısı ekipleri erişilebilirken yapılmalıdır. Uygulanacak politika değişikliği önceden gözden geçirilmeli, mevcut yapılandırma yedeği alınmalı ve değişiklik kapsamı yalnız planlanan komşuluklarla sınırlandırılmalıdır.

Geri alma planı, yalnız “önceki ayara dön” ifadesinden oluşmamalıdır. Hangi dışa aktarım politikasının geri yükleneceği, yeni prefixin nasıl geri çekileceği, eski yolun ne zaman yeniden etkinleştirileceği ve internet servis sağlayıcısına hangi kanaldan bildirim yapılacağı sıralı biçimde yazılmalıdır.

Değişiklikten önce mevcut trafik hacmi, erişilebilirlik, gecikme, paket kaybı, BGP rota sayıları ve RPKI durumu için bir başlangıç ölçümü alınmalıdır. Yeni duyuru önce tek bir komşulukta veya sınırlı bir prefix kümesinde etkinleştirilebiliyorsa kademeli geçiş tercih edilir. Böylece beklenmeyen etki tüm bağlantılara yayılmadan fark edilebilir.

Aşağıdaki kontrol tablosu, duyuru öncesi geçiş kararını somut kanıta bağlar.

Duyuru Sonrası Görünürlüğü ve Trafiği İzleme

BGP görünürlüğü tek bir sorgu noktasından kesinleştirilemez. Önce yerel yönlendiricide oturum durumu, gönderilen prefix sayısı, kabul edilen rota sayısı ve politika sayaçları kontrol edilmelidir. Ardından farklı ağlardan çalışan rota toplayıcılar, uzak bir yönlendiricinin gördüğü yolları sorgulatan looking glass hizmetleri ve RPKI doğrulayıcılarıyla dış görünüm karşılaştırılmalıdır.

İzleme yalnız “prefix göründü” sonucuna dayanmaz. Farklı operatörlerden erişilebilirlik, dönüş yolunun beklenen internet servis sağlayıcısına gelmesi, gecikme ve paket kaybındaki değişim, beklenmeyen daha özel duyurular ve RPKI durum değişiklikleri birlikte izlenmelidir.

Durdurma eşikleri değişiklikten önce belirlenmelidir. Prefixin RPKI açısından geçersiz görünmesi, yalnız bazı ağlarda erişilebilir olması, yanlış internet servis sağlayıcısı üzerinden çıkması, iç ağda kara delik oluşması veya beklenmeyen rota sayısı artışı geri alma kararını tetikleyebilir.