HTTP proxy, SSH tüneli veya VPN: doğru katmanı seçin

Üç mühendise şirket içi bir hizmete nasıl ulaşılacağını sorun, üç tasarım alırsınız: bir web proxy, bir SSH tüneli veya tam bir VPN. Üçü de uzak bir hizmeti erişilebilir kılar ve üçü de trafiği başka bir yerden geliyormuş gibi gösterebilir. Farklar sonra ortaya çıkar: kullanılan protokol, seçilen aracın varsaydığı protokol değildir. Tarayıcıda hızlı bir testi geçen bir tasarım, isteği doğuran uygulamada düzenli olarak başarısız olur.

İki olgudan karar verin: hangi protokoller geçmeli ve ilgili adları kim çözebilir. Geri kalan her şey tercihtir.

Proxy yalnızca anladığını taşır

Bir web proxy, kendisi için geliştirildiği protokolü ayrıştırır. İstemci ona bir istek verir, o da isteği ileri aktarır; dolayısıyla proxy ayarı olmayan bir uygulama hiç katılmaz. HTTPS için istemcinin opak bir kanala ihtiyacı vardır; proxy bunu isteği okumak yerine CONNECT üzerinden sağlar.

SSH dinamik yönlendirmesi SOCKS konuşan yerel bir bağlantı noktası açar ve o nokta TCP akışını istemcinin adlandırdığı her hedefe iletir. TCP üzerine kurulu protokoller genellikle bunun üzerinden çalışır. UDP çalışmaz, bir araç açıkça destek eklemedikçe. Yerel yönlendirme daha da dardır: bir yerel bağlantı noktası tek bir sabit ana bilgisayara ve noktaya eşlenir; bu, tek bir bilinen hizmete hizmet eder ve başka hiçbir şeye etmez.

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN paketleri taşır. İstemcinin tünele yönlendirdiği her şey içinden geçer, UDP ve ICMP dahil; bu yüzden tek bir bağlantıya değil, bir ağ gereksinimine uygundur.

Adı birinin çözmesi gerekir

Hedef ad yalnızca uzak ağın DNS'inde varsa, aramayı yapan makine o bölgeyi görebilmelidir. Bir web proxy aramayı kendisi yapar; bu yüzden dizüstü bilgisayar adı hiç çözemese bile iç ad onun üzerinden çalışır. SOCKS de aynı şekilde davranabilir, ancak yalnızca istemci, zaten çözdüğü bir adrese bağlanmak yerine adı ileri aktarırsa. Bu seçim istemcide, sunucuda değil.

curl bölünmeyi açıkça gösterir: bir bayrak ana bilgisayar adını proxy'ye geçirir, bir diğeri önce yerelde çözer. Yerel çözümlemeyle iç ad, herhangi bir tünele dokunulmadan önce başarısız olur ve hata, aslında bir DNS kararı olan şey için proxy'yi suçlar.

VPN üçüncü yolu seçer: özel çözümleyiciyi ve arama etki alanını rotaların yanına kurar. Bu kullanışlıdır ve tanıdık bir yanılsama yaratır: yanıt vermeyen bir çözümleyiciyle var olan bir rota, paketler karşı tarafa ulaşsa bile tam olarak ölü bir tünel gibi görünür.

Ağ yalnızca tek bir çıkışa izin verdiğinde

Pek çok kurumsal ağ, giden bağlantılara yalnızca kimlik doğrulamalı bir web proxy üzerinden izin verir. OpenVPN ve SSH orada çalıştırılabilir; birincisi kendi taşımasını proxy üzerinden tüneller, ikincisi küçük bir CONNECT yardımcısı çalıştıran bir proxy komutu kullanır.

TCP üzerine kurulu tüneller bu kısıtı atlatır, UDP tabanlı bir VPN atlatamaz; bu da evde çalışıp ofiste başarısız olan pek çok yapılandırmayı açıklar. İkinci maliyeti gözden kaçırmak kolaydır: proxy'lenmiş bir TCP bağlantısının içinde taşınan bir TCP tüneli artık yeniden ileten iki katmana sahiptir ve kayıp altında bu eşleşme, hiçbir katmanın tek başına üretmediği biçimde tıkanır.

Aracıları zincirlemek, katman seçmekten farklı bir sorudur. İkinci bir proxy veya Tor eklemek kimin neyi gözlediğini değiştirir ve zincirdeki konum hangi atlamanın şifreli metni gördüğünü belirler.

Sıra, atlama sayısından daha önemlidir. Dış atlama şifreli bir akışı izlerken iç atlama taşıdığı düz metni görür; bu yüzden bir zincir ancak en dikkatsiz halkası kadar gizlidir. Protokolleri atlamalar arasında karıştırmak bunu otomatik olarak iyileştirmez. Çoğunlukla arıza biçimleri hakkında akıl yürütmeyi zorlaştırır.

Sahte adres seçeneklerden biri değildir

Başkasının kaynak adresiyle paket üretmek yararlı hiçbir şey sağlamaz: yanıtlar gerçek sahibine gider ve çoğu ağ trafiği doğrudan düşürür. Aracı tam da kaynak uydurulamadığı için gereklidir ve bu, üç tasarımın da dürüst gerekçesidir.

Bu aynı zamanda hiçbirinin ne iddia edebileceğini sınırlar. Belirli bir adresten geliyormuş gibi görünmek, o adresin yasal olarak nerede tahsis edildiği ve kimin yönlendirebileceği sorusudur; hangi aracın başlığı taklit edebileceği değil. Bir tasarım aksini varsayıyorsa, bu varsayım onu filtreleyen ilk sağlayıcıda çöker. Varsayımı yazın ki arıza geldiğinde tanınabilsin.

Protokollere ve adlara göre karar verin

Tek bir web istemcisi tek bir web hizmetine ihtiyaç duyuyorsa ve proxy ayarları varsa proxy'ye başvurun. Birkaç bilinen TCP hizmeti yeterliyse ve SSH erişimi zaten varsa SSH tüneline başvurun. Birden çok uygulama, TCP dışı trafik, özel DNS veya yeniden kullanılabilir bir yol gereksinimin parçasıysa VPN'e başvurun.

Sonra gerçek istemciyle ve gerçek adla doğrulayın. Proxy üzerinden bir sayfa yüklemek size UDP hakkında hiçbir şey öğretmez ve bir aracı SOCKS üzerinden çalıştırmak sistem çözümleyicisi hakkında hiçbir şey öğretmez. Sürecin hangi yerel adrese bağlandığını ve hangi çözümleyicinin yanıt verdiğini okuyun. Çalışan bir yol ile bir kez tesadüfen çalışmış bir yol arasındaki fark budur.