NAT Nedir? Ağ Adresi Çevirisi Nasıl Çalışır?

NAT iki iş yapar ve ikincisi çoğu anlatımda atlanır: dışarı çıkan paketin kaynak adresini değiştirir, sonra o değişikliği bir deftere yazar. Defteri olmasaydı çeviri tek yönlü bir numara olurdu; cevap geri döndüğünde onu kimin istediği bilinemez, paket kenarda ölürdü. NAT’ı anlamak, adresin değiştiğini bilmek değil, o defterin ne tuttuğunu bilmektir.

Kurumsal network kurulumu rehberimizde ağın sınırını pasaport kontrolüne benzetmiştik: kendi ülkenizin içinde kimse sizden her adımda kimlik sormaz, ama sınıra geldiğinizde yerel kimliğiniz yetmez ve size dışarıda geçerli bir pasaport verilir. O anlatı sınırın yolcu tarafında duruyordu. Bu makale kabinin içine giriyor, çünkü asıl mekanizma orada: memurun önündeki defterde.

Aşağıda o defteri gerçekten açacağız. Buradaki bütün komutlar ve çıktılar kendi laboratuvarımızda alındı, hiçbiri başka bir kaynaktan aktarılmadı: tek bir Linux makinesinde küçük bir NAT geçidi kurup çevirinin iki tarafını aynı anda yakaladım, çeviri tablosunun kendisini ekrana bastım ve aynı iç porttan çıkan iki bağlantının dışarıda nasıl ayrıldığını ölçtüm.

Mekanizmayı hemen görmek isterseniz doğrudan çeviri tablosunun açıldığı bölüme atlayabilirsiniz. Sonunda da sahadan iki gerçek vaka var: birinde çıkış trafiğiyle VPN trafiği bilerek iki ayrı hatta bölündü, diğerinde bir ISP geçişi sırasında kurumun dış kimliği değişti.

NAT Nedir? Adres Çevirisinin İki Yarısı

NAT (Network Address Translation), bir paketin geçtiği cihazda adres bilgisini değiştiren ve bu değişikliği bir tabloda tutan mekanizmadır. Değiştirme kısmı kolaydır; tabloyu tutma kısmı NAT’ı NAT yapan şeydir. Terimlerini Ağustos 1999 tarihli RFC 2663, ofislerde kullanılan klasik biçimini Ocak 2001 tarihli RFC 3022 tanımlar.

Sınır kapısındaki memuru düşünün. Yaptığı iş yalnızca size bir pasaport uzatmak değil. Uzattığı anda deftere bir satır yazıyor: “bu pasaportla, şu saatte, şu vatandaş çıktı.” Dışarıdan bir cevap geldiğinde memur o deftere bakıyor ve cevabın kime ait olduğunu oradan buluyor. Defteri yakın, pasaport işe yaramaz hale gelir: insanlar dışarı çıkabilir ama hiçbiri geri dönemez.

Makale boyunca bu sahnede kalacağız. Eşleşmeler şöyle, hepsini sırasıyla açacağız:

NAT Neyin Kısaltması?

NAT, Network Address Translation ifadesinin kısaltmasıdır. Türkçede ağ adresi çevirisi ya da ağ adresi dönüştürmesi olarak geçer, iki kullanım da yaygındır.

Kısaltmanın kendisi ağ dünyasına ait değil: tıpta, denizcilikte, havacılıkta ve edebiyatta da aynı harfleri taşıyan başka anlamlar var. Bir cihaz arayüzünde ya da bir belgede NAT gördüğünüzde bu sorun çıkarmaz, bağlam zaten bellidir. İnternette arama yaparken ise tamlamayı tam yazmak işinizi kolaylaştırır: network address translation ya da NAT ağ adresi çevirisi aramak, sonuçları doğru alana daraltır.

Beşli Demetin İkisi Değişir

Bir TCP ya da UDP bağlantısını tanımlayan şey tek bir adres değil, beş bilgiden oluşan bir demettir: kaynak adres, kaynak port, hedef adres, hedef port ve protokol. Bu demetin niçin bir kişiyi değil bir bağlantıyı tanımladığını port ve soket rehberimizde ayrıntılı ele almıştık.

NAT’ın yaptığı iş bu beşlinin tamamını değil, ikisini değiştirmektir: kaynak tarafını ya da hedef tarafını. Hangisini değiştirdiği, birazdan göreceğimiz SNAT ve DNAT ayrımının tamamıdır.

Buradaki incelik şu: beşli değiştiği anda bağlantı, dışarıdaki taraf için başka bir bağlantı haline gelir. Karşı taraf sizin iç adresinizi hiç görmez, göremez de. Onun bildiği tek şey pasaportun üstündeki numaradır.

NAT Neden Var? IPv4 Adres Kıtlığı ve Özel Adres Blokları

NAT bir güvenlik özelliği olarak tasarlanmadı, bir kıtlık çözümü olarak tasarlandı. IPv4 adres alanı yaklaşık 4,3 milyar adres taşır ve bu sayı, her cihaza bir adres verecek kadar büyük değildir.

Çözüm iki parçalıydı. Birincisi, herkesin serbestçe kullanabileceği ama internette yönlendirilmeyen adres blokları ayrıldı: 10.0.0.0/8, 172.16.0.0/12 ve 192.168.0.0/16. Bu bloklar ve alt ağ maskesinin sınırı nereden geçirdiği IP adresi ve subnet maskesi rehberimizde anlatılıyor. İkincisi, bu adreslerin dışarı çıkarken gerçek bir adrese çevrilmesi gerekti. İşte o çeviri NAT’tır.

