Sunucuda port açık olduğu halde uygulamaya neden erişilemez?

Bir portun açık görünmesi, uygulamanın dışarıdan erişilebilir olduğu anlamına gelmez. Portu işletim sistemi dinliyor olabilir; ancak uygulama yalnızca 127.0.0.1 üzerinde çalışıyor, güvenlik duvarı bağlantıyı engelliyor, NAT yönlendirmesi eksik kalıyor, yanlış IP sürümüne bağlanılıyor veya uygulama gelen isteğe yanıt vermiyor olabilir. Sorunu, istemciden uygulamaya uzanan katmanları sırayla test ederek bulun.

Önce servisin gerçekten nerede dinlediğini kontrol edin​

Sunucuda şu komutu çalıştırın:


Buradaki 8080 yerine uygulamanın portunu yazın. Örnek çıktıdaki adres önemlidir:

• 127.0.0.1:8080 yalnızca aynı sunucudan erişim kabul eder. Doğrudan dış erişim tasarlanıyorsa uygun arayüz düşünülür; reverse proxy aynı makineden bağlanacaksa loopback doğru ve daha dar kapsam olabilir. Port açık değil diye backend’i gelişigüzel internete bağlamayın.
• 0.0.0.0:8080 IPv4 arayüzlerinde dinleme anlamına gelir; yine de güvenlik duvarı, ağ güvenlik grubu veya NAT engeli olabilir.
• [::]:8080 IPv6 dinlemesini gösterir. İstemci IPv4 kullanıyorsa ayrıca IPv4 dinlemesi gerekip gerekmediğini kontrol edin.

Aynı sunucuda yerel test yapın:


Bağlantı kurulup HTTP yanıtı alınırsa uygulama en azından yerel olarak çalışıyordur. Connection refused sonucu genellikle ilgili adreste dinleyen süreç olmadığını; zaman aşımı ise ağ filtresi, yanlış adres veya uygulamanın yanıt vermemesi ihtimalini güçlendirir.

Sorunu katmanlara ayırın​

Varsayımsal olarak uygulama 192.0.2.10:8080 üzerinde çalışıyor ve istemci başka bir ağdaki 203.0.113.10:8080 adresine bağlanıyor olsun. Bu örnek203.0.113.10 dış adresinin192.0.2.10 iç örnek adresine NAT ile yönlendirildiğini varsayar; iki ağ da dokümantasyon adresidir. İç ağ testi ile dış IP testini aynı kabul etmeyin. Aşağıdaki ayrım, hangi noktada ilerlemenin durduğunu gösterir.


Port tarama aracı kullanıyorsanız sonucu tek başına kesin kanıt saymayın. Aynı ağdan yapılan test ile internetten yapılan test farklı güvenlik duvarı ve yönlendirme kurallarına tabi olabilir. Özellikle istemci ile sunucu aynı yerel ağdaysa, dış IP üzerinden yapılan test NAT loopback desteği olmadığı için yanıltabilir.

Uygulanabilir teşhis sırası​

1. Sunucunun kendisinde ss ile dinleme adresini doğrulayın. Servis loopback’teyse bunun mimaride beklenen durum olup olmadığını belirleyin. Reverse proxy varsa dışarıdan proxy’nin443 portunu, içeride backend’i test edin. Yalnız gerekli doğrudan erişim için bind/firewall kapsamını kontrollü değiştirin.
2. Sunucu içinde curl ile doğrudan uygulamaya istek gönderin. Bu başarısızsa ağ ayarlarına geçmeyin; uygulama günlüğünü, yapılandırma dosyasını, kullandığınız yolu ve uygulamanın beklediği protokolü inceleyin.
3. Başka bir makineden TCP bağlantısını test edin. Örneğin nc -vz 192.0.2.10 8080 bağlantı kurulumu gösteriyorsa yol üzerindeki temel TCP erişimi vardır. Zaman aşımında sunucu güvenlik duvarı, bulut güvenlik grubu, router ACL'si veya yanlış hedef adresi kontrol edin.
4. Sunucu NAT arkasındaysa router üzerinde dış portun doğru iç IP ve porta yönlendirildiğini doğrulayın. Sunucu adresi değişmişse eski yönlendirme geçerli görünse bile yanlış makineye gidebilir.
5. Uygulama bir konteynerde çalışıyorsa konteyner içindeki dinleme adresini ve host port yayınlamasını ayrı ayrı kontrol edin. Konteynerin kendi portunun açık olması, host üzerinde aynı portun yayınlandığı anlamına gelmez.
6. TCP erişimi kurulduğu halde tarayıcı hata veriyorsa HTTP ve HTTPS ayrımını kontrol edin. TLS beklemeyen bir porta HTTPS ile bağlanmak veya TLS bekleyen porta düz HTTP göndermek uygulama çalışsa bile başarısız sonuç verir.
7. Son olarak reverse proxy, sanal host, Host başlığı, IPv4/IPv6 DNS kaydı ve sunucunun dönüş yolunu kontrol edin. Paket sunucuya ulaşıyor ancak yanıt geri dönemiyorsa istemci bağlantısı zaman aşımına uğrar.

