İçeriğe geç
gelistiriciaraclari

Bir Port Dışarıdan Açık mı, Kapalı mı, Filtrelenmiş mi?

· 8 dk okuma

Bir ağ anahtarına (switch) takılı ethernet kablolarının yakın çekimi
Fotoğraf: Dimitri Karastelev / Unsplash

Bir sunucudaki bir servise (SSH, web sunucusu, oyun sunucusu, kamera arayüzü, ev sunucusu) dışarıdan bağlanılamadığında akla gelen ilk soru genellikle şudur: port açık mı? Ama bu tek soru aslında üç farklı ihtimali gizler: port gerçekten açık ve dinliyor, port kapalı ve bağlantı reddediliyor, ya da port bir güvenlik duvarı tarafından sessizce filtrelenip cevap bile vermiyor. Bu üç durumu ayırt edemezseniz saatlerce yanlış yeri (örneğin sunucudaki servisi) kurcalayıp asıl sorunun modem üzerindeki port yönlendirme ayarında ya da operatörün uyguladığı bir kısıtlamada olduğunu kaçırabilirsiniz. Sorunu doğru katmanda aramak, bazen dakikalar içinde çözülecek bir ayarı saatlerce aramaktan kurtarır.

Bir port durumunu doğru okumanın anahtarı, TCP el sıkışmasının (three-way handshake) nerede ve nasıl sonuçlandığına bakmaktır. Kendi bilgisayarınızdan yaptığınız bir test çoğu zaman yanıltıcıdır: yerel ağda her şey normal görünse de internetten gelen bir bağlantı modem, operatör ya da sunucu güvenlik duvarında takılabilir. Bu yüzden dışarıdan, gerçek bir üçüncü noktadan test etmek önemlidir — port kontrol aracımız sorguyu Avrupa'da (Fransa) bulunan sunucumuzdan yapar, yani sizin değil internetin gördüğü sonucu gösterir.

$ araçPort KontrolBir sunucuda portun açık olup olmadığını test edin.

Açık, Kapalı ve Filtrelenmiş Port Arasındaki Fark

TCP bağlantısı kurulurken istemci bir SYN paketi gönderir. Hedef port dinliyorsa SYN-ACK ile cevap verir ve bağlantı açılır: bu açık (open) durumdur. Hedef portta dinleyen bir servis yoksa işletim sistemi RST (reset) paketiyle bağlantıyı hemen reddeder: bu kapalı (closed) durumdur, port testinde 'connection refused' olarak görürsünüz. Üçüncü ihtimal ise hiç cevap gelmemesidir: paket bir güvenlik duvarı tarafından sessizce düşürülür (drop), istemci zaman aşımına (timeout) kadar bekler. Bu filtrelenmiş (filtered) durumdur ve genellikle bir firewall kuralının işaretidir. Bazı tarama araçları filtrelenmiş durumu 'stealth' olarak da adlandırır, çünkü hedef sanki hiç var olmuyormuş gibi davranır.

Bu ayrım pratikte çok işe yarar: kapalı bir port 'buraya kadar ulaştım ama kimse dinlemiyor' derken, filtrelenmiş bir port 'muhtemelen hiç ulaşamadım' der. Bir web sunucusunda 443 portu kapalıysa servis çökmüş ya da hiç kurulmamış olabilir; filtrelenmişse önce güvenlik duvarı kurallarına, port yönlendirmeye ya da operatörünüzün CGNAT uygulamasına bakmalısınız.

Kendi Bilgisayarınızdan Hızlı Test: nc, telnet, Test-NetConnection

Linux ve macOS'ta en pratik araç netcat'tir. 'nc -vz 203.0.113.10 443' komutu belirtilen host ve portu tarar; başarılı olursa 'Connection to 203.0.113.10 443 port [tcp/*] succeeded!' benzeri bir satır, kapalıysa 'Connection refused' görürsünüz. telnet de aynı işi görür: 'telnet mail.example.com 25' bağlantı kurabilirse boş bir ekran ya da sunucunun banner mesajını (örneğin '220 mail.example.com ESMTP') gösterir; kuramazsa hemen ya da zaman aşımıyla hata verir.