Metafora oturttuğumuzda tablo netleşiyor: yerel kimlik ülke içinde geçerlidir ve herkeste aynı numaralar bulunabilir, çünkü karşılaştırılacakları bir uluslararası kayıt yoktur. Sınırdan çıkarken ise dünyada tek olan bir belge gerekir. NAT, bu iki dünyayı birbirine bağlayan tercümandır.

Bunun bir yan etkisi var ve makalenin geri kalanı büyük ölçüde o yan etkiyle uğraşıyor: dışarısı artık sizi tek tek tanımıyor. Bu bazen istediğiniz şeydir, bazen de tam olarak çözmeye çalıştığınız sorundur.

NAT Türleri Nelerdir? Statik, Dinamik ve PAT

Adres çevirisi tek bir şey değil, üç farklı kurulumun ortak adı. Ayrımı belirleyen şey basit: kaç iç adrese kaç dış adres düşüyor ve eşleşme kalıcı mı?

Sınır kapısında karşılıkları da net. Statik NAT, belirli bir kişiye ayrılmış ve hep aynı kalan bir pasaport numarasıdır. Dinamik NAT, kapıdaki numara havuzundan boştaki bir numarayı verip kişi dönünce geri almaktır. PAT ise tek bir pasaportu herkese verip yanına sıra numarası yazmaktır; makalenin geri kalanı büyük ölçüde bunu anlatıyor, çünkü sahada karşılaşacağınız kurulum bu.

Bir dördüncü ayrım daha var ve adı NAT türü sanılıp karıştırılıyor: NAT’ın dışarıdan gelen paketi ne kadar sıkı elediği. Bazı kurulumlar, siz bir adrese bağlandıktan sonra o adresten gelen her paketi kabul eder; bazıları yalnızca tam olarak konuştuğunuz adres ve porttan geleni kabul eder, gerisini düşürür.

İkincisi daha güvenlidir ama iki tarafın da NAT arkasında olduğu senaryolarda (görüntülü görüşme, oyun, eşler arası bağlantı) bağlantı kurulmasını zorlaştırır. Bu yüzden aynı hat bazı uygulamalarda sorunsuz çalışıp bazılarında takılabilir; sorun bant genişliğinde değil, kenardaki eleme davranışındadır.

NAT Tablosu Nedir? Çevirinin Tutulduğu Defter

Şimdi defteri açalım. Aşağıdaki ölçümlerin tamamı gerçek bir makinede alındı; komutlar da çıktılar da olduğu gibi duruyor.

Lab: Tek Makinede İki Ayrı Ağ

Bir NAT geçidi görmek için normalde üç şey gerekir: bir iç ağ, bir dış ağ ve ikisinin arasında duran bir cihaz. Bunların üçünü de tek bir Linux makinesinin içinde kurabiliyoruz. Komutlara geçmeden önce kullanacağımız üç kavramı ayrı ayrı tanıtayım, çünkü bunları bilmeden komut satırları anlamsız görünür.

Network namespace, makinenin içindeki ayrı bir ağ ortamıdır. Linux’ta normalde her şey tek bir ağ yığınını paylaşır: aynı arayüzler, aynı adresler, aynı yönlendirme tablosu. Namespace bunu bölmenizi sağlar. Oluşturduğunuz her namespace’in kendi arayüzleri, kendi IP adresi ve kendi yönlendirme tablosu olur; makinenin geri kalanından habersizdir. Pratikte küçük bir sanal makine gibi davranır, ama ayrı bir işletim sistemi ya da ayrı bir bellek alanı gerektirmez. Biz namespace’leri iç ağdaki cihazların yerine kullanacağız.

veth çifti, iki ucu olan sanal bir kablodur. Bir ucundan giren paket öbür ucundan çıkar. Bir ucunu namespace’in içine, öbür ucunu makinenin kendisine takıyoruz. Yani fiziksel bir kablonun yazılım karşılığı; iç ağdaki cihazı geçide bağlayan şey bu.

Geçit, makinenin kendisi. Ubuntu 24.04 çalışan bir sanal sunucudur; hem iki iç ağın kapısı hem de dışarı çıkan taraftır. Dışarıya ens33 arayüzünden, 192.168.1.15 adresiyle çıkıyor.

Kurduğumuz düzen tabloda:

Hedef olarak internetteki bir adres yerine kendi ağımızdaki bir sunucuyu kullanıyoruz. Ölçüm açısından fark etmez: NAT için önemli olan paketin geçitten çıkması ve cevabın dönmesi, çıktıktan sonra nereye gittiği değil. Bağlantıyı 389 portuna, yani LDAP servisine kuruyoruz; o port zaten açık olduğu için cevap veren gerçek bir muhatabımız oluyor.

Şimdi kurulum. Önce iç ağı oluşturuyoruz: bir namespace açıp, sanal kablonun bir ucunu onun içine takıyoruz.

ip netns add ic1
ip link add veth-gw1 type veth peer name veth-ic1
ip link set veth-ic1 netns ic1

Üç satır sırasıyla şunu yapıyor: ic1 adında yalıtılmış bir ağ ortamı açılıyor, veth-gw1 ve veth-ic1 adında iki uçlu bir sanal kablo üretiliyor, sonra kablonun veth-ic1 ucu ic1in içine taşınıyor. Bu andan sonra kablonun bir ucu makinede, öbür ucu iç ağda.

Sıra adres vermekte. Kablonun geçit tarafındaki ucuna geçidin adresini, namespace tarafındaki ucuna cihazın adresini yazıyoruz.

ip addr add 10.10.1.1/24 dev veth-gw1
ip link set veth-gw1 up

