NAT Traversal ve Blockchain #1

NAT Traversal veya diğer bir deyişle “NAT Geçişi”, NAT adlı cihazın da içinde bulunduğu ağlarda P2P (eşler arası) bağlantıyı mümkün kılan yegane şeylerden biridir. Ancak NAT Traversal’ı anlatmadan önce gelin NAT’ın ne olduğunu ve neden var olduklarını öğrenelim. Hikayemiz IPv4 ile başlıyor.

IPv4, İnternet Protokolü versiyon 4 anlamına gelmektedir. Aslında bu protokol temel itibariyle cihazların internet üzerinde birbirlerini bulup iletişime geçmelerini sağlayan en önemli şeylerden biri ancak bu protokol oldukça eski. Temel problemi de bu oluşturuyor zaten. 1983 yılından beri kullanılan IPv4 protokolü adres alanları için 32 bitlik yer kullanır. Bu ne demek?

Gördüğünüz üzere bir IPv4 adresi 3 tane noktayla ayrılmıştır ve 4 ayrı kısımdan oluşmaktadır. Her bir kısım ise 8 bit veya 1 bayt uzunluğundadır. Dolayısıyla bir IPv4 adresi 32 bit veya 4 bayt uzunluğunda olmaktadır. 8 bitte elde edebileceğiniz en büyük sayı ²⁸-1'dir ve bu da 255'e tekabül etmektedir. Yani IPv4 ile adresleyebileceğiniz cihaz sayısı 2⁵⁵⁴’e, o da 4.228.250.625'e tekabül etmektedir. İlk bakışta oldukça büyük bir sayıya benziyor değil mi? 1983 yıllarındaki IPv4'ü icat eden bilim insanları de aynı şeyi düşünüyordu ancak günümüzde bu sınır çok rahatlıkla ulaşılabilir hatta ve hatta nispeten ulaşılmış bir sınırdır. Nitekim bu problem önceden görülüp 128 bit ile adresleme sağlayan IPv6 yani İnternet Protokolü versiyon 6 geliştirilmiş olsa da bütün adreslerin IPv6'ya geçmesi zaman alacağından ve maliyetli olacağından ISP’ler (İnternet Servis Sağlayıcısı) bu duruma daha değişik, geçici ve ucuz bir çözüm bulmak zorunda kaldılar. Nitekim daha fazla IP adresi onlar için daha fazla müşteri anlamına gelmektedir. Dolayısıyla da John Mayes’in 1994'te aslında bir güvenlik önlemi olarak kullandığı NAT yöntemini kendi ağlarına entegre etmeye başladılar. Peki nedir bu NAT denilen şeyler?

NAT (Network Address Translators/Ağ Adresi Çeviricileri)

NAT’lar aslında birkaç IP’yi gruplar haline getirip hepsinin internete tek bir genel IP adresi üzerinden iletişime geçmesini sağlayan cihazlardır. Bu sayede IP kullanım oranını düşürüp ISP’lerin daha fazla cihazı adresleyebilmesini sağlarlar. Ancak bu yapılan eylem tahmin edilebileceği gibi faydaları yanında birkaç problemi de yanında getirir. NAT entegre edilmiş ağlar için artık cihazlar iki IP adresine sahip olacaklardır. Bunlardan biri genel yani NAT dışındaki cihazların gördüğü IP adresidir (Public/External IP Address). Diğeri ise NAT’ın içindeki gizli IP adresidir (Private/Internal IP Address).

Gördüğünüz gibi artık NAT arkasındaki cihazların NAT’ın yönettiği grubun içinde kendine has bir IP adresi varken direkt internete bağlanabileceği bir IP adresi yoktur. Nitekim bu P2P bağlantıyı yaralayan önemli bir husustur. Çünkü P2P bağlantıda gönderici iletişimi başlatmak için (veya diğer bir deyişle ilk defa diğer bilgisayara “mesaj yollamak” için) artık alıcının NAT arkasındaki IP’sini de bilmek zorunda kalacaktır veya diğer bir deyişle gönderici (bu örnekte P2P bağlantıyı başlatan kişi) sadece NAT’ın genel IP adresini bileceğinden gönderilen mesajlar sadece NAT’a gidecek ve NAT’ın bu mesajı kendi özel ağı içerisinde kime ileteceğini bilmemesinden kaynaklı gelen mesaj hedef cihaza iletilemeyecektir. Kendinizi NAT’ın yerine koyun ve bir hayal edin: Size 10 tane kişi verildi, hiç birinin ismini bilmiyorsunuz ve rastgele bir yerden “Ahmet’e şu mesajı iletir misin?” isteği geliyor ancak siz Ahmet’in kim olduğunu bilmediğinizden mesajı da iletemiyorsunuz. Peki her NAT aynı mıdır? Tabii ki hayır, NAT’lar da kendi aralarında kısıtlamalar açısından:

