Sunucudan localhost'a SSH Tünel (Reverse değil) Kurulumu

Bugün erişimi kısıtlı servisleri (ör. veritabanı, admin panel, dahili API) güvenli biçimde kullanmak için en pratik yöntemlerden biri SSH tunnel kullanmaktır. Sunucu tarafındaki bir servisi yerel makinenize taşımak istediğinizde “localhost” kavramı kafa karıştırır. Bu rehberde sunucudan localhost’a (kullanıcının kendi bilgisayarı) nasıl tünel kuracağınızı; doğru port seçimi, kimlik doğrulama, güvenlik ve test adımlarıyla net biçimde öğreneceksiniz.

Mantık: SSH tunnel neyi değiştirir?

SSH tunnel, iki uç arasında şifrelenmiş bir bağlantı kurar ve bir portu diğer port üzerinden taşır. Bu sayede ağ kısıtlarını “aşmak” yerine, trafiği yetkili bir kanal üzerinden yeniden yönlendirmiş olursunuz.

Bu yazıda iki uçtan bahsediyoruz: - Uzak sunucu (server): SSH erişimi olan VDS/VPS/dedicated makine. - Yerel makine (local): Tarayıcıyla kullandığınız ya da psql/mysql gibi istemciler çalıştırdığınız bilgisayar.

“Sunucudan localhost’a tunneling” derken genelde iki senaryo kastedilir: - Senaryo A (en yaygın): Yerel makineden sunucuya tünel (local forward) - Komut sizde çalışır, siz yerelde bir port açarsınız. - Yerel portu, sunucudaki hedef porta yönlendirir. - Senaryo B: Reverse (remote forward) - “Uzak tarafın yereldeki porta bağlanması” gibi senaryolardır.

Bu rehber Senaryo A’yı hedefler: Yerelde “localhost:port” açıp bunu sunucudaki servise bağlamak.

Hangi servislerde işe yarar?

• Sunucuda çalışan bir servis yalnızca sunucu içinden erişilebilir (ör. 127.0.0.1’de veya özel ağda).
• Yerel makineden doğrudan erişilemiyor (firewall/NAT sebebiyle).
• DB portu sadece loopback’te veya iç arayüzde.

Ön koşullar: doğru yetki ve doğru hedef

Tünel kurabilmeniz için şu bilgiler net olmalıdır: 1. SSH kullanıcı adı (ör. root, ubuntu, centos). 2. Sunucu IP / domain. 3. SSH portu (standart 22 değilse). 4. Sunucuda hedef servisin: - IP’si (çoğu zaman 127.0.0.1 ya da dahili adres), - portu (ör. PostgreSQL 5432, MySQL 3306, Redis 6379). 5. Localde kullanacağınız portun boş olması.

Hızlı teşhis: Sunucuda hedef gerçekten çalışıyor mu?

Sunucuya SSH ile bağlanın ve (örnek) şu kontrolü yapın: - PostgreSQL için: ss -ltnp | grep 5432 - MySQL için: ss -ltnp | grep 3306 - Web servisi için: ss -ltnp | grep 80

Eğer hedef servis sadece 127.0.0.1 dinliyorsa bu tünel tam olarak bu tip senaryolar için uygundur.

Temel kurulum: local port forward

Aşağıdaki komutlar “yerelde localhost’ta bir port açıp, bu portu sunucudaki hedef porta yönlendirir”.

Örnek 1: Sunucudaki PostgreSQL (127.0.0.1:5432) -> local (localhost:15432)

ssh -N -L 15432:127.0.0.1:5432 user@server_ip -p 22

• -N: Uzakta komut çalıştırma (sadece tünel).
• -L local_port:remote_host:remote_port:
• 15432: Yerel bilgisayarınızda açılan port.
• 127.0.0.1: Sunucunun kendi içindeki adres.
• 5432: Sunucudaki hedef port.

Yerel istemciyi şu şekilde kullanırsınız: - localhost:15432 üzerinden bağlanırsınız.

Örnek 2: Sunucudaki Redis (127.0.0.1:6379) -> local (localhost:16379)

ssh -N -L 16379:127.0.0.1:6379 user@server_ip

Örnek 3: Sunucuda servis 0.0.0.0’da ama yine de tünel tercih edilebilir

Eğer hedef servis 0.0.0.0:PORT dinliyorsa remote_host kısmına yine 127.0.0.1 yazmak genellikle sorun çıkarmaz. Mantık aynı: SSH sunucu üzerinden yerel tünelden trafiği alır.

Kimlik doğrulama ve anahtarlar (key) ile güvenli kurulum

Sadece parola ile çalıştırmak yerine anahtar (SSH key) kullanmak daha güvenli ve pratiktir.

Anahtar dosyası (identity file) belirtme

ssh -N -i ~/.ssh/netkyas_key -L 15432:127.0.0.1:5432 user@server_ip

Parola ihtiyacını azaltma

• Anahtar yerinde doğru yüklenmiş olmalı.
• Sunucuda authorized_keys doğru kullanıcı altında olmalı.

Güvenlik: tunnel’ı “sadece local” tutun

SSH’in varsayılanı çoğu kullanımda yerel arayüzden bağlanır. Yine de netleştirmek önemli.

Yerel dinlemeyi yalnızca localhost yapmak

Bazı platformlarda -L ile dinleme davranışı değişebilir. En kritik kural: Tüneli internetten erişilebilir hale getirmeyin.