ip netns exec ic1 ip addr add 10.10.1.2/24 dev veth-ic1
ip netns exec ic1 ip link set veth-ic1 up
ip netns exec ic1 ip route add default via 10.10.1.1

Buradaki ip netns exec ic1 öneki, “bu komutu ic1in içinde çalıştır” demektir; onsuz komut makinenin kendi ağ ortamına uygulanırdı. Son satır iç cihaza varsayılan ağ geçidini gösteriyor: nereye gideceğini bilmediğin her paketi 10.10.1.1e ver.

Geriye iki şey kalıyor. Makinenin paketleri bir arayüzden alıp diğerine geçirmesine izin vermek, ve çıkarken adresi çevirmesini söylemek.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.10.0.0/16 -o ens33 -j MASQUERADE

Birinci satır olmadan makine gelen paketi öbür arayüze taşımaz, kendisine ait olmayan trafiği sessizce düşürür. İkinci satır ise bütün işi yapan satır ve parça parça okunmayı hak ediyor:

• -t nat: kuralı NAT tablosuna yaz, normal güvenlik duvarı tablosuna değil.
• POSTROUTING: paket makineden çıkmadan hemen önce uygulansın.
• -s 10.10.0.0/16: yalnız iç ağlardan gelen paketlere dokun.
• -o ens33: yalnız dış arayüzden çıkanlara dokun.
• MASQUERADE: kaynak adresi, çıktığı arayüzün kendi adresiyle değiştir.

Pasaport masasının kendisi bu son satır. Bir not: Ubuntu 24.04’te iptables komutu aslında arka planda nftables motorunu kullanıyor, yani yazdığınız kural eski altyapıya değil yenisine gidiyor; komutun sözdizimi ve davranışı aynı kaldığı için bu ölçümü etkilemiyor.

Önce NAT’sız Deneyelim: Paket Çıkıyor ama Dönmüyor

Sahada bu konu anlatılırken verilen standart cevap şudur: NAT olmasa paket dışarı çıkamaz. Deneyi tam olarak bu cümleyi sınamak için kuruyoruz.

Üç adım var. Az önce yazdığımız çeviri kuralını siliyoruz (-A yerine -D, yani ekle yerine sil). Dış arayüzü dinlemeye alıyoruz, böylece makineden gerçekten ne çıktığını görebiliyoruz. Sonra iç ağdan hedefe bağlanmayı deniyoruz.

iptables -t nat -D POSTROUTING -s 10.10.0.0/16 -o ens33 -j MASQUERADE
tcpdump -i ens33 -nn "host 192.168.1.10 and port 389"
ip netns exec ic1 nc -p 40000 -w 3 192.168.1.10 389

Ortadaki tcpdump satırı ens33 arayüzünü dinliyor; -nn adresleri ve portları isme çevirmeden, ham haliyle yazdırmasını sağlıyor. Üçüncü satırdaki nc ise iç ağdan bağlantı kuran taraf: -p 40000 kaynak portunu sabitliyor (birazdan bunun neden önemli olduğunu göreceğiz), -w 3 üç saniye sonra vazgeçmesini söylüyor.

Dış arayüzde görünen:

21:58:31.153681 IP 10.10.1.2.40000 > 192.168.1.10.389: Flags [S], seq 316966271
21:58:32.172475 IP 10.10.1.2.40000 > 192.168.1.10.389: Flags [S], seq 316966271
21:58:33.196472 IP 10.10.1.2.40000 > 192.168.1.10.389: Flags [S], seq 316966271

Standart cevap tutmadı. Paket çıktı, üstelik üç kez çıktı. Kaynak adres olarak 10.10.1.2 yazıyor, yani özel adres olduğu gibi dış arayüze taşındı.

Asıl öğretici olan çıkan satırlar değil, çıkmayanlar: dönüş yok. Aynı paketin üç kez tekrarlanması da bunun kanıtı. Satır sonundaki Flags [S], TCP’nin bağlantı kurma isteği olan SYN paketidir; karşıdan onay gelmediği için aynı istek yineleniyor. Bağlantının nasıl kurulduğunu ve bu üçlü el sıkışmanın adım adım nasıl işlediğini portlar ve TCP rehberimizde anlatıyoruz. Hedef sunucu paketi aldı ve cevabı 10.10.1.2 adresine göndermeye çalıştı; o adres kendi ağında olmadığı için cevap hiçbir yere ulaşmadı.

Yani NAT’ın çözdüğü sorun “paketi dışarı çıkarmak” değil. Paket zaten çıkıyor. NAT’ın çözdüğü sorun cevabın geri dönebilmesi. Sınır kapısında pasaport verilmeseydi de insanlar dışarı yürüyebilirdi; dönemezlerdi, çünkü kimse onları geri kabul etmezdi.

Bu, laboratuvara özel yapay bir durum gibi görünebilir. Değil; sahada birebir böyle yaşadım.

Çeviriyi İki Taraftan Aynı Anda Görmek

Şimdi kuralı geri koyup aynı bağlantıyı, iç kabloda ve dış arayüzde aynı anda dinliyoruz.

İç tarafta, yani çeviriden önce:

21:58:35.240881 IP 10.10.1.2.40000 > 192.168.1.10.389: Flags [S], seq 380829920
21:58:35.242910 IP 192.168.1.10.389 > 10.10.1.2.40000: Flags [S.], ack 380829921
21:58:35.243296 IP 10.10.1.2.40000 > 192.168.1.10.389: Flags [.], ack 1

Dış arayüzde, yani çeviriden sonra, tam aynı saniyede:

