Tek OpenVPN portu, üç hizmet: iç portlar neden önemli

Tek SSH oturumu, tek web uygulaması ve tek ad sorgusu, portlar için kavga etmeden tek bir VPN bağlantısını paylaşabilir. İstemci ağ geçidine tek bir şifreli akış kurar ve her uygulama konuşması onun içinde yol alır. Dışarıda yalnızca tünelin kendi taşıması ve portu görünür. İçeride her hizmet kendi portunu korur ve yine de kendi iznini gerektirir.

Dış akış ne taşır ve neyi saklar

İstemci her paketi makineden çıkmadan önce tünelin taşımasına sarar. Bu dış akışın, VPN yapılandırılırken sabitlenen tek bir hedef portu vardır. Sargının içinde her özgün paket, hedeflediği hizmetin adresini ve portunu korur. Ağ geçidi sargıyı söker ve iç başlığa göre yönlendirir, böylece hedef ağdan gelen sıradan bir istemci görür.

Bu yüzden WAN arayüzündeki bir yakalama üç değil, tek konuşma gösterir. İç portlar ancak kapsülden çıkarma sonrasında görünür. Bu nedenle tek bir güvenlik duvarı açıklığı SSH, HTTPS ve DNS'i aynı anda taşıyabilir.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

TUN/TAP belgeleri yönlendirilmiş bir TUN aygıtının çekirdek ile kullanıcı alanı süreci arasında IP paketlerini geçirdiği devri açıklar. O devir, iç başlığı ağ geçidinin yönlendirme ve güvenlik duvarı koduna görünür kılan şeydir. Ayrıca dış portun hangi hizmetlere izin verildiği konusunda neden hiçbir şey söylemediğini de açıklar.

NAT yönlendirmesi uygulamalara değil, dinleyiciye aittir

IPv4 NAT arkasındaki kendi barındırılan ağ geçidi tek bir gelen çeviriye ihtiyaç duyar: genel adres ve port VPN dinleyicisine eşlenir. Yalnızca tünel kullanıcıları eriştiği için SSH, HTTPS veya DNS için hiçbir kural gerekmez. Bu portları yayımlamak, tünelin zaten koruduğu hizmetleri açığa çıkarırdı. Yönlendirme kuralı dinleyicinin erişilebilirliğini tanımlar, içerideki herhangi bir şey için izin değil.

Tersi de geçerlidir. Tünel portunu açmak başka hiçbir şeyi açığa çıkarmaz, bu yüzden yalnızca tünel üzerinden erişilebilen bir hizmet genel yüzeyini kapalı tutar. Bu ayrım genellikle hizmeti özel tutmanın nedenidir.

İç politika, erişimin gerçekte kararlaştırıldığı yerdir

Şifreleme yolu korur; hedefe yetki vermez. İstemci yolları hangi öneklerin tünele gireceğini seçer, ağ geçidinin yönlendirme politikası paketlerin ondan çıkıp çıkamayacağına karar verir, hedefin güvenlik duvarı ve oturum açma ise hizmetin yanıt verip vermeyeceğine karar verir. DNS en açık durumdur: sorguları taşımak, çözümleyicinin bunları istemci havuzunuzdan kabul etmesini sağlamaz. Her katman bağımsız olarak hayır diyebilir.

Her hizmeti tünel üzerinden tek tek test edin. Başarılı bir sorgu web portu hakkında hiçbir şey söylemez ve başarılı bir web isteği SSH hakkında hiçbir şey söylemez.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

Tünel açıkken her şey başarısız olursa önce istemcinin yol tablosunu okuyun. Bir hizmet başarısız olurken diğerleri çalışıyorsa arıza o hedefte bulunur. Bu iki gözlem farklı sahiplere işaret eder ve onları karıştırmak zaman kaybettirir.

WireGuard aynı çizgiyi çizer

WireGuard dış dinleyicisini ListenPort olarak adlandırır ve iç uygulama yine de ihtiyaç duyduğu hizmet portunu kullanır. AllowedIPs yönlendirilmiş öneklerden oluşan bir kümedir, izin verilen hizmet portlarının listesi değildir. Onu bir port izin listesi olarak okumak, tünelin yaptığıyla örtüşmeyen kurallar üretir. Adlandırma farklıdır; katmanlama değildir.

Hizmet uç noktanın kendisinde çalışıyorsa yerel giriş politikasında, o uç noktanın arkasındaysa yönlendirme politikasında izin verin. Bu ayrım hangi kural kümesinin paketi gördüğünü belirler.

Genel biçim, birçok iç konuşmaya sahip tek bir dış taşımadır. Birkaç dış alışverişe veya farklı bir IP protokolüne ihtiyaç duyan ürünler, tek genel port kalıbının bu tasarımı tanımladığını, her VPN'i tanımlamadığını hatırlatır.