Port yönlendirme ile VPN erişimi: paket gerçekte nereye gider

Port yönlendirme hedefi yeniden yazar ve orada durur; VPN önce paketi sarar. Her birinin hangi katmanı değiştirdiğini ve bunun HTTPS için ne anlama geldiğini görün.

İki tasarım, tek bir HTTPS uygulaması ve paket her birinde farklı bir yol izler. Port yönlendirme paketin nereye teslim edileceğini değiştirir ve gerisini olduğu gibi bırakır. VPN önce o paketi başka bir paketin içinde taşır, böylece uygulamanın dinleyicisi farklı bir kaynak ve daha küçük bir azami yük görür. İnsanların tartıştığı şifreleme her iki durumda da vardır, çünkü uygulama hâlâ HTTPS'tir; farklı olan, kimin bağlantı açabileceği ve aradaki ağın neyi gözlemleyebileceğidir. Bu ayrım pratik soruların çoğunu çözer.

DNAT kuralı hedefi yeniden yazar ve orada durur

Bir Linux ağ geçidinde hizmet yayımlamak, nat tablosunun PREROUTING zincirinde bir kural ya da nftables'ta eşdeğeri demektir. Kural genel adres ve bağlantı noktasıyla eşleşir, ardından hedefi uygulamanın özel adresine yeniden yazar. Kaynak adres, kaynak bağlantı noktası ve yük dokunulmadan kalır ve conntrack eşlemeyi kaydeder, böylece yanıtlar çıkarken yeniden yazılır. Davranış, RFC 3022'de tanımlanan geleneksel adres çevirisi modelidir.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

Uygulamanın dinleyicisi bağlantının bir çeviriden geldiğini asla öğrenmez. İstemcinin gerçek kaynak adresini görür, bu erişim günlükleri ve hız sınırları için yararlıdır ve özel adrese yanıt verir çünkü conntrack eşlemeyi tersine çevirir. O yolda hiçbir şey şifreyi çözmez veya yeniden şifrelemez: TLS hâlâ istemci ile uygulamanın kendi sertifikası arasında çalışır.

Kural ayrıca daha sonra karşılaşacağınız arıza modlarını belirler. Ağ geçidi iletir ama uygulamanın ana bilgisayarının istemciye dönüş yolu yoksa, yanıtlar yanlış kaynakla çıkar ve el sıkışma durur. İkinci bir kural önce eşleşirse sonucu sıra belirler ve iptables -t nat -L -n -v paketi hangi kuralın aldığını kanıtlayan sayaçları gösterir.

Tünel paketi dinleyici görmeden önce sarar

VPN uygulamayı hiç yayımlamaz. İstemci ağ geçidinin genel adresine yönelik bir dış paket kurar, iç paketi onun içinde şifreler ve ağ geçidi şifreyi çözüp iç paketi özel hedefe yönlendirir. WireGuard'da dış taşıma UDP'dir, genellikle yüksek bir bağlantı noktasındadır; OpenVPN TCP 443 üzerindeyken dış paket yolu izleyen her şeye TLS gibi görünür.

Tünelin içinde iç paket özel adresleri korur: istemcinin tünel adresi, diyelim 10.8.0.6, ve uygulama 10.20.30.40 üzerinde. Bu yüzden dinleyici tünel havuzundan bir kaynak görür ve her istemci o ağ geçidini bir sonraki sıçrama olarak paylaşır. VPN arkasındaki erişim günlükleri tam da bu nedenle kullanıcı yerine ağ geçidini gösterir, ağ geçidi özgün kaynağı saklamıyorsa.

Sarma başlık alanına mal olur ve ölçülebilir sonucu olan tek mekanizma düzeyi farkı budur. Bir dış IP başlığı artı UDP artı WireGuard'ın kendi başlığı yolun MTU'sundan yer ve bu yüzden büyük paketler parçalanmalı ya da iç TCP yığını MSS'sini sınırlamalıdır. Yönlendirilen yolda çalışan bir aktarım, bir ara cihaz daha küçük MTU'yu bildirecek ICMP'yi düşürdüğünde tünelde takılabilir.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Maruz kalma girişte belirlenir, şifreyle değil