21:58:35.242021 IP 192.168.1.15.40000 > 192.168.1.10.389: Flags [S], seq 380829920
21:58:35.242902 IP 192.168.1.10.389 > 192.168.1.15.40000: Flags [S.], ack 380829921
21:58:35.243304 IP 192.168.1.15.40000 > 192.168.1.10.389: Flags [.], ack 1

İki döküm arasındaki tek fark kaynak adres: içeride 10.10.1.2, dışarıda 192.168.1.15. Sıra numaraları (seq 380829920) birebir aynı, zaman damgaları milisaniye farkıyla aynı. Yani bu iki döküm aynı paketin iki farklı noktadaki görüntüsü.

Bu, metaforun tam karşılığı. Aynı yolcu, kapının içinde yerel kimliğiyle, kapının dışında pasaportuyla görünüyor. Dışarıdaki sunucu ömrü boyunca 10.10.1.2 diye bir adres olduğunu öğrenmeyecek.

Defteri Okumak: İki Demet, Tek Satır

Bağlantı ayaktayken çeviri tablosunu okuyoruz:

conntrack -L -d 192.168.1.10

tcp 6 431997 ESTABLISHED src=10.10.1.2 dst=192.168.1.10 sport=40000 dport=389
    src=192.168.1.10 dst=192.168.1.15 sport=389 dport=40000 [ASSURED] mark=0 use=1

Bu satırın okunuşu, tablonun tamamını anlamanın anahtarı. Satırda iki ayrı demet var:

• Birinci demet, giden yön: src=10.10.1.2 dst=192.168.1.10 sport=40000 dport=389. İçerideki cihaz ne gönderdi.
• İkinci demet, beklenen dönüş: src=192.168.1.10 dst=192.168.1.15 sport=389 dport=40000. Cevabın nasıl görüneceği.

Defterin satırı tam olarak budur: “şu vatandaş çıktı, cevabı şu pasaportla gelecek.” Kenar cihaz dışarıdan gelen her paketi bu ikinci demetle karşılaştırır; eşleşen bir satır varsa çeviriyi tersine uygular ve paketi gerçek sahibine yollar.

Tablodaki bir kaydın çevrilip çevrilmediğini anlamanın pratik yolu da burada. İki demeti yan yana koyun: birbirinin aynası ise çeviri yok, değilse çeviri var. Örnek olarak aynı makinenin kendi DNS trafiğinden bir satır:

udp 17 27 src=192.168.1.15 dst=192.168.1.10 sport=55057 dport=53
    src=192.168.1.10 dst=192.168.1.15 sport=53 dport=55057 mark=0 use=1

Burada giden demetin kaynağı 192.168.1.15, dönüş demetinin hedefi de 192.168.1.15. Tam ayna, yani bu trafik çevrilmemiş. Bir üstteki TCP satırında ise giden demetin kaynağı 10.10.1.2 iken dönüş demetinin hedefi 192.168.1.15; ayna bozulmuş, demek ki çeviri var.

Defterin Ömrü: Kayıt Ne Zaman Siliniyor?

Yukarıdaki satırların başındaki sayılar tesadüf değil. TCP satırında 431997, UDP satırında 27 yazıyor. Bunlar o kaydın kaç saniye sonra silineceğini gösteren geri sayımlar.

Fark büyük ve sebebi mantıklı. TCP’de bağlantının kurulduğu ve kapandığı bellidir, bu yüzden kurulmuş bir bağlantı için varsayılan ömür beş güne yakındır. UDP’de böyle bir işaret yoktur; çeviriyi yapan cihaz akışın bittiğini ancak sessizlikten anlayabilir, o yüzden sayaç otuz saniye civarında başlar ve her pakette sıfırlanır.

Metaforun burada söylediği şey de doğru: memurun defteri sonsuza kadar açık durmaz, eski satırlar bir süre sonra kapanır. Pratikte bunun karşılığı, uzun süre sessiz kalan bir bağlantının kenar cihazda sessizce unutulmasıdır. Oturumunuz kopmaz, hata almazsınız; yalnızca bir sonraki paket geldiğinde deftere bakılır, satır bulunamaz ve paket düşer. Uzun süre boşta kalan VPN ve SSH oturumlarının “durduk yere” kopmasının en yaygın sebebi budur, ve keepalive ayarlarının varlık sebebi de tam olarak bu satırı diri tutmaktır.

PAT Nedir? Tek Adres, Binlerce Bağlantı

Buraya kadar tek bir iç cihazı izledik. Gerçek hayatta o adresin arkasında yüzlerce cihaz var ve hepsi aynı anda dışarı çıkıyor. Tek bir pasaport numarası bunların hepsine nasıl yetiyor?

Yetmiyor. Yeten şey pasaport numarası değil, onun yanına yazılan sıra numarası. Adresle birlikte port numarasını da çeviren bu biçime PAT (Port Address Translation) denir ve bugün ev ile ofis ağlarında gördüğünüz NAT’ın neredeyse tamamı budur.

Aynı İç Port, İki Ayrı Bağlantı: NAT Hangisini Değiştirir?

Ders kitaplarının bu konuda verdiği cevap nettir: PAT kaynak portunu değiştirir. Bunu sınamak için iki ayrı iç ağdan, birebir aynı kaynak porttan (40000), aynı hedefe aynı anda bağlanıyoruz.

ip netns exec ic1 nc -p 40000 -w 6 192.168.1.10 389 &
ip netns exec ic2 nc -p 40000 -w 6 192.168.1.10 389 &

Dış arayüzde görünen:

