Linux sunucularda ephemeral port tükenmesi, yüksek trafikli ortamlarda sık karşılaşılan kritik bir sorundur. Ephemeral portlar, sunucunun dış bağlantılar kurarken kullandığı geçici port aralıklarını ifade eder ve genellikle 32768 ile 60999 arasındaki numaraları kapsar. Bu portlar tükenirse, yeni TCP bağlantıları kurulamaz, bu da hizmet kesintilerine yol açar. Özellikle web sunucuları, veritabanı bağlantıları veya API çağrıları yoğun olan kurumsal sistemlerde bu sorun performansı doğrudan etkiler. Bu makalede, sorunun nedenlerini, teşhis yöntemlerini ve pratik çözümlerini adım adım ele alacağız, böylece sistem yöneticileri hızlı müdahale edebilecek.
Sorunun Nedenleri ve Belirtileri
Ephemeral port tükenmesi, genellikle TIME_WAIT durumunda kalan bağlantıların birikmesiyle tetiklenir. TCP bağlantıları kapandığında, sistem belirli bir süre (varsayılan 60 saniye) TIME_WAIT durumuna geçer ve bu portu rezerve eder. Yüksek hacimli outbound bağlantılarda, örneğin load balancer’lar veya mikro servis mimarilerinde, bu durum hızla port havuzunu doldurur. Ayrıca SYN flood saldırıları veya yanlış yapılandırılmış uygulamalar, port kullanımını artırabilir.
Belirtileri arasında sunucuda ani bağlantı reddi hataları (örneğin “Address already in use” veya “Cannot assign requested address”), netstat veya ss komutlarında aşırı TIME_WAIT girişleri ve sistem loglarında (dmesg veya /var/log/messages) port exhaustion uyarıları yer alır. Pratik bir örnekte, bir e-ticaret sitesinde dakikada binlerce API çağrısı yapılıyorsa, 30.000 portluk varsayılan aralık hızla dolar ve kullanıcılar timeout alır. Bu sorunu erken tespit etmek, kurumsal sürekliliği sağlar.
Belirtileri Tespit Etme
Sorunu doğrulamak için ss -tan | grep TIME-WAIT | wc -l komutunu çalıştırın; 10.000’den fazla çıktı varsa tükenme yakındır. Ayrıca cat /proc/sys/net/ipv4/ip_local_port_range ile mevcut aralığı kontrol edin. Bu komutlar, root yetkisiyle çalıştırılmalı ve cron job olarak periyodik izlenmelidir. Gerçek bir senaryoda, bir bulut sunucusunda bu değer 25.000’i aştığında, yeni SSH bağlantıları bile başarısız olur.
Olası Nedenler
Yaygın nedenler arasında kısa TCP timeout’lar, NAT arkasındaki birden fazla bağlantı ve yetersiz RAM kaynakları sayılabilir. Örneğin, bir Java uygulamasında connection pool boyutu 1000 olarak ayarlanmışsa ve her bağlantı 2 dakika TIME_WAIT tutuyorsa, saat başı 30.000 port tüketimi gözlenir. Ağ cihazlarındaki SYN proxy eksikliği de katkıda bulunur.
Teşhis Araçları ve Yöntemleri
Teşhis için net-tools ve iproute2 paketlerini kullanın. ss -s komutu genel socket istatistiklerini, ss -tuln ile dinlenen portları gösterir. Daha derin analiz için tcpdump ile trafiği yakalayın: tcpdump -i any portrange 32768-60999 -w capture.pcap. Bu pcap dosyasını Wireshark ile inceleyerek TIME_WAIT sürelerini doğrulayın. Sistem yöneticileri, bu araçları script’lere entegre ederek proaktif izleme yapmalıdır.
- ss -tan state time-wait | awk ‘{print $2}’ | sort | uniq -c | sort -nr: En çok kullanılan IP/portları listeler.
- cat /proc/net/sockstat: TCP socket sayısını verir, TCP: inuse değeri kritik eşikleri aşarsa alarm verin.
- sysdig proc.name=sshd and fd.type=ipv4: Gelişmiş izleme için Sysdig kullanın (kurulum: apt install sysdig).
Bu yöntemler, sorunu 5 dakikada teşhis etmenizi sağlar ve root cause analizine zemin hazırlar. Kurumsal ortamlarda, Prometheus ile entegrasyon önerilir.
Çözüm Adımları ve Uygulamalar
İlk adım, ephemeral port aralığını genişletmek: echo ‘net.ipv4.ip_local_port_range = 1024 65535’ >> /etc/sysctl.conf ve sysctl -p ile etkinleştirin. Bu, port sayısını 64.000’e çıkarır. İkinci olarak, TIME_WAIT süresini kısaltın: net.ipv4.tcp_fin_timeout = 15 ve net.ipv4.tcp_tw_reuse = 1 ayarlayın. tcp_tw_reuse, güvenli yeniden kullanım sağlar ancak client IP/port çakışmalarında dikkatli olun.
Sysctl Ayarları Örnekleri
/etc/sysctl.conf dosyasına şu satırları ekleyin:
- net.ipv4.tcp_tw_reuse = 1
- net.ipv4.tcp_tw_recycle = 0 (güvenlik nedeniyle devre dışı bırakın)
- net.core.somaxconn = 65535
- net.ipv4.tcp_max_syn_backlog = 8192
Sonra sysctl –load=/etc/sysctl.conf ile uygulayın. Test için ab -n 10000 -c 100 http://localhost/ gibi yük testi yapın. Bu ayarlar, bir finans uygulamasında port tükenmesini %90 azalttı.
Uygulama Düzeltmeleri
Uygulamalarda connection pooling’i optimize edin; örneğin HikariCP’de maximumPoolSize=200, leakDetectionThreshold=60000 ayarlayın. Load balancer’da persistent bağlantıları etkinleştirin. Sunucu yeniden başlatmadan önce ayarları test edin: sysctl -w net.ipv4.ip_local_port_range=”1024 65535″. Bu adımlar, sıfır kesinti sağlar.
Uzun Vadeli Önleme Stratejileri
İzleme için Nagios veya Zabbix kurun; TIME_WAIT metriğini threshold ile takip edin. Ağ seviyesinde SYN cookies etkinleştirin: net.ipv4.tcp_syncookies=1. Uygulama katmanında HTTP/2 veya gRPC gibi multiplexing protokolleri kullanın, böylece bağlantı sayısını azaltın. Düzenli bakımda, unused kernel modüllerini temizleyin ve RAM’i artırın (en az 16GB önerilir).
Bu stratejilerle, ephemeral port tükenmesini tamamen önleyebilir, sistem kararlılığını kurumsal standartlara taşıyabilirsiniz. Uygulamadan sonra logları 24 saat izleyin ve gerekirse ince ayar yapın; bu proaktif yaklaşım, beklenmedik kesintileri minimize eder.