Reverse Proxy vs Reverse Tunnel: Temel Farklar ve En İyi Kullanım Durumları

Bir dashboard, NAS arayüzü, dahili bir araç veya küçük bir uygulama yayınlamaya çalışıyorsanız, arama yolculuğu hızla kafa karıştırıcı hale gelir. Bir rehber size ters proxy kullanmanızı söyler. Bir diğeri cevabın ters tünel olduğunu söyler. Üçüncüsü her iki terimi aynı nefeste kullanıyor gibi görünüyor. Bu noktada, kabaca aynı şeyi ifade ettiklerini varsaymak makuldür.

Karışıklık, her ikisinin de bir bağlantının ortasında yer alması ve dahili bir hizmeti açığa çıkarmaya yardımcı olabilmesi nedeniyle ortaya çıkar. Ancak yanlış modeli seçmek zaman kaybettirir. Ters proxy, hiç kimsenin ulaşamadığı bir ağı düzeltmez, tünel ise genel bir kenarın yalnızca daha iyi yönlendirme ve TLS işlemesine ihtiyaç duyduğunda gereksiz karmaşıklık ekleyebilir.

SSH bayraklarının, TLS’nin veya NAT diyagramlarının derinlemesine incelenmesine ihtiyacınız yok. Doğru seçim yapmak için bir soruyla başlayın: zaten ulaşılabilir bir genel giriş noktanız var mı?

Hızlı Anahtar Kelimeler ve Bir Dakikalık Cevap

Daha derine gitmeden önce, kelime dağarcığını düz İngilizce ile bir kez sabitleyin. Amaç basittir: makalenin geri kalanını soyut yerine açık hale getirmek.

Burada, istemci tarafından karşılaşılan her zaman internet tarafından karşılaşılan anlamına gelmez. Bir reverse proxy, tamamen özel bir ağ içinde istemcilere hizmet verebilir. Bu makale, hizmetleri dış kullanıcılara yayınlamaya odaklanır, bu nedenle çoğu örnek genel bir kenar kullanır, ancak trafik yönetimi rolü aynı kalır.

Bu terimler açık olduğunda, hızlı karşılaştırma taranması çok daha kolay hale gelir.

Kenar erişilebilirliği ve origin erişilebilirliği arasındaki önemli ayrım budur. Bir reverse proxy ile, istemcilerin proxy uç noktasına bir yolu olması gerekir, ancak nadiren arka uca doğrudan. Proxy, bu arka uca localhost, özel bir alt ağ veya başka bir iç yol üzerinden erişebilir. Bir reverse tunnel ile, origin gelen istemci bağlantısını beklemez. Röleye giden bir bağlantıyı korur ve bu, istemci tarafından karşılaşılan uç noktayı sağlar.

Bu makaleden sadece bir cümle tutacaksanız, bunu tutun: bir reverse proxy zaten gelebilecek trafiği yönlendirir, bir reverse tunnel ise doğrudan gelen erişilebilirlik eksik olduğunda veya istenmediğinde yolu oluşturur.

Her İkisinin Yapmaya Çalıştığı Şey

Her iki yaklaşım da dış istemci ile doğrudan açığa çıkarılmayan, basit bir genel uygulama gibi olmayan bir kaynak hizmet arasına bir aracı yerleştirir.

Bu paylaşılan aracı rol, terimlerin gerçek konuşmalarda karışmasının nedenidir. Yönetilen tünel ürünleri bir ana bilgisayar adını açığa çıkarabilir ve HTTP veya TCP trafiğini proxy benzeri bir şekilde iletebilir. Ters proxy’ler ise genellikle özel arka uçların önünde bulunur ve onları daha güvenli ve düzenli hale getirir. Yalnızca orta katmana baktığınızda, fark gerçekte olduğundan daha küçük görünebilir.

En yararlı analoji şudur:

• Bir ters proxy, insanların zaten ulaşabileceği bir binanın ön masasıdır. Ziyaretçileri alır ve onları doğru ofise gönderir.
• Bir ters tünel, kilitli bir bina içindeki birinin başka bir yerde ulaşılabilir bir masaya bir hat sağlamasına daha çok benzer. Ziyaretçiler hala genel bir masayı kullanırlar, ancak özel taraf içeriden dışarıya doğru yolu oluşturmuştur.

Sonraki adım, her aracının resme girdikten sonra ne yaptığına bakmaktır.

Ters Proxy Gerçekte Ne Yapar

Ters proxy doğru araç olduğunda, istek yolu basittir: istemci genel bir hostname veya IP’ye ulaşır, proxy isteği alır ve proxy onu arkasındaki doğru kaynak hizmetine iletir.

Temel akış şu şekilde görünür:

Client -> reverse proxy -> origin service

Ters proxy’yi yararlı kılan şey sadece iletme değildir. Trafiğin uygulamaya ulaşmadan önce o genel ön kapıda olabilecek her şeydir. Pratik anlamda, bu genellikle şunlar gibi şeyleri ifade eder:

• app.example.com ile api.example.com gibi hostname’e göre yönlendirme
• /blog ile /admin gibi yola göre yönlendirme
• sertifikaların kenarında işlendiği TLS sonlandırması
• upstream uygulamaların ihtiyaç duyduğu başlıkları iletme veya normalleştirme
• trafiği birden fazla backend örneğine dengeleme
• iç hizmet düzenini doğrudan genel maruziyetten gizleme

Bu nedenle ters proxy’ler doğal olarak genel VPS, dedicated server ve cloud VM altyapısına uyum sağlar. Örneğin, genel bir AlexHost VPS üzerinde çalışan birkaç web uygulaması, hostname’ler, sertifikalar ve backend yönlendirmesi için bir giriş noktasını paylaşabilir. Bu model yine de internet erişilebilirliğinin zaten yerinde olmasına bağlıdır. CGNAT arkasında veya kilitli bir ev ağında bulunan bir hizmetin önce dış dünyadan kullanılabilir bir yol olması gerekir.

Ters Tünelin Gerçekte Ne Yaptığı

Ters tüneller, kaynak hizmetinin özel veya doğrudan gelen erişimden engellenmiş olduğunu varsayar. Özel taraf, bir genel röle, kenar veya sunucuya giden-ilk veya içeriden-dışarı bağlantı oluşturur. Dış kullanıcılar daha sonra bu genel tarafa bağlanır.

Düz tutulması gereken iki yön vardır: kaynak tüneli dışarıya kurarken, sıradan istekler istemci tarafından içeri girer.

Tunnel establishment:
Origin service / connector -> public relay or edge

User request:
Client -> public relay or edge -> established tunnel -> origin service

Yanıtlar, ters yönde kurulan yol aracılığıyla geri döner.

Bir ana tünel ailesi klasik SSH uzak port yönlendirmesidir. Pratik anlamda, bu özel bir makinenin ulaşılabilir bir sunucuya SSH bağlantısı açması ve o ulaşılabilir sunucudaki bir bağlantı noktasının tünel aracılığıyla özel hizmete bağlanması anlamına gelir.

📝 Not: Klasik ssh -R uzak port yönlendirmesi bir ters-tünel desenidir. İyi bilinen bir örnektir, tüm kategori değildir.

Diğer ana aile, Cloudflare Tunnel veya ngrok tarzı hizmetler gibi yönetilen bağlayıcı tabanlı tünellerdir. Bu kurulumlar da, yerel bir bağlayıcı bir sağlayıcı kenarına giden bağlantılar oluşturur. Sağlayıcı bir ana bilgisayar adı veya uç nokta ortaya çıkarır ve trafiği bu yol aracılığıyla geri yönlendirir. Bu nedenle bu hizmetler dışarıdan proxy benzeri görünebilir.

Kaynak taraf kendi genel IP adresine veya açık gelen bağlantı noktalarına ihtiyaç duymayabilir. Genel kenar hala var, ancak doğrudan kaynak ana bilgisayarında yaşamak yerine kontrol ettiğiniz bir röle, sağlayıcı ağı veya genel sunucuya taşınmıştır.

📝 Not: SSH uzak yönlendirmeleri ile daha geniş maruz kalma her zaman otomatik değildir. Yönlendirilen bir bağlantı noktası, SSH sunucu ayarları daha geniş ulaşılabilirliğe izin vermediği sürece varsayılan olarak uzak sunucuda yalnızca loopback olur.

Gerçek Fark: Traffic Manager vs Path Creator

Aşağıdaki karşılaştırma iki modeli pratik karar kriterlerine dönüştürür.

Bu ayrım yaygın bir mimari karışıklığını önler. “Kurulum gelen trafiği kabul eder” ifadesi, arkasındaki her sunucunun genel olması gerektiği anlamına gelmez.

• Reverse proxy tasarımında, yalnızca istemciye bakan kenarın ilgili gelen istekleri kabul etmesi gerekir; kaynaklar arkasında izole kalabilir.
• Reverse tunnel tasarımında, erişilebilir kenar hala vardır, ancak relay veya tunnel uç noktasına aittir. Özel kaynak, kendi dinleyicisini istemcilere açığa çıkarmak yerine içeriden dışarıya doğru bu kenara ulaşır.

Bu farklar ayrıca kontrol ve performansı şekillendirir. Kendi genel sunucunuzda kendi kendine yönetilen bir reverse proxy, genellikle doğrudan bir ön kapı katmanı sağlar. Bir reverse tunnel, özellikle yönetilen hizmetlerde relay bağımlılığı veya başka bir atlama ekleyebilir. Bazı tunnel platformları ayrıca uygulama trafiğini proxy’ler ve ana bilgisayar adlarını sonlandırırlar, bu da kategorilerin neden hala çakışıyor görünebileceğini açıklar.

Ters Proxy, Ters Tünel veya Her İkisini Ne Zaman Kullanacağınız

Karşılaştırma, yaygın işletim ortamlarına uygulandığında daha kullanışlı hale gelir.