21:58:35.242021 IP 192.168.1.15.40000 > 192.168.1.10.389: Flags [S], seq 380829920
21:58:35.242872 IP 192.168.1.15.50048 > 192.168.1.10.389: Flags [S], seq 2172617502

Cevap beklenenden ince çıktı. İki bağlantı da aynı porttan çıkmıştı; dışarıda biri 40000 olarak kaldı, diğeri 50048 oldu.

Çeviri tablosu da bunu doğruluyor:

tcp 6 431997 ESTABLISHED src=10.10.1.2 dst=192.168.1.10 sport=40000 dport=389
    src=192.168.1.10 dst=192.168.1.15 sport=389 dport=40000 [ASSURED]
tcp 6 431997 ESTABLISHED src=10.10.2.2 dst=192.168.1.10 sport=40000 dport=389
    src=192.168.1.10 dst=192.168.1.15 sport=389 dport=50048 [ASSURED]

İki satırın giden demeti neredeyse aynı, yalnız iç adresleri farklı. Dönüş demetlerinde ise portlar ayrışmış. Yani PAT portu her zaman değiştirmiyor; değiştirmek zorunda kaldığında değiştiriyor. İlk bağlantı portunu koruyabildi çünkü o port dışarıda boştu. İkincisi geldiğinde aynı port kullanımdaydı ve çeviri kaçınılmaz hale geldi.

Bu davranışın kendisi çeviriyi yapan yazılıma bağlıdır ve ölçüm Linux netfilter üzerinde alındı; başka bir üreticinin cihazı portu her koşulda değiştirmeyi tercih edebilir. Değişmeyen kural şu: dışarıdaki adres ile port çiftinin aynı anda iki bağlantıya ait olması imkânsızdır, çünkü dönüş paketini ayırt edecek başka bir bilgi yoktur.

Sınır kapısında karşılığı da bu. Aynı pasaportla çıkan iki kişiye aynı sıra numarası verilemez; verilseydi memur dönen cevabı hangisine vereceğini bilemezdi. Numarayı benzersiz kılan şey pasaport değil, pasaportla numaranın birlikteliğidir.

5651 Neden Portu da İstiyor?

Bu mekanizmanın doğrudan hukuki bir sonucu var ve sahada en çok atlanan nokta orası.

5651 log yönetimi rehberimizde anlattığımız gibi, kayıt tutma yükümlülüğü yalnızca “hangi dış IP?” bilgisini değil, o çıkışın hangi porta eşlendiğini de kapsar. Sebebi yukarıdaki tabloda duruyor: tek bir dış adresin arkasında aynı anda binlerce cihaz olabilir, dolayısıyla dış adres tek başına kimseyi işaret etmez. Bir bağlantıyı geriye dönük olarak tek bir cihaza bağlayabilmenizi sağlayan şey adres değil, adres ile portun ve zamanın birlikte kaydedilmesidir.

Portsuz tutulan bir kayıt, dosyada var görünür ve soruldugunda hiçbir şey söyleyemez. Defterin yalnız pasaport numarasını yazıp sıra numarasını atlaması gibi.

SNAT ve DNAT Farkı Nedir?

Buraya kadarki her örnek içeriden dışarı gitti. Çevrilen şey hep kaynak adresti ve bunun adı SNAT (Source NAT). MASQUERADE de SNAT’ın, dış adresin arayüzden otomatik alındığı özel bir biçimidir.

Ters yön ayrı bir karardır ve adı DNAT (Destination NAT). Burada dışarıdan gelen bir paketin hedef adresi değiştirilir, yani dış dünyadan gelen bir isteğin içeride hangi sunucuya ulaşacağı belirlenir.

İkisi arasındaki en önemli fark teknik değil, kavramsal: SNAT ile DNAT aynı cihazda birbirinden bağımsızdır ve farklı adreslere bağlanabilir. Çıkarken gösterdiğiniz pasaport ile size ulaşmak için kullanılan adres aynı olmak zorunda değildir. Bu cümle kulağa teorik geliyor, ama sahada doğrudan bir tasarım aracı.

Çıkış ile Girişi Ayrı Hatlara Bağlamak

Bunun mümkün olmasının sebebi tam olarak yukarıdaki ayrımdır. Çıkış yönü SNAT’tır ve nereye bağlanacağı bir policy kararıdır; giriş yönü DNAT’tır ve o da ayrı bir policy kararıdır. İkisini aynı adrese bağlamak bir zorunluluk değil, yalnızca varsayılan.

Port Yönlendirme Nedir? NAT Kuralı Nasıl Yazılır?

Günlük dilde port yönlendirme denen şey, DNAT’ın en yaygın biçimidir. Dışarıdan belirli bir porta gelen trafiğin, içerideki belirli bir cihaza ve porta iletilmesidir.

iptables -t nat -A PREROUTING -d 192.168.1.15 -p tcp --dport 8080 \
  -j DNAT --to-destination 10.10.1.2:8080

Kuralın okunuşu şu: dışarıdan 192.168.1.15 adresinin 8080 portuna gelen TCP trafiğini al, hedefini 10.10.1.2:8080 yap. Sınır kapısında karşılığı, kapıdaki memura verilmiş bir talimattır: “şu numaraya gelen ziyaretçiyi şu daireye yönlendir.”

Buradaki asimetri, makalenin en pratik cümlesi olabilir. Çıkış için kural yazmanıza gerek yoktur, giriş için yazmak zorundasınız. Çıkışta kayıt paket çıkarken kendiliğinden oluşur; girişte ise oluşacak bir kayıt yoktur, çünkü içeriden kimse bir şey istememiştir. Memurun defterinde o ziyaretçiye ait bir satır yoktur ve kimi çağıracağını bilemez.