-Full Cone NAT

-(Address) Restricted Cone NAT

-Port-Restricted Cone NAT

-Symmetric NAT

olmak üzere dörde ayrılırlar. Hadi gelin teker teker hepsinin ne anlama geldiklerine bakalım.

Full Cone NAT (Bire-bir NAT)

Bire-bir NAT içlerinde en basit olanıdır. NAT üzerinde bir iç adres (Private/Internal IP Address) bir dış adresle(Public/External IP Address) eşleştirilir. NAT arkasındaki cihaza ulaşabilmek için onun NAT şeması üzerindeki adres ve port değerini bilmek yeterlidir. Eşleştirilmeden sonra NAT üzerindeki adres ve porta gelen veri direkt olarak eşleştirilen cihaza iletilecektir.

(Address) Restricted Cone NAT ((Adres) Kısıtlamalı Koni NAT)

Adres kısıtlamalı NAT’lar da bir iç adres ve dış adres arasında eşleştirme yaparlar ancak bu eşleştirme bire-bir tipteki NAT’lar gibi önceden ve statik bir şekilde yapılmaz. Eşleştirme bir iç adres tarafından bağlantı isteği alındığı zaman NAT tarafından dinamik bir şekilde yapılır. Dolayısıyla da bir dış sunucu NAT üzerinden bir iç adresle bağlantı kurabilir ancak bağlantının kurulabilmesi için iç adresin ilk olarak dış sunucuya bağlantı isteğini göndermiş olması gerekir. Aksi takdirde eşleştirme olmadığından dış sunucudan gelen mesaj iç adrese iletilemeyecektir (aynı önceden bahsettiğim Ahmet’e gelen mesaj örneğindeki gibi). Bu da Adres Kısılamalı NAT’ları Bire-Bir NAT’lardan ayıran şeydir.

Port-Restricted Cone NAT (Port-Kısıtlamalı Koni NAT)

Port Kısıtlamalı NAT’lar da aynı Adres Kısıtlamalı NAT’lar gibi dinamik şekilde bir iç adres ve dış adres arasında eşleştirme yaparlar. Dolayısıyla da aynı Adres Kısıtlamalı NAT’larda olduğu gibi bir dış sunucunun iç adresle bağlantı kurabilmesi için ilk önce iç adresin dış sunucuyla bağlantı kurmuş olması gerekir. Port Kısıtlamalı NAT’ları, Adres Kısıtlamalı NAT’lardan ayıran şey ise isminden de anlaşılabileceği gibi kısıtlamanın sadece adres üzerinden değil ek olarak port üzerinde yapılmasıdır. Yani Adres Kısıtlamalı NAT’lar ile bağlantı kurulduktan sonra dış sunucu herhangi bir porttan iç adres’e veri gönderebilirken Port Kısıtlamalı NAT’lar için dış sunucular sadece bağlantı kurdukları adres ve port üzerinden veri gönderebilirler.

Symmetric NAT (Simetrik NAT)

Simetrik NAT’lar önemli bir değişiklik dışında tıpkı Port Kısıtlamalı NAT’lar gibi davranırlar. Bu önemli değişiklik de karmaşık olsa da şekilde açıklanabilir. Port Kısıtlamalı NAT’lar üzerinden bir başka server aynı adres ve port değerleriyle bir iç adresle bağlantı kurabilirler nitekim Port Kısıtlamalı NAT eşleştirmeyi yaptıktan sonra eşleştirmeyi kimin için yaptığına bakmaksızın eşleştirdiği adres ve porttan gelen her mesajı eşleştirdiği iç adrese iletecektir. Nitekim Simetrik NAT’lar gelen verinin kimden geldiğine de bakar ve eğer spesifik bir dış sunucu için açtığı adresten başka bir dış sunucu iletişim kurmayı denerse Simetrik NAT bu iletişimi reddecektir. Tıpkı Port Kısıtlamalı NAT’lar gibi ilk başta iç adresin bağlantı isteği göndermesi gerekir ancak bu işlem her farklı dış adres için tekrarlanmalıdır. Simetrik NAT’lar genelde şirketler için kullanılırlar günlük hayatınızda kullandığınız cihazlar genelde Port Kısıtlamalı veya Adres Kısıtlamalı NAT’lardır (tabii birazcık değişik konfigürasyonlarla).