Senaryo 1: bir VPS veya dedicated sunucuda birkaç genel hizmet. AlexHost VPS veya dedicated sunucu gibi barındırılan bir ortamda, değer erişim oluşturmakta değil, onu organize etmektedir. Ters proxy, birkaç hizmete tek bir ön kapı ve TLS’yi işlemek için tek bir yer verir. Ayrıca backend uygulamalarını genel yüzeyden uzak tutar.

Senaryo 2: CGNAT arkasında bir ev laboratuvarı, NAS veya dashboard. Bu ortamda, ağ kenarı kendisi kısıtlamadır. ISS’niz veya router kurulumunuz, ters proxy’nin varsaydığı türde doğrudan maruziyeti engelleyebilir, bu nedenle tünel pratik ilk adım haline gelir.

Senaryo 3: router veya firewall’ı kontrol etmediğiniz bir istemci sitesi hizmeti. Bu, başka bir güçlü ters tünel kullanım durumudur. Yerel makineye veya sunucuya bir bağlayıcı yerleştirmenize izin verilebilir, ancak istemcinin ağını yeniden tasarlamaya izin verilmeyebilir. Ters tünel, gelen ağ değişiklikleri yerine giden bağlantıya bağlı olduğu için bu gerçeklikle çalışır.

Senaryo 4: her ikisine de ihtiyacınız var. Bu bir çelişki değildir. Bu katmanlı bir tasarımdır. Bir tünel, erişilebilir bir kenarına genel yol oluşturabilir ve bu kenarın arkasındaki ters proxy, trafik oraya ulaştığında birkaç dahili uygulamayı, ana bilgisayar adını veya TLS akışını organize edebilir.

Birleştirilmiş desen şöyle görünür:

Client -> public edge/tunnel endpoint -> internal reverse proxy -> app A / app B

💡 İpucu: Bir tünel uç noktası, dahili ters proxy’yi besleyebilir ve bu da her bir backend’i ayrı ayrı açığa çıkarmadan birkaç uygulama arasında istekleri yönlendirebilir.

Aşağıdaki tablo bunu hızlı bir ortam-seçim kılavuzuna dönüştürür.

Yaygın Yanlış Anlamalar ve Güvenlik Gerçeği

⚠️ Uyarı: Ne ters proxy ne de ters tünel kendi başına tam bir güvenlik çözümüdür. Ters proxy, savunmasız bir uygulamayı otomatik olarak güvenli hale getirmez ve ters tünel otomatik olarak sıfır güven platformu oluşturmaz.

Ters proxy yanlış anlaması genellikle şöyle ses verir: “Eğer önüne bir proxy koyarsam, hizmet artık güvenlidir.” Bu, yanlış katmana çok fazla kredi verir. Ters proxy, TLS sonlandırmasını merkezileştirebilir. Ayrıca erişim modellerini basitleştirebilir, filtreleme noktaları ekleyebilir ve arka uç düzenini gizlemeye yardımcı olabilir. Bunlar yararlı denetimlerdir, ancak işi bitirmezler. Kimlik doğrulama, yamalanma, uygulama sağlamlaştırması ve mantıklı maruz kalma tasarımı, hizmetin gerçekten iyi korunup korunmadığına karar verir.

Ters tünel yanlış anlaması diğer yöne gider: “Eğer kaynağın açık gelen bağlantı noktaları yoksa, sorun çözülmüştür.” Bu da eksiktir. Bir tünel, kaynağın artık olağan şekilde istenmeyen gelen trafiği kabul etmesi gerekmediğinden, bir tür doğrudan maruz kalmayı azaltabilir. Ancak bu, güven zincirinin geri kalanını ortadan kaldırmaz. Kullanıcılar yine de kimlik doğrulaması yapması gerekir. Maruz kalan kenar veya röle yine de güvenilir olması gerekir. Ve tünelin arkasındaki hizmet yine de güvenli hale getirilmesi gerekir. Ters tünel, varsayılan olarak VPN veya tam sıfır güven mimarisi ile aynı şey değildir.

Yönetilen tünel platformları ana bilgisayar adı yönlendirmesi, ilkeler ve diğer kenar denetimleri ekleyebilir, ancak bu ekstralar katmanlı özellikler olarak okunmalı, tünelin diğer her erişim veya güvenlik kararını değiştirdiğinin kanıtı olarak değil. Güven sınırları hala vardır; bunlar sadece taşınmıştır.

Sonuç: Hangi Sorunun Önce Geldiğini Sorun

Terimler başlangıçta birbirinin yerine kullanılabilir gibi görünüyorsa, ilk soruya dönün: zaten ulaşılabilir bir genel giriş noktanız var mı? Cevap, gelen trafiği yönetmeye mi yoksa trafiğin kullanabileceği bir yol oluşturmaya mı odaklanmanız gerektiğini söyler.

Buradan itibaren, bir sonraki yararlı konu seçmek daha kolay hale gelir. Ortamınıza bağlı olarak, bu ters proxy kurulumu, SSH ters iletme, yönetilen tüneller veya NAT ve CGNAT olabilir. Gerçek beceri terminolojiyi ezberlememek değildir. Hangi eksik parçanın önce geldiğini belirlemektir.