Kurumsal Ağda NAT Tasarımı: PAT, Statik NAT, Hairpin ve Çakışma

Şubeye giden trafik tünele girmiyor, IP telefonda ses tek yönlü, bazı kullanıcılar şirketin kendi web sitesini içeriden açamıyor. Üç ayrı arıza gibi görünür; üçünün de kökü çoğu zaman NAT tasarımıdır. Kurumsal ağlarda NAT genellikle “internete çıkış için açılan bir ayar” sayılır, oysa adres çevirisi yayınlanan servislerin erişilebilirliğini, VoIP kalitesini, şirket birleşmelerinde ağların bağlanabilmesini ve olay incelemede bir bağlantının hangi cihazdan geldiğinin bulunabilmesini doğrudan belirler. Aşağıda NAT türlerini, PAT port tükenmesini, hairpin NAT ile split DNS seçimini, çakışan alt ağlar için iki yönlü NAT’ı ve NAT’ın uygulama protokollerine etkisini saha senaryolarıyla anlatıyoruz.

NAT türleri ve kullanım alanları

Klasik NAT davranışı RFC 3022’de tanımlanır. Kurumsal ağda karşılaşılan türler ve üreticilerin bunlar için kullandığı farklı terimler:

Cisco IOS’ta kullanıcı çıkışı ip nat inside source ... overload, Linux’ta masquerade veya snat, FortiGate’te firewall politikasındaki NAT ve IP pool ile, yayınlanan servisler ise VIP nesnesiyle yapılandırılır. Terimler farklıdır. Tasarım soruları aynıdır.

PAT ve port tükenmesi

PAT, aynı genel IP’yi kullanan oturumları kaynak port numarasıyla ayırt eder. Bir genel IP adresinde protokol başına kullanılabilecek port sayısı 1024–65535 aralığıyla yaklaşık 64 bindir. Belirleyici olan kullanıcı sayısı değil, eşzamanlı oturum sayısıdır: tarayıcılar, bulut senkronizasyon istemcileri ve güncelleme servisleri aynı anda çok sayıda bağlantı açar.

Örnek hesap: 1.500 cihazlı bir ağda yoğun saatlerde cihaz başına ortalama 60 eşzamanlı TCP/UDP oturumu ölçülmüşse toplam yaklaşık 90 bin oturum eder; tek genel IP bu yükü taşıyamaz, en az iki, büyüme payıyla üç adreslik bir PAT havuzu gerekir. Gerçek değer ağdan ağa çok değiştiği için hesabı ölçüme dayandırın.

Port tükenmesi sinsi bir arızadır, çünkü belirtileri rastgele ve geçicidir: bazı sayfalar yüklenmez, VPN istemcisi ara ara bağlanamaz, bulut uygulamaları “ağ hatası” verir, beş dakika sonra her şey düzelir. Kullanıcı “internet gidip geliyor” der; hat sağlam, sorun NAT tablosundadır. Kontrol için NAT istatistiklerini ve aktif çeviri sayısını izleyin, zaman aşımı değerlerini gözden geçirin (özellikle uzun UDP zaman aşımları gereksiz kayıt biriktirir). Endpoint-independent mapping davranışı (RFC 4787) uygulama uyumluluğu için önerilir ama portların hedefler arasında yeniden kullanımını sınırlar; havuz boyutlandırmasında muhafazakâr olun.

Aşağıdaki Cisco IOS XE örneği, iki adreslik bir PAT havuzu ve tek bir statik port yönlendirmesi tanımlar (adresler dokümantasyon aralığından):

interface GigabitEthernet0/0/0
 description WAN
 ip address 203.0.113.2 255.255.255.248
 ip nat outside
!
interface GigabitEthernet0/0/1
 description LAN
 ip address 10.10.0.1 255.255.0.0
 ip nat inside
!
ip access-list standard NAT-ICERIDEN
 permit 10.10.0.0 0.0.255.255
!
ip nat pool PAT-HAVUZ 203.0.113.3 203.0.113.4 prefix-length 29
ip nat inside source list NAT-ICERIDEN pool PAT-HAVUZ overload
ip nat inside source static tcp 10.10.20.15 443 203.0.113.5 443 extendable

Doğrulama için show ip nat translations aktif çevirileri, show ip nat statistics toplam çeviri sayısını ve havuz kullanımını gösterir. NAT çevirilerini merkezi olarak loglayın: olay incelemede bir genel IP ve port bilgisinden iç cihaza ulaşmanın tek yolu budur. Log yoksa iz de yoktur. Log saklama yükümlülüklerini kurumun hukuk birimiyle teyit edin.