İki tasarım da aynı TLS dinleyicisinde biter, yani ikisi de aynı sertifikayı, aynı protokol sürümlerini ve aynı uygulama oturum açmasını devralır. Değişen, kimin el sıkışma başlatmaya izinli olduğudur. Genel bir yönlendirmede 203.0.113.10:443 adresine ulaşan her ana bilgisayar, uygulamanızın yetkilendirmesine bakılmadan önce bir TCP el sıkışması ve TLS ClientHello alır. Yalnızca tünel üzerinden erişimde dinleyiciye yalnızca ağ geçidinin tünele yönlendirdiği adreslerden ulaşılabilir ve yabancının SYN'i ağ geçidi ilkesinde ölür.

Bu fark erişilebilirlikle ilgilidir, gizlilikle değil. Yönlendirilmiş bir HTTPS hizmeti düz metin değildir ve VPN uygulama kimlik doğrulaması ihtiyacını ortadan kaldırmaz: tünele kabul, bir cihazın bu ağa paket gönderip gönderemeyeceğini yanıtlar; dosya uygulaması ise bir kullanıcının belge okuyup okuyamayacağını. İkisini karıştırmak, ekiplerin tüm LAN'ı veren bir VPN ve tek ortak parolalı bir uygulamayla sonuçlanmasının yoludur.

Dinleyiciyi ve ilkeyi ayrı ayrı inceleyin, çünkü ikisinden biri sandığınızdan daha geniş olabilir:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

ss dinleyicinin 0.0.0.0 adresine bağlı olduğunu gösteriyorsa, uygulamaya yönlendirme ve güvenlik duvarı ilkesinin izin verdiği her yerden ulaşılabilir ve yönlendirme giriş yollarından yalnızca biridir. Özel adrese bağlamak veya güvenlik duvarında kaynak aralığını kısıtlamak VPN seçmekten ayrı bir karardır ve maruz kalmayı gerçekten daraltan karar budur.

Yolu ölçün, etiketi değil

Biri yönlendirmenin daha hızlı olduğunu iddia ettiğinde dürüst karşılaştırma diğer her şeyi sabit tutar: aynı istemci, aynı erişim ağı, aynı dosya, aynı TLS yapılandırması, aynı uygulama ana bilgisayarı. Aktarımı her yol için iki kez çalıştırın ve toplam süreyi, hata sayısını ve yanıt verme yeteneğini kaydedin; ilgisiz bir hız testinin çıktısını değil.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

Bu sayılar bağlantı kurulumunu aktarım süresinden ayırır, bu önemlidir çünkü iki yol genellikle şifre maliyetinde değil, gidiş-dönüş gecikmesi ve MTU'da farklılaşır. TLS işi her iki tasarımda da uçlarda olur ve tünel kapsülleme, farklı bir rota ve belki daha yoğun bir ağ geçidi ekler. Tünel yolu daha uzunsa veya ağ geçidi yüklüyse fark yola aittir, şifreleme kelimesine değil.

Hizmetin gerçekten ihtiyaç duyduğu giriş ilkesini seçin, sonra ölçülen bir farkın onu değiştirmeyi haklı çıkarıp çıkarmadığına karar verin. Genel yönlendirme açık internete yönelik bir hizmete uygundur; kaynak kısıtlamaları, güncel TLS ve önünde izleme ile. Yalnızca tünel üzerinden erişim, kullanıcıları zaten kayıtlı olan bir iç araca uygundur; ağ geçidi yönlendirmesi ve uygulama izinleri ikisi de tüm LAN'dan darsa.

Tasarımı tamamlanmış ilan etmeden önce dört şeyi doğrulayın: dinleyicinin hangi adrese bağlı olduğunu, paketi hangi kuralın veya rotanın içeri aldığını, dönüş yolunun istemcinin gerçek adresinden çalışıp çalışmadığını ve büyük yüklerin MTU'yu aşıp aşmadığını. Her biri için yukarıda bir komut var ve hiçbirine güvenli kelimesi veya bir bant genişliği grafiği yanıt vermiyor.

İlgili makaleler