Bağlantı sırasında paket yakalama yapabiliyorsanız sunucunun ilgili arayüzünde TCP SYN paketinin gelip gelmediğini ve SYN-ACK dönüp dönmediğini gözlemleyin. SYN hiç gelmiyorsa sorun sunucu uygulamasından önceki ağdadır; SYN geliyor fakat yanıt dönmüyorsa yerel filtreleme veya yönlendirme incelenmelidir. TCP kuruluyor ama HTTP yanıtı yoksa artık port açıklığı değil, uygulama veya proxy davranışı araştırılmalıdır.

HTTPS sanal host/SNI için IP’ye doğrudan curl atmak alan adı isteğiyle aynı değildir. DNS yolunu ayırmak için curl --resolve example.com:443:192.0.2.10 Example Domain gibi kendi gerçek değerlerinizle test edin; sertifika doğrulamasını kapatmayın. IPv6 [::] soketinin IPv4 de kabul etmesi işletim sistemi/socket ayarına bağlıdır. Paket yakalamada yanlış arayüz/namespace seçimi de SYN görünmemesine yol açabilir.

Sık yapılan hatalar​

Portu yalnızca sunucu işletim sisteminin güvenlik duvarında açıp bulut güvenlik grubunu unutmak, uygulamanın dinlediği port ile proxy'nin yayınladığı portu karıştırmak ve DNS'in doğru IP'ye çözüldüğünü doğrulamamak en yaygın hatalardandır. Ayrıca 127.0.0.1 üzerinde çalışan servisi dışarıdan erişilebilir sanmak ve yalnızca aynı sunucudan başarılı curl sonucunu yeterli kabul etmek de yanlış teşhise yol açar.

Kaynaklar​

• Linux: ss port filtresi
• curl: resolve ve TLS bağlantısı
• Nginx: Proxy/backend yerleşimi

Sık sorulan sorular​

Port taramasında “open” görünüyor ama tarayıcı sayfayı açmıyor; bu nasıl mümkün?​

Tarama TCP bağlantısının kurulduğunu gösterebilir; uygulamanın doğru HTTP protokolünü, yolu veya Host başlığını kabul ettiğini göstermez. Önce aynı porta curl -v ile istek gönderip alınan yanıtı inceleyin.

Yerel ağdan erişiliyor, internetten erişilemiyorsa hangi nokta önceliklidir?​

NAT port yönlendirmesi, dış güvenlik duvarı, bulut güvenlik grubu ve servis sağlayıcının gelen bağlantı kısıtlamaları kontrol edilmelidir. Dış testin gerçekten dış bir ağdan yapıldığından da emin olun.

IPv4 ile çalışıp IPv6 ile çalışmayan servis için ne kontrol edilir?​

DNS kayıtlarının hangi IP sürümünü döndürdüğünü ve uygulamanın 0.0.0.0 ile [::] adreslerinden hangisinde dinlediğini karşılaştırın. IPv6 kaydı varsa istemciler IPv6'yı tercih ederek yalnızca IPv4'e bağlı servise ulaşamayabilir.