Bu nedenle: - Local makinede portu sadece 127.0.0.1 / localhost üzerinden kullanın. - Yerelde firewall/uygulama güvenlik ayarlarını kontrol edin.

Uzak tarafta dinleme kısıtlarını doğru hedefle

Tünelde remote_host olarak genellikle 127.0.0.1 kullanılır. Böylece servis sadece sunucu içinde kalır.

Port çakışması ve “neden bağlanmıyor?” kontrol listesi

Aşağıdaki liste, en sık yaşanan problemleri sırayla ele alır.

Hata 1: “Local port zaten kullanımda”

• Localde 15432 gibi bir port seçtiyseniz çakış olabilir.
• Çözüm: Boş bir port seçin.

Yerel makinede kontrol: - Linux/macOS: lsof -i :15432 - Windows PowerShell: Get-NetTCPConnection -LocalPort 15432

Hata 2: SSH bağlanıyor ama tünel çalışmıyor

• Sunucudaki hedef servis gerçekten dinliyor mu?
• Servis sadece belirli arayüzde mi (ör. 127.0.0.1)?
• Yanlış port numarası yazılmış olabilir.

Sunucuda doğrulama: - ss -ltnp | grep <port>

Hata 3: “Connection refused”

Bu genelde şu anlama gelir: - Hedef servis o portta çalışmıyor. - Yanlış remote_host yazıldı. - Servis firewall ile reddediyor (daha nadir; çoğu zaman servis hiç dinlemiyor).

Hata 4: “Timed out”

Bu durumda daha çok ağ/dolaylı kısıtlar vardır. - SSH tünel kuruldu mu? - Sunucunun içinden hedefe erişim var mı?

Aynı anda birden fazla tünel: pratik kullanım modeli

Tek bir port yetmeyebilir (ör. DB + admin panel). Her servis için ayrı -L tanımlayabilirsiniz.

Örnek: PostgreSQL (15432) + Redis (16379)

ssh -N \
  -L 15432:127.0.0.1:5432 \
  -L 16379:127.0.0.1:6379 \
  user@server_ip

Böylece localde iki port da açılır ve istemciler ayrı ayrı kullanır.

Tarayıcı ile test: HTTP servisleri için net yöntem

Eğer sunucudaki dahili bir HTTP servisi (ör. 127.0.0.1:8080) tünelleniyorsa:

ssh -N -L 18080:127.0.0.1:8080 user@server_ip

Sonra yerelde: - http://localhost:18080 adresine gidersiniz.

Performans ve sınırlar: tüneli ne kadar “yüksek trafik”te kullanmalı?

SSH tüneli şifreleme ek yük getirir. Bu nedenle: - Çok yoğun veri akışında (ör. büyük dosya indirme/streaming) tünel yerine daha uygun mimari seçmek daha doğru olur. - Yine de DB yönetimi, küçük servis erişimleri ve kısa süreli debug işlemleri için SSH tunnel pratik bir standarttır.

Aşağıdaki tablo, kullanım amacına göre beklentiyi netleştirir:

Tunnel kapanması: neden bağlantı kesiliyor?

SSH tüneli açık kaldığı sürece çalışır. Tüneli kesen yaygın sebepler: - Yerel terminalin kapanması. - SSH oturum süresi (keepalive ayarı olmaması). - Ağ kopmaları.

Stabilite için keepalive ayarı (opsiyonel)

SSH istemcisinde keepalive kullanarak bağlantı kopmalarını azaltabilirsiniz:

ssh -N \
  -o ServerAliveInterval=30 \
  -o ServerAliveCountMax=3 \
  -L 15432:127.0.0.1:5432 \
  user@server_ip

Sık yapılan yanlışlar: localhost adresini karıştırmak

Bu konu genelde “localhost kimin localhost’u?” sorusuyla karışır.

• ssh -L local_port:remote_host:remote_port içindeki remote_host sunucunun kendi içindeki adresi demektir.
• localhost kavramı yerelde kullanıldığında sizin bilgisayarınızı, sunucuda kullanıldığında sunucuyu ifade eder.

Bu yüzden DB hedefini doğru şekilde yazmak kritik: Sunucudaki DB 127.0.0.1 dinliyorsa remote_host olarak da 127.0.0.1 yazılmalıdır.

Ne zaman reverse (remote) tunnel gerekir?

Bu rehber local forward’u anlattı. Ancak şu durumda reverse’a ihtiyaç doğar: - Yerel makinenin arkasında NAT/firewall var ve sunucu yerel portunu çağırmak zorunda. - “Sunucu tarafında erişilecek şekilde yerelde port açma” gerektiğinde reverse forward gündeme gelir.

Reverse tunnel ayrı bir komut mantığıyla çalışır; bu durumda hedef mimariyi netleştirmeniz gerekir.

Sonuç: İlk denemeyi en güvenli şekilde yapın

Önce hedef servisin sunucuda gerçekten dinlediğini kontrol edin (ss -ltnp). Sonra local forward ile tek bir portu test edin (ör. PostgreSQL için -L 15432:127.0.0.1:5432). Bağlantı stabilitesi için gerekiyorsa ServerAliveInterval ayarını ekleyin ve tüneli yalnızca localhost üzerinden kullanın. Bu adımları tamamladığınızda, sunucudaki dahili servisleri yerelinizden güvenli ve anlaşılır şekilde erişebilir hale gelirsiniz.