Aynı asimetri FortiGate arayüzünde de görünür. Sanal IP (Virtual IP) adresi çevirir, ama trafiğe izin veren bir kural yazılmadan dışarıdan gelen istek cevap alamaz. Bunu ve kuraldaki kaynak NAT’ı açık kalınca iç sunucunun bütün ziyaretçileri firewall’un iç adresinden gördüğünü FortiGate kullanım rehberimizde ölçtüm.

Bir de port yönlendirmenin az konuşulan biçimi var: tek bir portu içeri vermek zorunda değilsiniz. Elinizde birden fazla genel adres varsa, bir adresin tamamını tek bir servise ayırabilirsiniz. Yukarıdaki tabloda statik NAT dediğimiz şeyin sahadaki karşılığı budur ve bir geçiş sırasında kıymeti şöyle anlaşılıyor.

Çift NAT ve CGNAT Nedir?

Şimdiye kadar tek bir sınır kapısı vardı. Gerçek ağlarda çoğu zaman iki tane oluyor: servis sağlayıcının modemi bir çeviri yapıyor, kurumun kendi güvenlik duvarı bir çeviri daha yapıyor. Trafiğin arka arkaya iki kez çevrilmesine çift NAT denir.

Metafora oturttuğumuzda anlaşılması kolaylaşıyor: bir transit ülkeden geçiyorsunuz. Kendi ülkenizin kapısında bir pasaport alıyorsunuz, transit ülkenin kapısında o pasaport da yetmiyor ve size ikinci bir belge veriliyor. Varış noktasındaki kişi yalnızca ikinci belgeyi görüyor ve sizin kim olduğunuza dair hiçbir fikri yok.

Lab: İki Çeviriyi Arka Arkaya Koymak

Bunu göstermek için araya bir katman daha koyduk. Artık üç seviye var: en içteki ağ, ortadaki geçit ve dıştaki geçit. İkisi de kendi çevirisini yapıyor.

# Ortadaki katman kendi cevirisini yapiyor
ip netns exec mid iptables -t nat -A POSTROUTING -s 10.10.1.0/24 -o veth-mo -j MASQUERADE
# Distaki katman bir kez daha ceviriyor
iptables -t nat -A POSTROUTING -s 10.30.0.0/24 -o ens33 -j MASQUERADE

Aynı bağlantıyı üç noktada birden dinlediğimizde adresin iki kez değiştiği görünüyor:

KATMAN 1, en icteki agda (hic cevrilmemis):
10.10.1.2.40000 > 192.168.1.10.389: Flags [S], seq 2596541764

KATMAN 2, iki gecit arasinda (bir kez cevrilmis):
10.30.0.2.40000 > 192.168.1.10.389: Flags [S], seq 2596541764

KATMAN 3, dis arayuzde (iki kez cevrilmis):
192.168.1.15.40000 > 192.168.1.10.389: Flags [S], seq 2596541764

Üç satırın sıra numarası da (seq 2596541764) birebir aynı, yani bu tek bir paketin üç ayrı yerdeki görüntüsü. Kaynak adres her katmanda bir kez değişmiş.

Ve artık iki ayrı defter var:

Ortadaki gecidin defteri:
tcp ESTABLISHED src=10.10.1.2 dst=192.168.1.10 sport=40000 dport=389
    src=192.168.1.10 dst=10.30.0.2 sport=389 dport=40000 [ASSURED]

Distaki gecidin defteri:
tcp ESTABLISHED src=10.30.0.2 dst=192.168.1.10 sport=40000 dport=389
    src=192.168.1.10 dst=192.168.1.15 sport=389 dport=40000 [ASSURED]

Her defter yalnızca kendi katmanını biliyor. Dıştaki geçit 10.10.1.2 diye bir adres olduğundan habersiz; onun bildiği tek iç adres 10.30.0.2.

Tek Kural Neden Yetmiyor?

Çift NAT’ın neden arıza ürettiği tam burada görünüyor. İçerideki bir sunucuya dışarıdan erişmek isteyelim: en içteki ağda 8080 portunu dinleyen bir servis açtık ve yalnızca dıştaki geçide bir DNAT kuralı yazdık.

Dışarıdan, ağdaki gerçek bir Windows makinesinden denediğimizde:

Test-NetConnection -ComputerName 192.168.1.15 -Port 8080

PingSucceeded    : True
TcpTestSucceeded : False

Belirti tam da sahada duyduğunuz cümle: makine ayakta, ping cevap veriyor, ama servise ulaşılamıyor. Bu iki satırın yan yana durması önemli, çünkü PingSucceeded : True çoğu zaman “ağ çalışıyor” diye okunuyor ve teşhis yanlış yere gidiyor.

Sebep, dıştaki geçidin paketi ortadaki geçide teslim etmesi ama ortadaki geçitte o paketi karşılayacak bir kuralın olmaması. İkinci katmana da kuralı yazdığımızda:

ip netns exec mid iptables -t nat -A PREROUTING -d 10.30.0.2 -p tcp --dport 8080 \
  -j DNAT --to-destination 10.10.1.2:8080

PingSucceeded    : True
TcpTestSucceeded : True

Bu arada gelen bağlantının defterlerine bakmak da öğretici:

Distaki gecit:  src=192.168.1.224 dst=192.168.1.15 dport=8080
                src=10.30.0.2 dst=192.168.1.224 sport=8080
Ortadaki gecit: src=192.168.1.224 dst=10.30.0.2 dport=8080
                src=10.10.1.2 dst=192.168.1.224 sport=8080