Statik NAT ve port yönlendirme

Dışarıdan erişilecek servisler için iki yaklaşım var. Statik 1:1 NAT, bir iç sunucuya tüm portlarıyla ayrı bir genel adres ayırır; hangi portların açık olacağını firewall politikası belirler. Port yönlendirme ise tek genel adresin farklı portlarını farklı iç sunuculara dağıtır ve genel adres sayısı kısıtlıyken tercih edilir.

Tasarımda sahada en sık atlanan noktalar:

• Yayınlanan sunucunun giden trafiği (örneğin e-posta sunucusunun SMTP çıkışı) aynı genel adresten çıkmalı; aksi halde ters DNS ve SPF kayıtlarıyla tutarsızlık oluşur ve giden e-postalar karşı tarafta reddedilebilir. Statik NAT bunu kendiliğinden sağlar, port yönlendirmede ayrı kaynak NAT kuralı gerekir.
• Çift hatlı yapıda servis yalnızca bir operatörün IP’sine bağlıysa o hat düştüğünde servis erişilemez; bu durumun seçenekleri çift internet hattı yazısında, operatörden bağımsız kalıcı çözüm ise kurumsal BGP multihoming yazısında anlatılıyor.
• Yayınlanan sunucuları kullanıcı VLAN’larında değil, ayrı bir DMZ segmentinde tutun.

NAT hairpin ve split DNS alternatifi

İç ağdaki bir kullanıcı şirketin kendi web sunucusuna genel alan adıyla eriştiğinde DNS ona genel IP’yi döndürür. Paket firewall’a gider, hedef NAT ile iç sunucuya yönlendirilir. Kullanıcı ile sunucu aynı alt ağdaysa sunucu, kaynak adresi yerel olduğu için yanıtı firewall’u atlayıp doğrudan kullanıcıya gönderir; kullanıcı yanıtı beklemediği bir adresten aldığı için bağlantı kurulamaz. Sunucu ayrı bir DMZ segmentindeyse yanıt zaten firewall’dan geçer ve çoğu firewall’da iç arayüze uygulanan hedef NAT yeterlidir; asıl sorun aynı segment durumudur. Hairpin NAT (NAT loopback, U-turn) bu durumda hedefle birlikte kaynağı da firewall’un adresine çevirerek yanıtın firewall üzerinden dönmesini sağlar.

Hairpin çalışır, ama iç trafiği gereksiz yere firewall’dan geçirir ve sunucu loglarında tüm iç kullanıcılar tek bir adresten geliyormuş gibi görünür. Daha temiz alternatif split DNS’tir: iç çözümleyici aynı ad için iç IP’yi, dış DNS genel IP’yi döndürür. Split DNS tasarımının ayrıntıları kurumsal DNS mimarisi yazısında anlatılıyor.

Çakışan subnetler: iki yönlü NAT

Şirket birleşmeleri, iş ortağı bağlantıları veya makine üreticilerinin sabit adresli sistemleri, aynı alt ağın iki tarafta da kullanıldığı durumları sık doğurur. İki taraf da 192.168.1.0/24 kullanıyorsa, yerel bir cihaz karşı taraftaki 192.168.1.10’a paket gönderdiğinde paket kendi ağında kalır. Tünel ayakta olsa bile. Çözüm, her tarafın diğerine kendi ağını farklı bir “görünen” alt ağ olarak sunmasıdır: A tarafı kendini 10.200.1.0/24, B tarafı kendini 10.201.1.0/24 olarak gösterir. A’daki kullanıcı B’deki sunucuya 10.201.1.10 adresiyle erişir.

Cisco ASA (8.3 ve sonrası) sözdiziminde A tarafındaki kural şöyle yazılır; B tarafında aynı yapı adresler ters çevrilerek tanımlanır:

object network A-GERCEK
 subnet 192.168.1.0 255.255.255.0
object network A-GORUNEN
 subnet 10.200.1.0 255.255.255.0
object network B-GORUNEN
 subnet 10.201.1.0 255.255.255.0
!
nat (inside,outside) source static A-GERCEK A-GORUNEN destination static B-GORUNEN B-GORUNEN

Bu yapıda VPN trafik seçicileri ve routing gerçek değil görünen alt ağlarla tanımlanır. DNS kayıtları, uygulama yapılandırmalarındaki sabit IP’ler ve firewall nesneleri de görünen adreslere göre güncellenmeli. Sahada en çok vakit kaybettiren kısım budur: NAT kuralı doğrudur, ama bir uygulamanın yapılandırma dosyasında eski gerçek IP kalmıştır. Tünel tarafındaki tasarım için site-to-site IPsec VPN tasarımı yazısına bakabilirsiniz. İki yönlü NAT kalıcı çözüm değil, geçiş aracıdır; uzun vadede adres planını yeniden düzenlemeyi hedefleyin.