Windows'ta PowerShell'in Test-NetConnection komutu daha okunaklıdır: 'Test-NetConnection -ComputerName example.com -Port 443' çalıştırdığınızda TcpTestSucceeded alanı True ya da False olarak sonucu verir, ayrıca çözülen IP adresini de gösterir. Eski telnet istemcisi Windows'ta varsayılan kapalı olduğundan 'Uygulamalar ve Özellikler > İsteğe Bağlı Özellikler' üzerinden ayrıca etkinleştirmeniz gerekir. Her iki komutun da ortak zayıf yanı aynıdır: sonucu yalnızca kendi ağınızdan görürsünüz, dolayısıyla bu testler asıl olarak sunucunun kendisinden yerel bir kontrol yapmak ya da aynı ağdaki bir cihaza erişimi doğrulamak için değerlidir, internetten görünürlüğü kanıtlamaz.

Neden Dışarıdan Test Etmek Gerekir

Aynı ağdaki bir cihazdan yaptığınız test, çoğunlukla NAT hairpinning denen bir davranış yüzünden yanıltıcı sonuç verir: bazı router'lar kendi genel IP adresinize yapılan isteği içeride doğrudan yönlendirir, bazıları vermez. Yani 'kendi genel IP'me 443'ten bağlanabiliyorum' demek, internetteki birinin de bağlanabileceği anlamına gelmez. Bazı ISS'ler de kendi ağ içindeki trafiği farklı yönlendirdiğinden, ofisten yaptığınız test evden yapılan testten bile farklı sonuç verebilir. Gerçek cevabı almanın tek yolu ağınızın tamamen dışındaki, bağımsız bir noktadan sorgulamaktır.

Bu yüzden port kontrol aracımız bilinçli olarak sizin cihazınızdan değil sunucumuzdan bağlanır; SSH (22), HTTP/HTTPS (80/443), veritabanı portları (3306, 5432) gibi yaygın port kısayolları da sunar. Test sırasında bağlantı süresini de görürsünüz, bu da timeout ile hızlı reddetme (kapalı) arasındaki farkı ayırt etmenize yardımcı olur. Sorgu yalnızca yazdığınız host ve portu sunucumuza iletir; kısıtlı bir hız limiti uygulanır ve aralık taraması desteklenmez, çünkü amaç geniş kapsamlı bir tarama değil, tek bir servisin gerçekten erişilebilir olup olmadığını doğrulamaktır.

Port Yönlendirme (Port Forwarding) Nasıl Çalışır

Ev ya da ofis modeminizin arkasındaki cihazlar genelde özel bir IP aralığında (örn. 192.168.1.0/24) yaşar ve tek bir genel IP'yi paylaşır. İnternetten gelen bir bağlantının hangi iç cihaza gideceğini modem bilmez, siz söylemezseniz düşürür. Port yönlendirme kuralı tam olarak bunu tanımlar: 'genel IP'nin 51820 portuna gelen paketleri 192.168.1.50:51820'ye ilet' gibi. Bu ayar router yönetim panelinde genelde 'Port Forwarding', 'Virtual Server' ya da 'NAT' başlığı altında yapılır.

Kural doğru girildiğinde bile iki şey daha kontrol edilmelidir: iç cihazın kendi güvenlik duvarı o portu kabul ediyor mu, ve iç cihaza sabit bir yerel IP (statik ya da DHCP rezervasyonu) atanmış mı — aksi halde router yeniden başladığında cihaz IP değiştirir, kural eski adrese işaret etmeye devam eder. Yönlendirmeyi ekledikten sonra port kontrol ile dışarıdan doğrulamak, ayarın gerçekten çalıştığını göstermenin en hızlı yoludur.

Güvenlik Duvarı Kuralları Portu Nasıl Filtreler

Sunucu tarafında en sık karşılaşılan filtreleme kaynağı Linux'ta iptables/nftables ya da ufw, Windows'ta Windows Defender Güvenlik Duvarı'dır. Bir kural paketi DROP ederse istemci hiç cevap almaz (filtrelenmiş), REJECT ederse RST ya da ICMP 'port unreachable' döner (kapalıya benzer görünür ama sebebi farklıdır: uzak sunucudaki servis değil, aradaki bir kural bağlantıyı kesmiştir). Bulut sağlayıcılarında (AWS Security Group, Azure NSG, DigitalOcean Firewall gibi) ayrıca bir katman daha vardır; sunucu içindeki ufw'yi açsanız bile bulut panelindeki kural kapalıysa paket sunucuya hiç ulaşmaz, dolayısıyla sunucu içi log'larda da hiçbir iz görmezsiniz.