Hedef adres iki kez değişmiş (192.168.1.15 sonra 10.30.0.2 sonra 10.10.1.2), ama kaynak adres hiç değişmemiş: 192.168.1.224 her iki defterde de aynı. Yani DNAT istemciyi gizlemez. Gizleyen SNAT’tır, ve ikisi bağımsız olduğu için içerideki sunucu gerçek istemci adresini görmeye devam eder.

Çift NAT’tan kurtulmanın yolu modemi köprü moduna almaktır: modem çevirmeyi bırakır, servis sağlayıcıyla oturumu firewall kurar ve dış adres doğrudan firewall’a gelir. Modemin ve firewall’un bu iki çalışma biçimini PPPoE nedir yazımızda şemasıyla anlattık.

CGNAT: Çeviriyi Yapan Siz Değilseniz

CGNAT (Carrier Grade NAT), çift NAT’ın sizin kontrolünüzde olmayan biçimidir. Servis sağlayıcı, IPv4 adres kıtlığı yüzünden tek bir genel adresi yüzlerce aboneye paylaştırır; siz modeminize baktığınızda genel bir adres göremez, kendinize ayrılmış özel bir adres görürsünüz.

Teknik olarak yukarıda ölçtüğümüz düzenin aynısıdır ve tek farkı belirleyicidir: ikinci katman sizin değil. Yani içerideki bir sunucuya dışarıdan erişim gerektiğinde ihtiyacınız olan ikinci kuralı yazamazsınız, çünkü o cihaza erişiminiz yok. Port yönlendirme yaptığınız halde çalışmıyorsa ve hattınız CGNAT’lıysa, sorun sizin yapılandırmanızda değildir.

Pratik sonuç: uzaktan erişim, kamera sistemi, şubeler arası bağlantı ya da site-to-site VPN gerektiren her kurumsal senaryoda hattın gerçek genel adres taşıyıp taşımadığı, sözleşme aşamasında sorulacak bir sorudur. Sonradan çözmek genelde tarife değişikliği demektir.

IPv6 Gelince NAT Bitecek mi?

CGNAT bir tercih değil, bir kıtlık belirtisi: servis sağlayıcının dağıtacak IPv4 adresi kalmadığı için var. O yüzden akla gelen ilk soru şu oluyor: adresler bittiği için doğduysa, adresler bitmeyince ortadan kalkar mı?

Adres çevirisinin varlık sebebi açısından cevap evet. IPv6 adres alanı, her cihaza kendi genel adresini verecek kadar geniş; kıtlık diye bir sorun kalmıyor, dolayısıyla “birçok cihazı tek adresin arkasına sıkıştırma” ihtiyacı da kalmıyor. IPv6 zaten uçtan uca adreslenebilirlik üzerine tasarlandı.

Ama sahada NAT’a atfedilen ikinci bir iş var ve asıl karışıklık orada. Çoğu kişi NAT’ı bir güvenlik katmanı sanıyor: “içerideki cihazlar dışarıdan görünmüyor.” Bu makale boyunca ölçtüğümüz mekanizma bunun neden yanlış bir okuma olduğunu gösteriyor. İçeri gelen bağlantıyı durduran şey NAT’ın kendisi değil, defterde o bağlantıya ait bir satırın bulunmamasıydı. Yani koruma bir tasarım değil, çevirinin yan etkisiydi.

IPv6’da o yan etki ortadan kalkıyor, çünkü çevrilecek bir şey yok. Bu, her cihazın dışarıdan erişilebilir olacağı anlamına gelmiyor: adresin genel olması ile o adrese ulaşılabilmesi ayrı şeyler. Gelen bağlantıyı durduran iş artık açıkça güvenlik duvarının işi ve durum bilgisi tutan bir kural setiyle yapılıyor. Ev tipi cihazların çoğu bunu varsayılan olarak zaten yapıyor; kurumsal tarafta ise bu, yazılması gereken bir kural haline geliyor.

Sınır kapısı benzetmesinde karşılığı temiz: IPv6’da herkesin kendi pasaportu var, ortak pasaport dağıtan masaya gerek kalmıyor. Ama kapıdaki görevli hâlâ orada duruyor ve kimin içeri gireceğine o karar veriyor. Masayı kaldırmak, kapıyı açmak değildir.

Pratikte geçiş kısmi ve uzun sürüyor. Ağların büyük çoğunluğu bir süre daha iki protokolü birlikte taşıyacak; IPv4 tarafı ayakta kaldığı sürece o taraftaki NAT da ayakta kalıyor. Yani NAT’ın yakın zamanda yazılımlardan silinen bir konu olmasını beklemeyin; bu makaledeki teşhis sırası, IPv4 hattınız olduğu sürece geçerli.

NAT Teşhisi: Sunucu Ayakta ama Dışarıdan Erişilmiyor

Sahada NAT kaynaklı arızaların büyük çoğunluğu tek bir cümleyle geliyor: “sunucu çalışıyor, içeriden giriyoruz, dışarıdan girilmiyor.” Metafora çevirirsek durum şu: kapıya bir ziyaretçi gelmiş, içeride aradığı kişi masasında oturuyor, ama memurun defterinde o ziyaretçiye ait hiçbir satır yok. Memur kötü niyetli değil, kimi çağıracağını bilmiyor. Teşhis de bu yüzden “sunucu ayakta mı?” sorusundan değil, “defterde bu bağlantının satırı var mı?” sorusundan ilerliyor.

Sırayı paketin izlediği yolun tersinden kurun, çünkü en pahalı hata en dıştaki cihaza bakmadan içeriye dalmaktır.

