SSH yönlendirmesi aslında hangi uygulama trafiğini taşır?

Bir kabuk, yerel yönlendirme, SOCKS ve tünel aygıtı modu farklı arayüzler sunar. Uygulamanızın kullanabileceği arayüzü, yönlendirilmiş bir VPN ile karşılaştırmadan önce adlandırın.

Terminal bağlanır, istem görünür ve herkes SSH erişiminin çalıştığı konusunda hemfikirdir. Sonra dizüstü bilgisayardaki veritabanı istemcisi özel ana bilgisayara hâlâ ulaşamaz ve suç oturuma atılır. İnşa edilen şey bir kabuktu ve bu, SSH’nin sunabileceği dört oldukça farklı arayüzden biridir. Önce arayüzü adlandırın, sonra uygulamanın onu gerçekten kullanıp kullanmadığını test edin. Sıra önemlidir, çünkü her arayüz kendi biçiminde başarısız olur.

Herhangi bir şeyi karşılaştırmadan önce arayüzü adlandırın

OpenSSH istemci kılavuzu birbirine karıştırılması kolay dört mekanizmayı ayırt eder. Bir kabuk veya uzak komut SSH ana bilgisayarında yürütülür. Yerel yönlendirme istemcide dinleyen bir soket açar ve sonraki bağlantıyı uzak taraftan yapar. Uzak yönlendirme tersini yapar ve sunucu tarafında dinler. Dinamik yönlendirme, nasıl kullanılacağını bilen programlar için bir SOCKS uç noktası sunar.

  • Kabuk: program uzak makinede çalışır, yerel olarak hiçbir şey dinlemez.
  • Yerel yönlendirme: dizüstü bilgisayarınızda bir bağlantı noktası vardır, uzak ana bilgisayar giden bağlantıyı kurar.
  • Uzak yönlendirme: uzak tarafta bir bağlantı noktası vardır, trafik size geri döner.
  • Dinamik: istemcide bir SOCKS vekili, yalnızca vekili anlayan uygulamalar kullanır.

Bunların hiçbiri bir yol kurmaz. Vekil ayarlarını yok sayan, ya da UDP konuşan, ya da adları kendi çözen bir program, etkin bir SSH oturumundan etkilenmez. Bu SSH’de bir hata değildir; bu, seçtiğiniz arayüzün kapsamıdır.

Yerel, uzak ve dinamik yönlendirmeler kimin dinlediği konusunda farklıdır

Çoğu durumu belirleyen fark, dinleyen soketin kime ait olduğudur. Yerel yönlendirmede istemci dinler ve uzak uç hedefi arar, bu yüzden hedef adresi sunucunun bakış açısından çözülür. Uzak yönlendirmede sunucu dinler ve bağlantı sizin tarafınıza geri taşınır, böylece yerel bir hizmeti doğrudan yayınlamadan açığa çıkarırsınız.

ssh -N -L 5432:db.internal.example:5432 [email protected]
ssh -N -D 1080 [email protected]
ss -ltnp | grep -E '5432|1080'

İlk komut dizüstü bilgisayarda 5432 numaralı bağlantı noktasını bağlar ve onu bastiondan göründüğü gibi veritabanına yönlendirir. İkincisi 1080 numaralı bağlantı noktasında bir SOCKS vekili oluşturur. Üçüncü komut hangi süreçlerin gerçekten dinlediğini doğrular ve bu, yönlendirmenin bir bağlantı noktası çakışması yüzünden sessizce başarısız olması yerine var olduğunun tek kanıtıdır.

Dinamik yönlendirme kendi uyarısını hak eder: yalnızca SOCKS’e saygı duyan uygulamaları kapsar. Bir tarayıcı ona yönlendirilebilir, bir komut satırı aracına onu kullanması söylenebilir, ancak kendi bağlantı yığınına sahip bir veritabanı sürücüsü genellikle bunu yapamaz. Makinedeki her programın artık tüneli kullandığını varsaymak bu alandaki en yaygın hatadır.

Tünel aygıtı modu tek gerçek ağ istisnasıdır

OpenSSH ayrıca -w tünel aygıtı yönlendirmesini destekler; bu, TCP dinleyicisi yerine noktadan noktaya bir arayüz geçirir. Bu gerçek bir ağ tünelidir ve kasıtlı olarak yapılandırılır, kabuk açmanın yan etkisi değildir.

sudo ssh -w 0:0 [email protected]
ip addr show tun0

Her iki uçta da uygun arayüz numaralarının bulunmasını, sunucuda doğru yapılandırmayı ve istemcide aygıtı oluşturmak için yeterli ayrıcalığı gerektirir. Ayrıca bir adresleme ve yönlendirme planı gerektirir, çünkü çıplak bir arayüz hangi hedeflerin onu kullanması gerektiğine dair hiçbir politika taşımaz.

O zaman bile tünel uzak ana bilgisayarda sona erer. SSH taşımasının sağladığı koruma orada biter ve sonraki bağlantı ayrı bir sıçramadır. Bir VPN ağ geçidi de aynı sınır biçimine sahiptir, bu yüzden karşılaştırma hangi aracın daha güçlü olduğu değil, kapsam ve sonlanma hakkında olmalıdır. Bu sınırı yüksek sesle adlandırmak, bir tünelin «her şeyi şifreleyip şifrelemediği» tartışmasını da bitirir, çünkü açıkça şifrelemez.

Uygulamanızın oluşturduğunuz arayüzü kullandığını test edin

Doğrulama oturum başına değil, uygulama başınadır. Çalışan bir yönlendirme, bağlantı noktasının bağlandığını ve uzak ucun arayabildiğini kanıtlar; önemsediğiniz programın onun üzerinden bağlandığını kanıtlamaz.

curl -sS --socks5-hostname 127.0.0.1:1080 -o /dev/null -w '%{http_code}\n' https://app.internal.example/health
psql "host=127.0.0.1 port=5432 dbname=app sslmode=require" -c 'select 1'

İlk komut, ana bilgisayar adı uzaktan çözülerek SOCKS uç noktası üzerinden bir istek gönderir; ikincisi ise TLS hâlâ gerekliyken yönlendirilen veritabanı bağlantı noktasını dener. Yönlendirme durdurulmuş haldeyken aynı testleri çalıştırıp başarısız olduklarını doğrulayın, çünkü iki yönde de geçen bir test tüneli hiç kullanmamıştır.

Sonra yönlendirilmiş bir VPN ile yalnızca önemli boyutlarda karşılaştırın: hangi hedefler kapsanıyor, hangi protokoller çalışıyor, koruma nerede bitiyor ve erişimi kimin onaylaması gerekiyor. Tek hizmetlik bir yönlendirme daha dar ve daha iyi bir yanıt olabilir, oysa birçok uygulamanın aynı ağ yoluna ihtiyaç duyduğu durumda VPN doğru biçimdir. Hiçbiri uzak uç noktasından erişilebilen her şeyi vermez.

İlgili makaleler