NAT’ın SIP ve diğer protokollere etkisi

NAT yalnızca IP ve port başlıklarını değiştirir; uygulama verisinin içine gömülü adresler olduğu gibi kalır. Bu bazı protokolleri doğrudan bozar:

• SIP: SIP mesajları (Via, Contact başlıkları ve SDP gövdesi) iç IP adreslerini taşır. Karşı taraf sesi bu iç adrese göndermeye çalışınca tek yönlü ses oluşur. Firewall’daki SIP ALG bu adresleri yeniden yazmayı dener; santral veya SBC de NAT düzeltmesi yapıyorsa iki müdahale çakışır. Güvenilir yöntem: santral veya SBC tarafında NAT farkındalığını yapılandırmak, rport (RFC 3581) ve simetrik RTP kullanmak, kayıt ve keepalive aralığını firewall’un UDP zaman aşımından kısa tutmak ve ALG’yi buna göre kapatmak. Tek yönlü seste ilk bakılacak yer SDP içindeki adrestir.
• FTP: Aktif modda istemci, veri bağlantısı için kendi IP ve portunu PORT komutuyla bildirir; NAT arkasında ALG veya inspection yoksa çalışmaz. Pasif mod (PASV) çoğu durumu çözer, ama sunucu NAT arkasındaysa sunucuyu kendi genel adresini bildirecek şekilde yapılandırmak gerekir.
• IPsec: AH, başlık bütünlüğünü koruduğu için NAT ile çalışmaz. ESP, NAT-T ile UDP 4500 içinde taşınarak NAT’tan geçer.
• Operatör CGNAT’ı: Bazı hatlarda (özellikle hücresel) operatör RFC 6598 aralığından (100.64.0.0/10) adres verip kendi tarafında ikinci bir NAT uygular; bu durumda gelen bağlantı kabul edilemez. Konu 4G/5G yedek internet hattı yazısında işleniyor.

Senaryo bazlı tasarım tablosu

Son satır, sahada en sık gördüğümüz NAT hatasını işaret eder: firewall’da genel PAT kuralı VPN kuralından önce eşleşirse şubeye gidecek trafik genel IP’ye çevrilir ve tünele hiç girmez. Tünel “up” görünür, sayaçlar artmaz. NAT kural sırasını her yeni tünelde kontrol edin. Adresleme ve segmentasyon planı için VLAN, routing ve ağ segmentasyonu, genel adres ve hat tarafı için internet hat yönetimi sayfalarına bakabilirsiniz.

Sık sorulan sorular

Tek genel IP adresiyle kaç kullanıcı internete çıkabilir?

Sınır kullanıcı sayısı değil, eşzamanlı oturum sayısıdır. Bir genel IP adresi protokol başına 1024 üzerindeki yaklaşık 64 bin port ile sınırlıdır; uygulamanın port yeniden kullanım davranışına göre pratik değer değişir. Eşzamanlı oturum sayısını NAT istatistiklerinden ölçün ve PAT havuzunu buna göre boyutlandırın.

SIP ALG kapatılmalı mı?

IP telefonlar, santral veya SBC NAT’ı kendisi yönetiyorsa (rport, STUN, kayıt yenileme ve simetrik RTP ile) SIP ALG çoğu durumda kapatılmalıdır; ALG’nin SIP mesajlarını yeniden yazması tek yönlü ses ve kayıt kopması gibi sorunlara yol açabilir. Kararı operatör ve santral üreticisinin önerisiyle birlikte, test ederek verin.

NAT bir güvenlik önlemi midir?

NAT, iç adresleri gizlediği ve istenmeyen gelen bağlantılar eşleşecek bir çeviri kaydı bulamadığı için yan etki olarak koruma sağlar; ama bir güvenlik kontrolü olarak tasarlanmamıştır. Erişim denetimini firewall politikalarıyla yapın, NAT’ı yalnızca adresleme ihtiyacına göre tasarlayın.

IPv6’ya geçince NAT gerekmeyecek mi?

IPv6’da her cihaza küresel adres verilebildiği için adres tasarrufu amaçlı NAT gerekmez; güvenlik firewall ile sağlanır. Operatör değişiminde iç adreslerin korunması gibi özel ihtiyaçlar için NPTv6 (RFC 6296) vardır ama kullanımı istisnaidir. Geçiş süresince IPv4 tarafındaki NAT tasarımı geçerliliğini korur.