Cem Kemal Erbaş Network, Siber Güvenlik ve Teknik Rehberler
Route var.
Interface up/up.
Gateway’e ping atılabiliyor.
Ama kullanıcı internete çıkamıyor.
İlk şüphelilerden biri doğal olarak:
“NAT çalışmıyor.”
oluyor.
Cisco IOS ve IOS XE ortamlarında gerçekten de küçük bir NAT konfigürasyon hatası bütün internet erişimini kesebilir. Ancak production troubleshooting sırasında doğrudan NAT satırlarını değiştirmeye başlamak çoğu zaman en doğru yaklaşım değildir.
Çünkü NAT’ın çalışabilmesi için yalnızca:
ip nat inside source ...konfigürasyonunun bulunması yeterli değildir.
Interface rolleri, NAT classification ACL’si, route, translation table, return path ve bazı durumlarda CEF/forwarding davranışının da doğru olması gerekir.
Bu nedenle Cisco NAT troubleshooting’e bir packet-flow problemi olarak yaklaşmak çok daha sağlıklıdır.
Cisco NAT nasıl çalışır?
En yaygın kurumsal senaryoyu düşünelim.
İç ağdaki client:
10.10.10.25adresine sahip.
Router’ın dış interface’inde ise:
203.0.113.10public IP adresi bulunuyor.
Amaç:
10.10.10.25
↓
Cisco Router
↓
NAT / PAT
↓
203.0.113.10
↓
Internetşeklinde internet erişimi sağlamaktır.
Cisco’da interface üzerinden PAT/overload için tipik yapı şuna benzer:
access-list 10 permit 10.10.10.0 0.0.0.255
ip nat inside source list 10 interface GigabitEthernet0/1 overload
interface GigabitEthernet0/0
ip nat inside
interface GigabitEthernet0/1
ip nat outsideCisco IOS XE dokümantasyonu, overload kullanıldığında birden fazla inside host’un aynı global adresi port numaralarıyla ayrıştırarak paylaşabildiğini ve NAT’a tabi olacak kaynakların ACL ile seçilebildiğini belirtir. Cisco
NAT Overload — PAT nedir?
Bir kurumda yüzlerce client bulunduğunu düşünelim.
Her client’a ayrı public IPv4 adresi vermek yerine tek public IP kullanılabilir:
10.10.10.25:50231
10.10.10.26:53010
10.10.10.27:49155
↓
PAT
↓
203.0.113.10:farklı-portlarCisco terminolojisinde bu yapı genellikle NAT overload olarak geçer ve pratikte Port Address Translation — PAT davranışı sağlar.
Örneğin:
ip nat inside source list 10 interface GigabitEthernet0/1 overloadkomutundaki overload, birden fazla internal adresin aynı global/interface IP’sini TCP veya UDP port farklılıklarıyla kullanabilmesine olanak sağlar. Cisco
İlk kontrol: NAT translation gerçekten oluşuyor mu?
Troubleshooting sırasında ilk bakılabilecek en değerli komutlardan biri:
show ip nat translationskomutudur.
Cisco IOS XE üzerinde bu komut aktif NAT translation kayıtlarını gösterir. Daha ayrıntılı bilgi gerektiğinde:
show ip nat translations verbosekullanılabilir. Cisco
Örnek bir çıktı şöyle görünebilir:
Pro Inside global Inside local Outside local Outside global
tcp 203.0.113.10:49101 10.10.10.25:49101 8.8.8.8:443 8.8.8.8:443Buradaki en önemli iki alan:
Inside Local = 10.10.10.25
Inside Global = 203.0.113.10şeklindedir.
Bu, router’ın internal client’ın adresini public IP’ye çevirdiğini gösterir.
Cisco’nun NAT terminolojisinde Inside Local, içeride kullanılan host adresini; Inside Global ise aynı inside host’un dış dünyaya göründüğü global adresi ifade eder. Cisco
Inside Local, Inside Global, Outside Local ve Outside Global nedir?
show ip nat translations çıktısını doğru okuyabilmek NAT troubleshooting için oldukça önemlidir.
| Alan | Anlamı |
|---|---|
| Inside Local | Inside host’un içeride kullandığı adres |
| Inside Global | Inside host’un outside network’e göründüğü translated adres |
| Outside Local | Outside host’un inside taraftan görülen adresi |
| Outside Global | Outside host’un kendi global adresi |
Basit internet çıkışı senaryolarında Outside Local ve Outside Global çoğu zaman aynı görünür.
Bu kavramlar özellikle daha karmaşık inside/outside NAT yapılarında çok daha önemli hale gelir. Cisco da NAT terminolojisini tam olarak bu dört adres tipi üzerinden tanımlar. Cisco
Translation oluşmuyorsa ne anlama gelir?
Client trafik üretiyor fakat:
show ip nat translationsçıktısında ilgili host için hiçbir dynamic translation oluşmuyorsa NAT işlemine giden zincirin daha erken aşamalarına bakmak gerekir.
Örneğin NAT’a tabi olacak kaynak subnet yanlış yazılmış olabilir.
Şöyle olması gerekirken:
access-list 10 permit 10.10.10.0 0.0.0.255yanlışlıkla:
access-list 10 permit 10.20.10.0 0.0.0.255girildiyse 10.10.10.25 NAT classification’a hiç eşleşmez.
Sonuç:
Trafik var ama translation yok.
NAT ACL’si doğru trafiği seçiyor mu?
Kontrol için:
show access-listsveya platform/sürüm desteğine göre:
show ip access-listskullanılabilir.
Burada önemli bir kavramsal ayrım vardır.
Şu konfigürasyondaki:
access-list 10 permit 10.10.10.0 0.0.0.255
ip nat inside source list 10 interface GigabitEthernet0/1 overloadACL temel olarak hangi source adreslerin NAT’a tabi tutulacağını seçmektedir.
Yani bu kullanım bağlamında permit:
“Bu trafiği güvenlik açısından izinli kabul et.”
anlamına değil:
“Bu kaynak NAT işlemine dahil olsun.”
anlamına gelir.
Cisco da NAT için kullanılan ACL’nin yalnızca translate edilmesi gereken adresleri permit etmesi gerektiğini ve aşırı geniş ACL’lerin beklenmeyen sonuçlar yaratabileceğini belirtiyor. Cisco
Bu ayrım özellikle troubleshooting sırasında önemlidir.
Çünkü NAT ACL ile interface üzerinde uygulanan packet-filter ACL aynı amaçla kullanılmayabilir.
NAT interface rolleri doğru mu?
Basit ama production ortamlarında şaşırtıcı derecede sık görülen hata:
inside ve outside rollerinin yanlış atanmasıdır.
Tipik yapı:
interface GigabitEthernet0/0
description LAN
ip address 10.10.10.1 255.255.255.0
ip nat insideve:
interface GigabitEthernet0/1
description INTERNET
ip address 203.0.113.10 255.255.255.252
ip nat outsideşeklindedir.
Cisco’nun güncel IOS XE NAT rehberinde de internal interface ip nat inside, dış ağa bağlı interface ise ip nat outside ile işaretlenir. Cisco
Konfigürasyonun yalnızca:
ip nat inside source ...satırına bakıp interface rollerini kontrol etmemek sık yapılan troubleshooting hatalarından biridir.
show ip nat statistics bize ne anlatır?
NAT’ın genel durumunu görmek için:
show ip nat statisticsoldukça faydalıdır.
Bu çıktı platform ve IOS/IOS XE sürümüne göre bazı ayrıntılarda değişebilse de NAT translation kullanımı, mappings ve ilgili NAT durumları hakkında hızlı görünürlük sağlar. Cisco’nun güncel monitoring rehberi show ip nat translations ile birlikte show ip nat statistics komutunu NAT’ın temel doğrulama araçları arasında gösterir. Cisco
Pratikte burada özellikle şunu anlamaya çalışırım:
NAT motoru trafik görüyor mu?
Translation hiç oluşmuyorsa başka bir problem vardır.
Translation artıyor ama erişim hâlâ yoksa problem büyük olasılıkla packet flow’un sonraki aşamalarındadır.
NAT çalışıyor ama internet hâlâ yoksa: Routing
Bu nokta son derece önemlidir.
NAT translation tablosunda:
10.10.10.25 → 203.0.113.10görmeniz uçtan uca bağlantının başarılı olduğunu kanıtlamaz.
Router destination network’e nasıl ulaşacağını hâlâ bilmek zorundadır.
Kontrol:
show ip routeveya belirli destination için:
show ip route 8.8.8.8kullanılabilir.
Default route senaryosunda örneğin:
ip route 0.0.0.0 0.0.0.0 203.0.113.9gibi bir route bulunabilir.
Classic IOS NAT işlem sıralamasında inside-to-outside trafik için routing kararı NAT translation’dan önce değerlendirilir; dönüş yönünde ise translation ile routing sırası farklıdır. Cisco bu nedenle hem dış destination’a geçerli route’un hem de dönüş trafiği için inside local adrese ulaşan route’un bulunmasının önemli olduğunu vurgular. Cisco
Troubleshooting açısından sonuç basittir:
NAT ve routing’i birbirinden bağımsız düşünmeyin.
CEF neden kontrol edilmeli?
Routing table kontrolü mantıksal routing kararını gösterir.
Forwarding tarafında ise:
show ip cef <destination>kullanılabilir.
Örneğin:
show ip cef 8.8.8.8ile FIB’in destination için hangi next-hop/interface’i kullandığını kontrol edebilirsiniz.
Buradaki temel yaklaşım şudur:
RIB → Route kararı
FIB/CEF → Gerçek forwarding kararıÖzellikle karmaşık routing, VRF veya recursive next-hop yapılandırmalarında yalnızca show ip route ile yetinmemek yararlı olabilir.
Return Path neden NAT troubleshooting’in kritik parçasıdır?
Şunu düşünelim:
10.10.10.25
↓
Cisco Router
↓
203.0.113.10
↓
Internet ServerForward trafik sorunsuz gidiyor.
NAT translation oluşuyor.
Ama cevap paketi geri dönemiyor.
Bu durumda kullanıcı yine:
“İnternet çalışmıyor.”
diyecektir.
Dolayısıyla NAT troubleshooting yalnızca:
“Source IP public IP’ye çevrildi mi?”
sorusundan ibaret değildir.
Şunu da sormak gerekir:
“Return traffic translated global IP’ye geri geliyor mu ve router bunu doğru inside local adrese ulaştırabiliyor mu?”
Cisco’nun NAT order-of-operation açıklaması da dönüş paketlerinin translation sonrası inside local adrese routable olması gerektiğini özellikle vurgular. Cisco
Bu yüzden:
Forward Path + Return Path
birlikte incelenmelidir.
Inside Local → Inside Global mantığını packet flow üzerinden anlayalım
Şöyle bir flow olduğunu düşünelim:
Client
10.10.10.25:53120destination:
8.8.8.8:443NAT router’dan çıktıktan sonra:
203.0.113.10:53120
→
8.8.8.8:443haline gelebilir.
Burada:
Inside Local:
10.10.10.25ve:
Inside Global:
203.0.113.10olur.
Outside adres translated edilmiyorsa:
Outside Local:
8.8.8.8
Outside Global:
8.8.8.8aynı olabilir.
Cisco’nun resmi NAT terminology dokümanında da inside-to-outside trafik için local/global kavramları bu şekilde tanımlanıyor. Cisco
clear ip nat translation * neden dikkatli kullanılmalı?
Test sırasında bazen eski translation kayıtlarını temizlemek gerekir.
Cisco IOS XE üzerinde:
clear ip nat translation *tüm dynamic NAT translations’ı temizlemek için desteklenen komutlardan biridir. Cisco ayrıca tek bir translation veya belirli inside/outside adreslere ait kayıtların daha seçici biçimde temizlenebilmesi için granular komutlar da sağlar. Cisco
Production ortamında ise:
clear ip nat translation *komutunu refleks olarak kullanmak iyi bir yöntem değildir.
Çünkü tüm dynamic translation table’ı temizler.
Bu nedenle mümkün olduğunda yalnızca sorunlu host/session ile ilişkili entry’nin temizlenmesi daha kontrollü bir yaklaşımdır.
Önce:
show ip nat translationsile mevcut durumu kaydedip, ardından gerekiyorsa hedefli temizlik yapmak daha güvenlidir.
Translation var ama uygulama çalışmıyorsa NAT’ı suçlamayın
Şu senaryoyu düşünelim:
show ip nat translationsçıktısı doğru.
Inside Local → Inside Global translation oluşmuş.
Routing doğru.
Return traffic de geliyor.
Ancak web sitesi açılmıyor.
Bu noktada sorun artık NAT olmayabilir.
DNS, upstream ACL, Zone-Based Firewall, application service, MTU/MSS, IPsec, PBR veya doğrudan karşı uç servisinde problem bulunabilir.
İyi network troubleshooting’in temel prensibi budur:
Bir bileşenin beklenen şekilde çalıştığını doğruladıysanız, aynı bileşeni tekrar tekrar değiştirmek yerine packet flow’da bir sonraki noktaya geçin.
NAT troubleshooting sırasında debug kullanılır mı?
Gerekirse evet.
Cisco NAT troubleshooting için:
debug ip natgibi debug seçenekleri sağlar. Cisco’nun güncel Catalyst NAT rehberi de NAT troubleshooting araçları arasında NAT debug komutlarını gösteriyor. Cisco
Ancak production router üzerinde debug kullanımı kontrollü yapılmalıdır.
Cisco’nun NAT order-of-operation dokümantasyonu debug komutlarının ciddi miktarda çıktı üretebileceğini ve canlı ağlarda etkisinin anlaşılması gerektiğini özellikle belirtir. Cisco
Bu nedenle normal yaklaşım:
showkomutlarıyla başlamalıdır.
Debug daha ileri troubleshooting aşamasında kullanılmalıdır.
Ben Cisco NAT troubleshooting’e nasıl yaklaşırım?
Rastgele konfigürasyon değişikliği yapmak yerine şu zinciri takip etmek daha doğru olur:
Packet → Interface Role → NAT Classification → Translation → Routing/CEF → Return Path → Application
İlk olarak problemli flow’u kesin olarak tanımlarım:
Source IP
Destination IP
Source Port
Destination Port
ProtocolArdından ilgili inside interface’in gerçekten ip nat inside, dış interface’in ise ip nat outside olduğunu doğrularım.
Sonra NAT ACL veya route-map’in bu source trafiği gerçekten seçip seçmediğine bakarım.
Trafik üretirken:
show ip nat translationsçalıştırırım.
Translation oluşuyorsa NAT’ın en azından classification ve translation bölümü çalışmaktadır.
Ardından route ve CEF’e geçerim:
show ip route <destination>
show ip cef <destination>Son olarak mutlaka return path’i kontrol ederim.
Çünkü NAT troubleshooting’de sorun bazen giden pakette değil:
geri gelmeyen pakettedir.
Cisco NAT troubleshooting hızlı kontrol tablosu
| Kontrol | Komut / Nokta | Aranan durum |
|---|---|---|
| Interface role | show running-config interface ... | LAN=ip nat inside, WAN=ip nat outside |
| NAT ACL | show access-lists | Kaynak subnet gerçekten match oluyor mu? |
| NAT yapılandırması | show running-config | include ip nat | Doğru ACL/interface/pool kullanılıyor mu? |
| Translation | show ip nat translations | Inside Local → Inside Global oluşuyor mu? |
| NAT durumu | show ip nat statistics | NAT mappings ve translations beklenen durumda mı? |
| Routing | show ip route <destination> | Geçerli route/default route var mı? |
| Forwarding | show ip cef <destination> | Doğru next-hop/interface seçiliyor mu? |
| Return Path | Upstream/router kontrolleri | Cevap NAT router’a geri geliyor mu? |
| Temizlik | clear ip nat translation ... | Yalnız gerektiğinde ve kontrollü |
| İleri analiz | debug ip nat | Show komutları yeterli değilse |
En sık karşılaştığım Cisco NAT hataları
Pratikte sorun çoğu zaman karmaşık değildir.
Yanlış wildcard mask:
access-list 10 permit 10.10.10.0 0.0.255.255yerine olması gerekenden farklı bir subnet seçilmiş olabilir.
Inside/outside interface rolleri ters olabilir.
NAT rule farklı ACL’ye referans veriyor olabilir.
Default route olmayabilir.
Public interface değişmiş ancak NAT overload hâlâ eski interface’i kullanıyor olabilir.
NAT translation mevcut olabilir fakat return path yanlış olabilir.
Ya da NAT tamamen doğru olduğu halde gerçek problem DNS veya upstream filtering olabilir.
Bu nedenle iyi troubleshooting yaklaşımı:
“NAT bozuk.”
demek yerine:
“Paket NAT zincirinin hangi aşamasında kayboluyor?”
sorusunu sormaktır.
NAT’ta en önemli troubleshooting prensibi
Bir kullanıcının internete çıkamaması size yalnızca sonucu söyler.
Sebebi söylemez.
show ip nat translations translation’ın oluşup oluşmadığını,
show ip nat statistics NAT motorunun genel durumunu,
show access-lists classification’ın doğru olup olmadığını,
show ip route routing kararını,
show ip cef forwarding bilgisini
gösterir.
Bunları birlikte değerlendirdiğinizde sorun:
ACL mi? NAT mı? Routing mi? Return path mi?
çok daha hızlı ayrıştırılabilir.
Cisco NAT troubleshooting’i tek cümlede özetlemek gerekirse:
Konfigürasyona değil, paketin yolculuğuna troubleshoot uygulayın.
Çünkü çoğu NAT problemi router’ın cevabı vermemesinden değil, bizim doğru tabloya bakmamamızdan kaynaklanır.
Sık Sorulan Sorular
Cisco NAT translation nasıl kontrol edilir?
Aktif NAT translation kayıtları:
show ip nat translationsile görüntülenir. Daha detaylı bilgi için show ip nat translations verbose kullanılabilir. Cisco
show ip nat statistics ne işe yarar?
NAT’ın genel kullanım ve mapping durumunu kontrol etmeye yardımcı olur ve Cisco tarafından temel NAT monitoring komutlarından biri olarak tanımlanır. Cisco
Cisco NAT overload nedir?
NAT overload, birden fazla inside host’un aynı global/public IP adresini TCP/UDP port farklılıklarıyla paylaşmasını sağlar. Bu yapı yaygın olarak PAT olarak adlandırılır. Cisco
Inside Local ile Inside Global arasındaki fark nedir?
Inside Local, internal host’un içeride kullandığı IP adresidir. Inside Global ise bu host’un outside network’e göründüğü translated/global IP adresidir. Cisco
NAT translation neden oluşmaz?
Yanlış inside/outside interface tanımı, NAT ACL’nin source trafiği eşleştirmemesi, yanlış NAT configuration veya packet’in NAT işlemine ulaşmasını engelleyen routing/flow problemleri olası nedenler arasındadır.
clear ip nat translation * güvenli midir?
Komut bütün dynamic NAT translations’ı temizler. Bu nedenle production ortamında etkisi değerlendirilmeden kullanılmamalı; mümkün olduğunda yalnızca sorunlu translation hedeflenmelidir. Cisco
NAT çalışıyor fakat internet neden açılmıyor?
Translation oluşması uçtan uca bağlantının başarılı olduğunu garanti etmez. Routing, CEF, return path, ACL/firewall, DNS ve karşı uç uygulama ayrıca kontrol edilmelidir.
Cem Kemal Erbaş sitesinden daha fazla şey keşfedin
Subscribe to get the latest posts sent to your email.