Pratik bir hata ayıklama sırası şöyledir: önce sunucu üzerinde servisin gerçekten o portu dinlediğini doğrulayın (örneğin 'ss -tlnp' çıktısında port görünmeli), sonra sunucu içi güvenlik duvarı kuralını, sonra bulut sağlayıcı güvenlik grubunu, en son da varsa evdeki modem/router yönlendirmesini kontrol edin. Her adımdan sonra port kontrol ile dışarıdan tekrar test etmek hangi katmanın sorunu çözdüğünü net gösterir; her katmanı tek tek elemek, aynı anda birkaç ayarı değiştirip hangisinin işe yaradığını bilememekten çok daha hızlıdır.

CGNAT: Port Yönlendirmenin Hiç Çalışmadığı Durum

Bazı mobil ve ev interneti operatörleri, tükenen IPv4 adreslerini idare etmek için CGNAT (Carrier-Grade NAT, RFC 6598, 100.64.0.0/10 aralığı) kullanır: birden fazla müşteri aynı genel IP adresini paylaşır. Bu durumda modeminizin arayüzünde gördüğünüz 'WAN IP' aslında genel bir IP değil, operatörün iç ağındaki bir adrestir — ne kadar doğru port yönlendirme kuralı girerseniz girin dışarıdan o porta asla ulaşılamaz, çünkü paket sizin modeminize hiç gelmez.

CGNAT'ten şüpheleniyorsanız ip adresim aracıyla gördüğünüz genel IP'yi modem yönetim panelindeki WAN IP ile karşılaştırın; ikisi farklıysa ya da modem arayüzündeki adres 100.64.0.0/10 gibi özel bir CIDR bloğundaysa CGNAT arkasındasınız demektir. Çözüm genelde operatörden statik/genel IP talep etmek ya da IPv6 üzerinden (çoğu operatör IPv6'da CGNAT uygulamaz) erişim kurmaktır.

Pratikte Nereden Başlamalı

Bir portla ilgili sorunu araştırırken sırayı karıştırmamak zaman kazandırır: önce servisin sunucuda çalıştığını ve doğru portu dinlediğini yerelde doğrulayın, sonra ping testi ile hostun ağdan erişilebilir olduğuna bakın (ICMP kapalıysa TCP connect ping'e geçin), ardından port kontrol aracıyla dışarıdan portun durumunu ölçün. Sonuç 'kapalı' ise servis ya çalışmıyor ya da yanlış portta dinliyor; 'filtrelenmiş' ise güvenlik duvarı katmanlarına, ev ya da ofis kurulumundaysanız CGNAT ihtimaline bakın. Bu sırayı takip etmek, aynı anda birden fazla olası nedeni birden düşünüp kafa karıştırmak yerine tek bir değişkeni test edip elemenizi sağlar.

  • Açık: SYN-ACK alındı, servis dinliyor ve bağlantı kabul ediyor.
  • Kapalı: RST alındı, o portta dinleyen bir servis yok.
  • Filtrelenmiş: hiç cevap yok, paket muhtemelen bir güvenlik duvarında düşürüldü.
  • Yaygın portlar: SSH 22, HTTP 80, HTTPS 443, RDP 3389, MySQL 3306, PostgreSQL 5432.

Sıkça sorulan sorular

Port taramasını kendi bilgisayarımdan yapmak neden yetmiyor?

Yerel testler NAT hairpinning ve kendi ağınızdaki kurallar yüzünden yanıltıcı olabilir; internetin gerçekte gördüğü sonucu almak için ağınızın dışındaki bir noktadan test etmek gerekir.

Port kapalı mı filtrelenmiş mi, aradaki fark neden önemli?

Kapalı port sunucuya ulaştığınızı ama kimsenin dinlemediğini, filtrelenmiş port ise muhtemelen hiç ulaşamadığınızı gösterir; ikisi farklı yerlerde (servis ya da güvenlik duvarı) çözüm gerektirir.

Port yönlendirme yaptım ama hâlâ açık görünmüyor, neden?

Sırasıyla iç cihazın güvenlik duvarını, iç IP'nin değişip değişmediğini ve operatörünüzün CGNAT uygulayıp uygulamadığını kontrol edin; CGNAT varsa port yönlendirme dışarıdan çalışmaz.

Port taraması yasal mı?

Kendi sunucunuz veya izniniz olan bir hedef için tek port kontrolü sorun teşkil etmez; başkasına ait sistemlerde izinsiz geniş kapsamlı tarama birçok ülkede yasaktır, bu yüzden aracımız da aralık taramasına izin vermez.

Diğer rehberler