Bu bölümde oldukça NAT’ların “eşleştirmesinden” bahsettim bu yazının daha da uzamamasını istediğimden bu havada kalan kavramı açıklamak yerine Gökhan Şengün’ün “eşleştirme” kavramını somut bir şekilde açıklayan şu yazısına bakabilirsiniz. Gördüğünüz üzere internet denilen kavram ISP’lerin nispeten daha fazla hizmet vermek istemeleri (veya daha fazla para kazanmak istemeleri, yorum artık size kalmış) ve bunu yaparken de gizlilik, mahremiyet ve P2P bağlantı gibi konuları umursamamaları Blockchain gibi P2P bağlantı üzerine inşa edilmiş ağlar için oldukça zorlayıcı bir şeydir. Nitekim bildiğiniz gibi Blockchain denilen kavram aslında Node’ların tuttuğu kayıt defterlerine dayanmaktadır ve bu kavram ağ üzerindeki Node’ların birbirleriyle bağlantı kurup konuşabilmesi üzerine var olabilmiştir. Peki Blockchain Node’ları bu kadar çeşitli zorluklar arasından nasıl sıyrılıp birlikte konuşmayı başarabiliyorlar? Tabii ki de NAT Traversal adını verdiğimiz yöntemler sayesinde. Bu yazıda yazının daha da uzamaması ve teknikleşmemesi adına sadece Hole-Punching ve Relaying adı verilen tekniklere göz atacağız ancak sonraki yazılarda STUN, TURN, UPNP ve ICE gibi protokollere de değineceğiz. Peki bunlardan bana göre en kolayı olan Relaying nedir?

Relaying

Relaying temelde yapılabilecek en basit ve “güvenilir” olan tekniklerden biridir. İki NAT arkasındaki cihaz birbirleriyle konuşamazlar çünkü içlerinden herhangi biri bir diğerinin NAT arkasındaki adresini bilmemektedir. Dolayısıyla da iletişimi başlatamamaktadır. Bundan dolayı yapılabilecek en basit şey Relaying’tir. Bu metot temel anlamda bağlantıyı internete direkt bağlı olan (yani bir NAT’ın arkasında olmayan) bir sunucu üzerinden geçirmekte yatar. İki istemci de bu sunucuya bağlanır ve bunlar üzerinden konuşmaya başlayabilirler.

Relaying iki istemci de sunucuya bağlı olduğu sürece doğru bir şekilde çalışacaktır ancak bu yöntemin dezavantajı sunucunun işlem gücünü ve bant genişliğini kullanmasının yanı sıra sunucuyla bağlantı ne kadar iyi olursa olsun aradaki gecikmedir. Bununla birlikte, mevcut tüm NAT’larda güvenilir bir şekilde çalışan daha verimli bir teknik olmadığından, bağlantıda maksimum kesinlik (Networking’de bir istemciye bağlanabilmek için birden fazla yöntem kullanmanız gerekir ve her birinin işe yarayacağının garantisi yoktur.) isteniyorsa Relaying yararlı bir stratejidir. TURN protokolü de Relaying’i nispeten güvenli bir şekilde uygulama yöntemini tanımlar. Nitekim istemcilerden sadece biri NAT arkasındaysa ilk başta Relaying sayesinde NAT arkasında olmayan istemci kendi IP adresini NAT olan cihaza iletir, bu sayede NAT arkasında olan cihaz internete direkt olarak bağlı olan cihaza bir bağlantı isteği gönderebilir ve bağlantı sunucunun üzerinden alınıp kendi aralarında başarıyla sağlanabilir. Keza bu işlemin ismine de “Connection Reversal” denir.

Hole Punching

Hole Punching aslında cihazların ne kadar fazla NAT arkasında olduklarına (Common, Different, Multiple Levels) göre çok az da olsa değişebilmektedir ancak hepsinde genel olarak konsept aynıdır: İlk başta istemciler yine internete direkt olarak bağlanan bir sunucu (Buna randevu sunucusu da denmektedir.) üzerinden birbirleriyle iletişime geçmeyi denerler. Nitekim bu noktada başarılı olan istemciler birbirlerine NAT arkasındaki adreslerini iletirler. Ardından ise ikisi de birbirlerine boş bir istek yollarlar bunun sebebi mesajların NAT’lar tarafından reddedilecek olmasıdır. Bu istekler reddedildikten sonra istekler tekrardan yollanır ancak bu sefer NAT’lar gelen mesajın önceki (yani gönderilemeyen başarısız istek) isteğe bir cevap olduğunu düşündükleri için mesajları başarıyla iletecektir ve bu sayede bağlantı direkt olarak iki istemci arasında gerçekleşecektir.

