Sunucu Yönetimi & Linux

    SSH Tünel ve Port Yönlendirme

    SSH tünelleriyle uzak servislere şifreli erişim ve yerel, uzak, dinamik port yönlendirmenin pratik rehberi.

    12 dk okuma Güncellendi: 10 Temmuz 2026

    Bir sunucuda çalışan veritabanını dış dünyaya açmadan yönetmek, güvenlik duvarının arkasında kalan bir servise güvenli erişmek ya da kısıtlı bir ağdan çıkışı şifrelemek istediğinizde ilk aracınız SSH tünelleri olmalıdır. SSH yalnızca uzak makineye komut satırı erişimi sağlayan bir protokol değildir; aynı bağlantının içinden başka trafiği de şifreli biçimde taşıyabilir. Bu sayede VPN kurmadan, ek bir port açmadan ve karmaşık yapılandırma dosyalarıyla uğraşmadan noktadan noktaya güvenli bir kanal elde edersiniz.

    Bu rehberde SSH port yönlendirmesinin üç temel biçimini tek tek ele alacağız: yerel yönlendirme (-L), uzak yönlendirme (-R) ve dinamik yönlendirme yani SOCKS proxy (-D). Her birini gerçek senaryolarla, çalışan komut örnekleriyle ve dikkat edilmesi gereken güvenlik noktalarıyla anlatacağız. Sonunda autossh ile tünellerin kopmadan ayakta kalmasını sağlayacak, hangi durumda hangi yönlendirmeyi seçeceğinizi netleştirecek ve sık yapılan hataları önleyeceksiniz. Temel SSH kavramlarına hâkim değilseniz önce SSH bağlantısı ve güvenliği yazısına göz atmanızı öneririz.

    SSH Tüneli Nedir ve Nasıl Çalışır#

    SSH tüneli, kurulmuş bir SSH oturumunun içinden ikinci bir TCP trafiğini taşıma tekniğidir. Normalde uzak sunucuya bağlanıp terminal komutları çalıştırırsınız; tünelleme yaptığınızda ise SSH istemcisi belirli bir portu dinlemeye başlar ve o porta gelen her bağlantıyı şifreli kanaldan karşı tarafa iletir. Karşı taraf paketi çözer ve hedef servise ulaştırır. Böylece açık ağda düz metin akan bir protokol (örneğin eski bir veritabanı bağlantısı) bile SSH'ın AES şifrelemesiyle korunmuş olur.

    Tünelin iki ucu vardır: dinleyen taraf (bağlantıyı kabul eden port) ve hedef taraf (trafiğin gerçekten ulaştığı host:port). Yönlendirme türünü belirleyen şey, dinleyen tarafın istemcide mi yoksa sunucuda mı olduğudur. Yerel yönlendirmede istemci dinler, uzak yönlendirmede sunucu dinler, dinamik yönlendirmede ise istemci bir SOCKS proxy'si gibi davranıp hedefi çalışma anında belirler. Bu üç kalıbı kavradığınızda neredeyse her erişim probleminizi tünelle çözebilirsiniz.

    Aşağıdaki tablo üç biçimi tek bakışta karşılaştırır:

    YönlendirmeBayrakDinleyen tarafTipik kullanım
    Yerel-LİstemciUzak DB'ye, panele, iç servise güvenli erişim
    Uzak-RSunucuNAT arkasındaki servisi dışarı açma
    Dinamik-Dİstemci (SOCKS)Tüm tarayıcı/uygulama trafiğini proxylemek

    Bu üç bayrağın söz dizimini ve mantığını sonraki bölümlerde ayrı ayrı işleyeceğiz.

    Yerel Port Yönlendirme (-L) ile Uzak Servise Erişim#

    Yerel yönlendirme en sık kullanılan biçimdir. Amacı, kendi makinenizdeki bir portu, SSH sunucusunun ulaşabildiği bir hedefe bağlamaktır. Klasik senaryo şudur: Sunucunuzda MySQL çalışıyor ama güvenlik gereği yalnızca 127.0.0.1 üzerinden dinliyor, dışarıya kapalı. Veritabanı yöneticinizi (DBeaver, TablePlus, phpMyAdmin gibi) doğrudan bağlayamazsınız çünkü 3306 portu internete açık değil. Yerel tünel tam da bunun için vardır.

    Söz dizimi -L [yerel_adres:]yerel_port:hedef_host:hedef_port biçimindedir. Örnek:

    # Yerel 3307 portunu, sunucudaki 127.0.0.1:3306 (MySQL) hedefine bağla
    ssh -L 3307:127.0.0.1:3306 [email protected]
    

    Bu komut çalışırken, kendi bilgisayarınızda localhost:3307 adresine bağlanan her uygulama aslında sunucudaki MySQL'e ulaşır. Veritabanı istemcinizde host olarak 127.0.0.1, port olarak 3307 girmeniz yeterlidir. Trafik SSH kanalından şifreli geçer, veritabanı portunu internete açmanıza hiç gerek kalmaz.

    Hedef illa aynı sunucu olmak zorunda değildir. SSH sunucusunun ağda görebildiği başka bir makineye de yönlendirebilirsiniz. Örneğin uygulama sunucunuz, ayrı bir iç veritabanı sunucusuna erişebiliyorsa:

    # Sunucudan görünen 10.0.0.5:5432 (PostgreSQL) hedefine tünel aç
    ssh -L 5432:10.0.0.5:5432 [email protected]
    

    Burada tünel iki atlamalı çalışır: siz app.clou.tr'ye bağlanırsınız, o da iç ağdaki 10.0.0.5'e ulaşır. Bu yöntem, doğrudan erişemediğiniz izole veritabanı sunucularına güvenli bir köprü kurmanın en temiz yoludur.

    Bazı yararlı ek bayraklar da vardır. -N bayrağı uzak kabuk açmadan yalnızca tüneli kurar (komut çalıştırmayacaksanız idealdir), -f ise SSH'ı arka plana atar:

    # Kabuk açma, arka plana at, sadece tüneli ayakta tut
    ssh -f -N -L 3307:127.0.0.1:3306 [email protected]
    

    Varsayılan olarak yerel dinleyen port yalnızca 127.0.0.1'e bağlanır, yani tüneli sadece kendi makineniz kullanabilir. Bunu bilinçli olarak ağa açmak isterseniz adres kısmına 0.0.0.0 yazabilirsiniz, ancak bu tüneli LAN'daki herkese açar ve genellikle önerilmez.

    Uzak Port Yönlendirme (-R) ile Gizli Servisi Dışarı Açma#

    Uzak yönlendirme, yerel yönlendirmenin ters yönlüsüdür. Bu kez dinleyen taraf sunucudur; SSH sunucusundaki bir portu, sizin makinenizin (ya da istemcinin görebildiği bir hedefin) servisine bağlarsınız. En güçlü olduğu senaryo, NAT veya güvenlik duvarı arkasındaki bir servisi geçici olarak dışarıya açmaktır. Örneğin ev bilgisayarınızda localhost:3000'de bir geliştirme sunucusu çalışıyor ve bunu bir iş arkadaşınıza ya da webhook test eden bir servise göstermek istiyorsunuz; ama ev IP'niz erişilebilir değil.

    Söz dizimi -R [uzak_adres:]uzak_port:hedef_host:hedef_port biçimindedir:

    # Sunucunun 8080 portunu, benim makinemdeki localhost:3000'e bağla
    ssh -R 8080:127.0.0.1:3000 [email protected]
    

    Bu komut çalışırken, birisi sunucu.clou.tr:8080 adresine istek gönderdiğinde istek SSH tünelinden sizin makinenize iner ve localhost:3000'e ulaşır. Böylece yerel geliştirme sunucunuz, herkese açık bir sunucu üzerinden erişilebilir hale gelir. Bu, ngrok gibi araçların yaptığı işin SSH ile yapılan sade sürümüdür.

    Burada kritik bir ayrıntı var: Varsayılan olarak -R ile açılan port yalnızca sunucunun 127.0.0.1 arayüzünde dinler; yani sadece sunucuya SSH ile bağlı olan başka biri kullanabilir, dış dünyaya kapalıdır. Portu gerçekten internete açmak için sunucudaki /etc/ssh/sshd_config dosyasında şu ayar açık olmalıdır:

    # /etc/ssh/sshd_config
    GatewayPorts yes
    

    Bu ayarı değiştirdikten sonra sudo systemctl restart sshd ile SSH sunucusunu yeniden başlatın. Güvenlik açısından GatewayPorts clientspecified değerini tercih etmek daha iyidir; bu, portun hangi arayüzde dinleyeceğine bağlantıyı kuran istemcinin karar vermesini sağlar:

    # Sadece belirli bir arayüzde dışa aç (GatewayPorts clientspecified ile)
    ssh -R 0.0.0.0:8080:127.0.0.1:3000 [email protected]
    

    Uzak yönlendirme güçlü ama riskli bir araçtır; bir iç servisi dış dünyaya köprülediğiniz için, tüneli açık bıraktığınız süre boyunca o servis internete maruz kalır. Bu yüzden -R tünellerini iş bitince kapatmayı alışkanlık edinin ve mümkünse kimlik doğrulaması olan servisler için kullanın.

    Dinamik Port Yönlendirme (-D) ve SOCKS Proxy#

    Dinamik yönlendirme, tek bir hedefe bağlanmak yerine SSH istemcinizi bir SOCKS proxy sunucusuna dönüştürür. Yerel ve uzak yönlendirmede hedefi (host:port) komut kurulurken sabitlersiniz; dinamik yönlendirmede ise hedef her bağlantıda değişebilir. Uygulamanız proxy'ye "şu adrese bağlanmak istiyorum" der, SSH da o isteği sunucu üzerinden karşılar. Bu, tarayıcınızın tüm trafiğini uzak sunucu üzerinden çıkarmak için ideal bir yöntemdir.

    Söz dizimi son derece basittir; yalnızca yerel bir port belirtirsiniz:

    # Yerel 1080 portunda bir SOCKS5 proxy başlat
    ssh -f -N -D 1080 [email protected]
    

    Artık localhost:1080 adresi bir SOCKS proxy'dir. Tarayıcınızın ağ ayarlarına bu proxy'yi tanıttığınızda, ziyaret ettiğiniz her site sunucu üzerinden yüklenir; sizin gerçek IP'niz yerine sunucunun IP'si görünür ve yerel ağınızla siteler arasındaki trafik SSH ile şifrelenir. Bu, güvenmediğiniz bir kafe Wi-Fi'sinde çıkışınızı güvenli hale getirmenin ya da bir bölgeye özel bir sorunu sunucu tarafından test etmenin pratik yoludur.

    Komut satırı araçlarını da SOCKS proxy üzerinden geçirebilirsiniz. Örneğin curl ile:

    # İsteği SOCKS5 proxy üzerinden gönder, DNS çözümünü de proxy tarafında yap
    curl --socks5-hostname localhost:1080 https://ifconfig.me
    

    Buradaki --socks5-hostname ayrıntısı önemlidir: Alan adı çözümlemesini de sunucu tarafında yaptırır, böylece hangi siteye gittiğiniz yerel DNS'inize sızmaz. Tarayıcılarda da mümkünse "uzak DNS" seçeneğini açmanız, DNS sızıntısını önlemek için doğru olur. Dinamik yönlendirmenin gücü, tek komutla çok sayıda hedefe erişim sağlamasıdır; bu yüzden birden fazla -L tüneli açmak yerine çoğu durumda tek bir -D yeterli olur.

    Kalıcı Tüneller İçin autossh Kullanımı#

    Standart SSH tünelinin zayıf noktası, bağlantı koptuğunda tünelin de gitmesidir. Ağ dalgalanması, sunucunun yeniden başlaması ya da uzun süre boşta kalma nedeniyle oturum düşerse tünel kapanır ve elle tekrar açmanız gerekir. Sürekli ayakta kalması gereken bir tünel (örneğin uzak veritabanına devamlı bağlı bir uygulama) için bu kabul edilemez. autossh bu boşluğu doldurur: SSH bağlantısını izler, koptuğunda otomatik olarak yeniden kurar.

    Kurulumu çoğu dağıtımda paket yöneticisiyle yapılır:

    # Debian/Ubuntu
    sudo apt install autossh
    
    # CentOS/AlmaLinux (EPEL gerektirir)
    sudo dnf install autossh
    

    Kullanımı ssh ile neredeyse aynıdır; başına autossh -M 0 eklersiniz. -M 0 izleme portunu devre dışı bırakır ve bunun yerine SSH'ın kendi canlılık kontrolüne (keepalive) güvenir; modern kurulumlarda önerilen yöntem budur:

    autossh -M 0 -f -N \
      -o "ServerAliveInterval 30" \
      -o "ServerAliveCountMax 3" \
      -o "ExitOnForwardFailure yes" \
      -L 3307:127.0.0.1:3306 [email protected]
    

    Buradaki ServerAliveInterval 30, her 30 saniyede bir canlılık paketi gönderir; ServerAliveCountMax 3 üç yanıtsız denemeden sonra bağlantıyı ölü sayar. ExitOnForwardFailure yes ise port yönlendirmesi kurulamazsa bağlantıyı hiç açmamayı sağlar, böylece sessizce yanlış çalışan bir tünel oluşmaz.

    Üretim ortamında tünelin sunucu açılışında otomatik başlaması ve çökerse kaldırılması için bir systemd servisi yazmak en temiz çözümdür:

    # /etc/systemd/system/db-tunnel.service
    [Unit]
    Description=MySQL SSH tuneli
    After=network-online.target
    Wants=network-online.target
    
    [Service]
    User=tunel
    Environment=AUTOSSH_GATETIME=0
    ExecStart=/usr/bin/autossh -M 0 -N \
      -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" \
      -o "ExitOnForwardFailure yes" -o "StrictHostKeyChecking accept-new" \
      -L 3307:127.0.0.1:3306 [email protected]
    Restart=always
    RestartSec=5
    
    [Install]
    WantedBy=multi-user.target
    

    Servisi sudo systemctl enable --now db-tunnel ile etkinleştirdiğinizde tünel arka planda çalışır, kopsa bile Restart=always ve autossh birlikte onu ayağa kaldırır. Bu tür kalıcı tünellerde mutlaka parolasız SSH anahtarı kullanın; bir servis interaktif parola giremez. Anahtar tabanlı kimlik doğrulamayı henüz kurmadıysanız temel Linux komutları ve SSH güvenliği yazımızdaki ssh-keygen adımları işinizi görür.

    Güvenlik Notları ve İyi Uygulamalar#

    SSH tünelleri güvenli bir kanal sağlar, ama yanlış yapılandırıldığında yeni bir saldırı yüzeyi de açabilir. Kullanmadan önce birkaç ilkeyi oturtmak, ileride başınızı ağrıtacak sorunları önler. Aşağıdaki tablo en sık karşılaşılan riskleri ve önlemlerini özetler:

    RiskAçıklamaÖnlem
    Açık GatewayPortsUzak tünel istemeden internete açılırclientspecified kullanın, işi bitince kapatın
    Sınırsız yönlendirme yetkisiTünel kullanıcısı her yere köprü kurabilirpermitopen ile hedefleri kısıtlayın
    Parolalı otomatik tünelServis parola giremez, kırılganlık artarSadece SSH anahtarı kullanın
    Unutulmuş tünelAçık kalan tünel sızıntı kaynağı olurSüreli veya izlenen tünel kurun

    Kalıcı bir tünel için ayrılmış, yetkisi kısıtlı bir kullanıcı oluşturmak en sağlıklısıdır. Bu kullanıcının kabuk açmasına gerek yoktur ve yalnızca belirli hedeflere yönlendirme yapabilmelidir. Sunucudaki authorized_keys dosyasında anahtarın önüne kısıtlama seçenekleri ekleyerek bunu sağlarsınız:

    # ~/.ssh/authorized_keys — sadece MySQL portuna tünel, kabuk yok
    command="/bin/false",no-pty,no-X11-forwarding,permitopen="127.0.0.1:3306" ssh-ed25519 AAAA... tunel-anahtari
    

    Bu satır sayesinde ilgili anahtarla bağlanan taraf ne kabuk açabilir ne de 127.0.0.1:3306 dışında bir hedefe tünel kurabilir. Tünel kullanıcılarını bu şekilde kısıtlamak, anahtar çalınsa bile hasarı tek bir servise indirger.

    Birkaç ek alışkanlık da faydalıdır. İş bittiğinde -R tünellerini mutlaka kapatın; açık unutulan bir uzak tünel, iç servisinizi saatlerce dışarıya maruz bırakabilir. Kritik veritabanı erişimlerini yalnızca 127.0.0.1'e bağlı tutup dışarıya hiç açmayın, erişimi tamamen tünel üzerinden yapın. Sunucularınızda düzenli anahtar rotasyonu uygulayın ve kullanılmayan tünel kullanıcılarını temizleyin. Sunucunuzu bir güvenlik duvarı, DDoS koruması ve WAF ile de katmanlı biçimde koruyorsanız, tünelleri bu savunmanın önüne değil, tamamlayıcısı olarak konumlandırın.

    Hangi Yönlendirmeyi Ne Zaman Seçmeliyim#

    Üç biçimi öğrendikten sonra pratikte doğru olanı seçmek kolaylaşır. Karar verirken kendinize tek bir soru sorun: Dinleyen tarafın kimde olmasını istiyorum ve hedef sabit mi değişken mi? Aşağıdaki hızlı kılavuz çoğu durumu kapsar.

    Uzaktaki tek bir servise (veritabanı, admin paneli, iç API) kendi makinenizden güvenli erişmek istiyorsanız yerel yönlendirme (-L) doğru seçimdir. Kendi makinenizdeki ya da iç ağdaki bir servisi geçici olarak dışarıya, herkese açık bir sunucu üzerinden göstermek istiyorsanız uzak yönlendirme (-R) gerekir. Tüm tarayıcı veya uygulama trafiğinizi tek seferde sunucu üzerinden çıkarmak, çıkış IP'nizi değiştirmek ya da birden çok hedefe aynı anda erişmek istiyorsanız dinamik yönlendirme (-D) en verimlisidir. Emin değilseniz varsayılan tercihiniz -L olsun; senaryoların büyük çoğunluğu yerel yönlendirmeyle çözülür.

    Ölçek büyüdüğünde, yani onlarca kullanıcının onlarca iç servise erişmesi gerektiğinde SSH tünelleri elle yönetmek zorlaşır. O noktada kalıcı bir çözüm olarak VPN ya da yönetilen sunucu altyapısına geçmek daha sürdürülebilirdir. Tekil geliştirici ve yönetici erişimleri içinse SSH tünelleri hâlâ en hızlı, en az bağımlılık gerektiren ve en taşınabilir araçtır.

    Sıkça Sorulan Sorular#

    SSH tüneli VPN yerine kullanılabilir mi#

    Sınırlı senaryolarda evet, ama tam bir VPN yerine geçmez. Dinamik yönlendirme (-D) ile bir SOCKS proxy kurup tarayıcı trafiğinizi sunucu üzerinden çıkarabilirsiniz; bu, tek uygulama düzeyinde VPN'e benzer bir gizlilik sağlar. Ancak SSH tüneli yalnızca proxy'yi kullanan uygulamaların TCP trafiğini taşır; işletim sistemi genelindeki tüm trafiği, UDP paketlerini veya rastgele protokolleri kapsamaz. Sistem çapında ve çok kullanıcılı kalıcı erişim gerekiyorsa gerçek bir VPN daha uygundur.

    Tünel açıkken bağlantı koparsa ne olur#

    Standart ssh komutuyla açtığınız tünel, altındaki SSH oturumu koptuğunda kapanır ve yeniden bağlanmanız gerekir. Bunun önüne geçmek için autossh kullanın; bağlantıyı sürekli izler ve düştüğünde otomatik olarak yeniden kurar. Üretim ortamında autossh'u bir systemd servisiyle sarmalayarak sunucu yeniden başlasa bile tünelin kendiliğinden ayağa kalkmasını sağlayabilirsiniz. Ayrıca ServerAliveInterval ayarıyla boşta kalan bağlantıların erken kopmasını da yavaşlatabilirsiniz.

    GatewayPorts ayarını neden açmam gerekti#

    Uzak yönlendirme (-R) ile açtığınız port, varsayılan olarak sunucunun yalnızca 127.0.0.1 arayüzünde dinler; yani yalnızca sunucunun kendisi ya da sunucuya bağlı biri erişebilir. Portu gerçekten dış dünyaya açmak istediğinizde sunucudaki sshd_config dosyasında GatewayPorts ayarının açık olması gerekir. Güvenlik için tam açık yes yerine clientspecified değerini tercih edin; böylece portun hangi arayüzde dinleyeceğine bağlantıyı kuran taraf karar verir ve istemeden her şeyi internete açmazsınız.

    Yerel yönlendirmede hangi portu seçmeliyim#

    Kendi makinenizde henüz kullanılmayan, ayrıcalık gerektirmeyen bir port seçmeniz yeterlidir. 1024'ün altındaki portlar genellikle yönetici yetkisi ister, bu yüzden 3307, 5433, 8080 gibi yüksek ve boş portları tercih edin. Çakışmayı önlemek için gerçek servis portundan bir farklı numara kullanmak (MySQL için 3306 yerine 3307 gibi) hem karışıklığı azaltır hem de yerelde zaten çalışan bir servisle çatışmayı engeller. Kullanmadan önce ss -tlnp komutuyla portun boş olduğunu doğrulayabilirsiniz.

    SOCKS proxy kullanırken DNS sızıntısı nasıl önlenir#

    Alan adı çözümlemesini yerel makinede değil, proxy'nin diğer ucundaki sunucuda yaptırmanız gerekir. curl gibi araçlarda --socks5-hostname seçeneği tam olarak bunu yapar; hostname çözümlemesini sunucu tarafına taşır. Tarayıcılarda ise proxy ayarlarında "uzak DNS kullan" ya da "SOCKS v5 ile DNS'i proxy üzerinden çöz" seçeneğini etkinleştirmelisiniz. Bu ayar kapalıysa hangi siteye gittiğiniz yerel DNS sunucunuza sızar ve gizlilik amacınız zedelenir.

    Tünel için ayrı bir kullanıcı oluşturmalı mıyım#

    Kalıcı ya da otomatik tüneller için kesinlikle evet. Yalnızca yönlendirme yapabilen, kabuk açamayan ve hedefleri kısıtlanmış özel bir kullanıcı oluşturmak, olası bir anahtar sızıntısında hasarı en aza indirir. Bu kullanıcının authorized_keys dosyasında command="/bin/false", no-pty ve permitopen="host:port" gibi kısıtlamalar tanımlayarak yetkiyi tek bir servise daraltabilirsiniz. Böylece tünel çalışır ama aynı anahtarla ne komut çalıştırılabilir ne de başka hedeflere köprü kurulabilir.

    Kapanış#

    SSH tünelleri, tek bir komutla noktadan noktaya şifreli bir kanal kurmanızı sağlayan sade ama son derece güçlü bir araçtır. Yerel yönlendirme (-L) ile uzak veritabanınıza güvenle bağlanır, uzak yönlendirme (-R) ile NAT arkasındaki servisinizi dışarı açar, dinamik yönlendirme (-D) ile tüm çıkışınızı sunucu üzerinden proxylersiniz. autossh ve systemd ile bu tünelleri kesintisiz çalışır hale getirir, permitopen gibi kısıtlamalarla da güvenli tutarsınız. Bir kez alışkanlık edindiğinizde, birçok erişim ve güvenlik problemini ek altyapı kurmadan çözdüğünüzü göreceksiniz.

    Bu tüneller ancak sağlam bir sunucu ve doğru yapılandırma üzerinde gerçek değerini gösterir. Root erişimli, tam denetim sunan bir altyapı arıyorsanız VDS sunucu ve sanal sunucu paketlerimize göz atın; kurulum ve bakımı bize bırakmak isterseniz sunucu yönetimi hizmetimiz devrede. Web projeleriniz için ise hosting paketleri ve güvenli erişim, yedekleme ve SSH desteğiyle gelen çözümlerimizi inceleyebilirsiniz. Clou.TR altyapısıyla tünellerinizi kurun, verinizi şifreli tutun.

    SSHTünel

    Uygulamaya geçmeye hazır mısınız?

    NVMe SSD, ücretsiz SSL ve %99.9 uptime garantisiyle Clou.TR hosting ve sunucu çözümleriyle projenizi hayata geçirin.