NAT arkasındaki bir iş istasyonuna port yönlendirmeden erişmek

Operatörün NAT’ı ve kilitli bir ofis yönlendiricisi arkasındaki iki uç nokta yönlendirilecek hiçbir gelen bağlantı noktası bırakmaz ve refleks yine de bir tane istemektir. Daha iyi soru, hangi tarafın dışarı arayabildiği ve hangi erişilebilir hizmetin trafiği taşımaya izinli olduğudur. Dört tasarım bu soruya farklı yanıt verir ve bir yol engellendiğinde farklı biçimlerde başarısız olur. Aralarında seçim yapmak protokol adlarının değil, garantilerin karşılaştırmasıdır.

Dört tasarım, dört farklı vaat

Aşağıdaki tablo kısa sürümdür. Orta sütunu test edebileceğiniz vaat olarak, sağ sütunu kimsenin vermediği vaat olarak okuyun.

Hangi satırın geçerli olduğu tercihe değil, işe bağlıdır. Bir uzak masaüstü oturumu, bir yönetim kabuğu ve tüm özel alt ağa erişim aynı giriş noktasına ihtiyaç duymayan üç gereksinimdir, tesadüfen aynı makineyle ilgili olsalar bile.

Bir hub kimin dışarı aradığını değiştirir, neyin izinli olduğunu değil

Yönlendirilmiş hub tasarımında uzaktaki dizüstü bilgisayar ve iş istasyonu, ya da önündeki site geçidi, ikisinin de ulaşabildiği bir hizmete giden bir çıkış tüneli açar. İş istasyonunun yönlendiricisinde hiçbir şey istenmeyen bir bağlantıyı kabul etmez ve bu tasarımın NAT’ı aşmasının ve site statik adrese sahip olmadığında bile çalışmasının nedeni tam olarak budur. Ardından hub, trafiği kendi politikasına göre iki iç adres arasında yönlendirir.

Bedel, hub’ın var olması, iki taraftan erişilebilir olması ve birinin onu işletmesi gerektiğidir. Giden filtreleme taşımayı izinli kılmalıdır ve onu engelleyen bir ağ, port yönlendirme gerekmediği hâlde tasarımı boşa çıkarır.

İnce nokta, erişilebilirliğin ve yetkilendirmenin farklı yerlerde alınan ayrı kararlar olmasıdır. Bir öneke giden yol, kimliğin iş istasyonundaki hangi hizmeti kullanabileceğini söylemez ve tünele izin veren güvenlik duvarı kuralı, hesabın oturum açıp açamayacağını söylemez. İkisini de yapılandırın, ikisini de test edin ve yetkilendirme kararını yönlendirme tablosunda değil, kaynağa sahip olan sistemde tutun.

Atlatma yalnızca her iki yığın da uyguladığında çalışır

Eşler arası atlatma belirli bir sistemin yeteneğidir, VPN’i iyileştiren bir ayar değildir. Interactive Connectivity Establishment birkaç aday adresi toplar ve biri çalışana kadar çiftleri test eder: yerel arayüzlerdeki ana bilgisayar adayları, NAT’ın açığa çıkardığı bilgiden kurulan sunucu yansımalı adaylar ve bir aktarma sunucusunda ayrılan aktarmalı adaylar. Tek başına özel bir adres yol değildir, çünkü diğer taraf oraya yönlendiremez.

Aktarmalı durumu atmadan önce anlamaya değer. RFC 8656 TURN’ü, bir istemcinin sunucudan aktarmalı bir taşıma adresi istediği ve sunucunun bu istemci ile eşleri arasındaki trafiği ilettiği bir protokol olarak tanımlar. Dolayısıyla veriyi aktarma sunucusu taşır ve bu, uç noktaların buluşmasına yalnızca yardım eden bir dizinden maddi olarak farklıdır. Aktarma adresini karşı tarafla değiştirmek, uygulamanın yapması gereken bir koordinasyon adımıdır.

Vaat edemeyeceğiniz şey doğrudan bir yoldur. Simetrik NAT ve bazı kurumsal güvenlik duvarları delik açmayı bozar ve bu olduğunda sistem ya bir aktarma sunucusuna geri döner ya da başarısız olur. İki çevrilmiş uç noktanın asla konuşamayacağı sonucuna da varamazsınız; aktarma yedeği olan desteklenen bir yığın tam da bunlar sık sık konuşabildiği için vardır. Kullanılabilirliğin mi yoksa doğrudanlığın mı daha önemli olduğuna karar verin, sonra iyi durumu varsaymak yerine kurulumun gerçekte hangi yolu seçtiğini doğrulayın.

Bir aracı ağdan daha dardır

Gereksinim tek bir uygulama olduğunda, bir uygulama aracısı veya iş istasyonunun başlattığı ters bağlantı en küçük yanıt olabilir. İş istasyonu dışarıya bir aracıya bağlanır, aracı uzaktaki kullanıcının kimliğini doğrular ve yalnızca o uygulama oturumu taşınır. İş istasyonunun alt ağına hiçbir yol oluşturulmaz, böylece uzak oturumun ele geçirilmesi yanındaki her cihaza giden bir yolu miras almaz.

Bu darlığın bir bedeli vardır: her ek uygulama kendi entegrasyonunu gerektirir ve uygulamanın yerel bir ağ hakkında varsaydığı her şey, örneğin yakındaki bir sunucuda açtığı dosya paylaşımı, erişilebilir olmayabilir. Aracılar politikayı ve günlüklemeyi tek bir yerde toplar, bu da o yer kesintiye dönüşene kadar yararlıdır.

Güven sınırlarını karşılaştırın, sonra yolu test edin

Tünelleri sonlandıran bir hub, yönlendirdiği trafiği okuyabilir. Uygulama uçtan uca şifrelediğinde bir aktarma sunucusu bağımsız olarak korunan bir alışverişi taşıyabilir ve bir aracı genellikle sunduğu oturumu sonlandırır. İkisi de şifreli diye iki tasarımın eşdeğer olduğuna karar vermeden önce korumanın gerçekte nerede bittiğini belirleyin.

Ardından iş istasyonunun dışarıya gerçekte neye ulaştığını kontrol edin, çünkü yukarıdaki her tasarım buna bağlıdır. Bunu iş istasyonunda çalıştırın ve kullanmayı düşündüğünüz ana bilgisayar adını değiştirin.

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

Tasarımı ancak izin verilen kimlik altında amaçlanan uzak işlem başarılı olduktan, onaylanmamış bir kimlik reddedildikten ve doğrudan ya da aktarmalı yol kullanılamadığında davranış bilinip belgelendikten sonra kabul edin. Yeniden bağlanmayı ve iş istasyonunun normal başlangıç bağlamını da ekleyin, çünkü ofiste LAN üzerinden başlayan bir oturum uzak erişimin bağlı olduğu hiçbir şeyi test etmez.