Bu resimde gördüğünüz örnek farklı (Different Private Networks) iç/özel ağlarda bulunan bilgisayarlar arasındaki Hole Punching metodunun çalışma yöntemini gösteriyor, şimdi gelin bir de ikisi de aynı özel ağda bulunan bilgisayarlar için Hole Punching’in nasıl işlediğine bakalım:

Aynı NAT arkasında bulunan cihazlar için Hole Punching

Senaryo kısmen aynı aslında, ilk önce iki istemci de randevu sunucusu üzerinden birbirlerine bir iletişim başlatma isteği yollarlar. Bunu gören randevu sunucusu istemcilere ulaşmak istedikleri istemcilerinin iç ve dış adreslerini geri gönderiyor. Yine farklı özel ağdaki bilgisayarlar gibi ikisi de bu sefer randevu sunucusu üzerinden olmamak üzere NAT’ları aracılığıyla bir konuşma isteği yolluyorlar. Bu durumda arkasında oldukları NAT’ın direkt bağlantıya izin verip vermemesine de bağlı olmak üzere durum çatallanıyor. Eğer izin veriyorsa görselde görüldüğü üzere iki bilgisayar da aynı özel ağın içinde olduklarını fark edip direkt bir iletişim sağlıyorlar ancak izin vermiyorsa NAT üzerinden konuşmaya başlıyorlar. Bu örnek en ütopik ve güzel olanı ama tabii ki bunun tam tersi yani distopik olanı da var. Onun ismi “Birden fazla NAT arkasında olan cihazlar”. Hadi gelin şimdi de onlara bir göz atalım:

Birden fazla NAT arkasında olan cihazlar için Hole Punching

Açıkçası birden fazla NAT arkasında olan cihazlar için Hole Punching bazen çalışmayabilir. Nitekim bu bilgisayarlar o kadar derinlerde yer alıyorlar ki internete bağlanabilmelerine bile şaşırmak lazım ancak niye birbirlerine bağlanamıyorlar sorusunu kısaca şöyle yanıtlayabiliriz: Birden fazla NAT arkasında olan cihazlar için randevu sunucusu bu bilgisayarların iç adreslerini ve hatta dış adreslerini bile bilmiyor. Çünkü iki istemcinin de iletişim başlatma istekleri aynı IP adresi üzerinden gelecektir maksimum farklılıksa portlar olacaktır. Yani A istemcisi sunucuya X adresi 1 portundan mesaj gönderiyorsa B istemcisi aynı sunucuya yine X adresinden ancak muhtemelen farklı bir port üzerinden mesaj iletecektir. Dolayısıyla randevu sunucusu birbirlerine iç ve dış adreslerini yollayamayacaktır ancak bir şekilde birbirlerinin iç ve dış adreslerini birbirlerine iletebilseler de yine de birbirleriyle iletişime geçebilecekleri kesin değildir. Çünkü birden fazla NAT arkasında olduğunuz sürece iki NAT arkasındaki iletişim eğer doğru sağlanmamışsa aynı IP adresi ikisi için farklı istemciler anlamına gelebilmektedir bu da çakışmalara sebep olacaktır. Kısacası birden fazla NAT arkasında olduğunuz sürece P2P bağlantı sağlayamazsanız diyemeyiz ancak oldukça zor olduğu da bir gerçektir. Nitekim bundan sonraki yazımızda bahsedeceğimiz Hairpin/Loopback tarzı yöntemlerle bu istemcilerin P2P bağlantı sağlayabilmesini bir nebze de olsa mümkün kılabiliyoruz.

Günümüzde her blockchain node’u kendi blockchain ağına bağlanmak için bu yöntemleri kullanır ve ISP’lerin nispeten zarar verdikleri bu merkezi internet yapısında birbirleriyle iletişime geçip merkeziyetsiz bir dünya oluşturmayı amaçlarlar ve nitekim başarırlar da. Bu yazıda güncel blockchain ağlarını çalıştıran node’ların binbir türlü zorlukla birbirlerine bağlanıp bir ideal uğrunda birbirlerine transaction yollamaları ne kadar kolay gözükse de aslında oldukça uğraştırıcı ve zor bir işlem olduğuna dikkat çekmek istedim. Nitekim birlikte blockchain ağı yazacağımız sonraki yazılarda bu bilgiler çok işimize yarayacak.

Okuduğunuz için teşekkür ediyorum, kendinize iyi bakın ve BlockchainDEU’yla kalın.

-Koray AKPINAR