1. Servis gerçekten dinliyor mu? İçerideki makinede portun dinlemede olduğunu doğrulayın. Dinlemiyorsa NAT’ın hiçbir kuralı bunu kurtarmaz.
2. İçeriden, aynı ağdan erişiliyor mu? Erişiliyorsa sorun servis değil yol demektir.
3. Kaç katman çeviri var? Modem ve güvenlik duvarı ayrı cihazlarsa muhtemelen ikisi de çeviriyor. Her katman ayrı kural ister.
4. Kenar cihazın gerçek genel adresi var mı? Modem arayüzünde WAN adresi 10., 100.64. ya da 192.168. ile başlıyorsa hattınız CGNAT’lıdır ve dışarıdan erişim bu yapılandırmayla mümkün değildir.
5. Kural doğru yöne mi yazılmış? Çıkış kuralı (SNAT) yazıp giriş beklemek, sahada en sık görülen karışıklıktır.

Bu sırayı güvenlik duvarı kurulumu rehberimizdeki kural denetimiyle birlikte yürütmekte fayda var, çünkü bir paket çeviriyi geçse bile ayrıca izin kuralına takılabilir. Çeviri ile izin farklı iki karardır ve ikisi de olmadan bağlantı kurulmaz.

Hairpin NAT: İçeriden Kendi Dış Adresinize Gitmek

Özel bir durum var ve teşhisi en çok yanıltan o. İç ağdaki bir kullanıcı, içeride duran bir sunucuya dış adresi üzerinden erişmeye çalışıyor. Paket içeriden çıkıyor, kenar cihaza gidiyor ve oradan geri dönmesi gerekiyor. Bu geri dönüşe hairpin NAT ya da NAT loopback denir.

Mekanizma tarafındaki sorun şu: kenar cihazın bu paketi hem hedef hem kaynak yönünde çevirmesi gerekir. Yalnız hedefi çevirirse, içerideki sunucu cevabı doğrudan istemciye gönderir; istemci ise cevabı dış adresten beklediği için tanımadığı bir kaynaktan gelen paketi kabul etmez. Bağlantı, iki taraf da ayaktayken kurulmaz. Bazı cihazlar bu ikili çeviriyi hiç desteklemez, destekleyenlerde ise trafik gereksiz yere kenardan geçer.

Bu sorunun asıl çözümü NAT tarafında değil isim çözümü tarafındadır: iç kullanıcıya iç adresi döndürmek. Ayrıntısını ve kurulumunu DNS rehberimizde ve Active Directory DNS yapılandırması rehberimizde ele alıyoruz. Buradan alınacak not şu: bir kullanıcı “dışarıdan çalışıyor, içeriden çalışmıyor” diyorsa, önce ona hangi adresin döndüğüne bakın.

ISP Geçişinde Dış Kimlik Değişince

İkinci vaka, dış kimliğin bir varlık olduğunu ve yönetilmesi gerektiğini gösteriyor.

Bu ayrıntı atlansaydı, teknik olarak kusursuz bir geçiş kullanıcı tarafında toplu bir arıza gibi görünecekti. Sebebi makalenin başındaki cümlenin ta kendisi: dışarısı sizi iç adresinizle değil, kenardaki cihazın verdiği kimlikle tanır. Kenar cihaz değişirse o kimlik de değişir. Sınır kapısını başka bir şehre taşıdığınızda pasaport numaraları da değişir; önceden haber vermezseniz kimse içeri giremez.

Sonuç: NAT’ın Asıl Mekanizması Bağlantı Defteridir

NAT’ı “adresi değiştiren şey” diye özetlemek, işin kolay yarısını almaktır. Ölçümlerin gösterdiği asıl mekanizma defterdir: çeviriyi yapan cihaz her bağlantı için iki demet yazar, biri gidişi biri beklenen dönüşü tanımlar, ve dışarıdan gelen her paketi o ikinci demetle karşılaştırır. Kuralı sildiğimizde paketler yine dışarı çıktı; çıkamayan şey cevaptı.

Aynı defterin bir firewall’daki karşılığını, FortiGate’in oturum tablosundaki act=snat ve act=dnat satırlarıyla FortiGate Firewall NAT ayarı yazımızda gösterdim.

Üç madde pratikte en çok işe yarayanlar:

• Çıkış ile giriş ayrı kararlardır. SNAT ile DNAT aynı cihazda farklı adreslere bağlanabilir; sahadaki vakamızda çıkış yeni hatta, VPN eski hatta bırakıldı ve ikisi de kendi gerekçesiyle doğruydu.
• Çeviri kaç katmandaysa giriş kuralı da o kadar katmanda olmalı. Çıkış yönü kendiliğinden zincirlenir, giriş yönü zincirlenmez. Çift NAT arızalarının neredeyse tamamı bu tek cümleye bakar.
• Dış kimlik yönetilen bir varlıktır. Kenar cihaz değişince değişir ve ona bağlı olan herkesin önceden haberi olması gerekir.

Bir de metaforun yalan söylediği yeri yazalım, çünkü orada mekanizmanın kendisi duruyor. Gerçek pasaport sizindir ve sizinle birlikte döner; NAT’ın pasaportu kapıda kalır, dışarısı adınızı hiç öğrenmez. Dahası memurun defteri kalıcı değildir. Bir süre sessiz kalan satır silinir ve o bağlantı, iki taraf da ayaktayken, kimse bir şey yapmadan kopar.

NAT bu makalede tek başına durmuyor: adresin ne olduğu, portun bir bağlantıyı nasıl tanımladığı ve ismin adrese nasıl çevrildiği aynı zincirin halkaları. Zincirin tamamı ağ protokolleri rehberimizde bir arada duruyor.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn