Hangi kaynak adresini VPN sunucunuzun gerçekte gördüğünü NAT belirler

VPN sunucusunun dizüstü bilgisayarınızın adresini paketten okuyup bir günlüğe yazdığını hayal ediyorsunuz. Okuduğu şey, son NAT atlamasının dış başlığa koyduğudur ve hotspot olarak kullanılan bir telefonda bu genellikle yüzlerce aboneye ortak bir adrestir. Makinenizin kendi 192.168.x.x adresi o başlıkta internete asla çıkmaz ve tünel adresi, bağlantı zaten kurulduktan sonra sunucu tarafından verilir. Bu yüzden sunucu günlüğü ile dizüstü bilgisayardaki ip addr uyuşmadığında ikisi de yanlış değildir; aynı oturumun farklı katmanlarını anlatırlar.

Üç adres ve bunlardan yalnızca biri günlükte

Karışıklık, üç adresin tek bir adrese indirgenmesinden doğar. Her birinin farklı bir sahibi vardır, farklı bir başlıkta yaşar ve sunucuya farklı bir yoldan ulaşır.

Bağlantı anında yalnızca orta satır bilinmez. Sunucu bunu daemon'a göre eş tablosuna, durum dosyasına veya akış günlüğüne yazar: WireGuard buna uç nokta der, OpenVPN durum dosyası bunu Real Address olarak etiketler ve strongSwan bunu IKE_SA'nın uzak ana bilgisayarı olarak bildirir. Bu değer farklı bir kaynaktan paket geldiğinde yenilenir, yani kimse bir şeyi yeniden başlatmadan değişir.

Alt satır, insanların yanlışlıkla kimlik iddiası olarak okuduğu şeydir. Sunucu yapılandırmasında bir yer işaretler, bir kişiyi değil, çünkü sunucu onu kendi havuzundan seçmiştir. İki kullanıcı farklı günlerde aynı tünel adresini alabilir ve biri iki cihazdan iki tanesini tutabilir.

Tünel ayakta kalırken günlüğe yazılan tuple neden değişir

Adres çevirisi zamanlayıcısı olan bir tablodur, kalıcı bir bağ değildir. Ev yönlendiricisi son paketten sonra UDP eşlemesini bir süre tutar, operatör ağ geçidi bağlantı noktalarını kendi takvimine göre geri dönüştürür ve Wi-Fi'den LTE'ye geçen bir telefon tamamen farklı bir kaynakla geri döner. Burada Linux conntrack varsayılanları yararlı bir ölçüttür: nf_conntrack_udp_timeout 30 saniyedir ve akış varyantı 120'dir, bu yüzden sessiz bir tünel eşlemesini kullanıcı fark etmeden çok önce kaybedebilir.

Tünel hayatta kalır çünkü protokol adresi değil eşi doğrular. WireGuard el sıkışmadan sonra durumsuzdur, bu yüzden doğrulanmış her paket saklanan uç noktayı günceller ve yeniden bağlanma bir sonraki pakette iyileşir; persistent-keepalive = 25 tam bunun için vardır, boştayken eşlemeyi sıcak tutmak için. OpenVPN'in --float parametresi aynı işi yapar ve doğrulanmış bir istemcinin yeni bir adres ve bağlantı noktasından devam etmesini sağlar. float'ın varsayılan olarak kapalı olduğu 2.4 ve 2.5 derlemelerinde yeniden bağlanma oturumu sıfırlar ve istemci yeniden bağlanır.

IPsec oraya daha fazla hareketli parçayla ulaşır. IKEv2, NAT algılama yüklerindeki kaynak ve hedef özetlerini karşılaştırarak çeviriyi fark eder, UDP 4500 kapsüllemesine geçer ve keepalive'ları yeni tuple'a kadar izler. Keepalive'lar engellendiğinde SA kağıt üzerinde ayakta kalırken tek yöndeki trafik sessizce durur.

Sunucunun atfedebildiği ve atfedemediği şeyler

Öldürmeye değer efsane, çevirinin sizi operatörden sakladığıdır. Değiştirdiği şey etikettir, gözlem değil. Operatörün NAT'ı arkasındaki bir ağ geçidi 100.64.0.0/10 alanını veya birçok abonenin paylaştığı tek bir genel adresi görür ve yine de akışı bir sertifika konusuna, WireGuard genel anahtarına, atanmış tünel adresine, bayt sayaçlarına ve bir zaman penceresine bağlayabilir. Bunların hiçbiri LAN adresinize ihtiyaç duymaz.

Sınırlar ters yönde de işler. Günlükteki paylaşılan bir adres bir ağ geçidine işaret eder, bir eve değil; aynı çevrilmiş adresten farklı bağlantı noktalarındaki iki oturum farklı cihazlardır; aynı adres iki farklı günde bağlantı noktası geri dönüştürüldüyse iki ilgisiz abone olabilir. Yalnızca eş anahtarlarını kaydeden bir sunucu, hesap veritabanı olmadan bunları bir müşteriye bağlayamaz ve yalnızca adresleri kaydeden bir sunucu aynı yönlendirici arkasındaki dizüstü bilgisayarı telefondan ayıramaz.

Tahmin etmek yerine iki ucu karşılaştırın

Ne olduğunu belirlemek için aynı bağlantıyı iki uçta aynı anda yakalayın ve adresi değil tuple'ı karşılaştırın. İstemcide, herhangi bir çeviriden önce:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

Ardından yönlendiricideki veya CGNAT ağ geçidindeki çeviri kaydını ve sonunda sunucuya ne ulaştığını okuyun:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

Uyuşmazlıkların çoğunu üç örüntü açıklar. Sunucudaki kaynak bağlantı noktası yerel bağlantı noktasından farklıyken hedef eşleşiyorsa: sıradan bağlantı noktası çevirisi. Sunucudaki kaynak adres sizin olmayan bir ISP bloğuna aitse: en az bir ek NAT katmanı. Paketler bir boşta kalma döneminden sonra durup yeni bir bağlantı noktasıyla devam ediyorsa: eşleme süresi doldu, yönlendirme hatası değil. Zaman damgaları bir veya iki saniyeden fazla ayrıysa iki farklı denemeyi karşılaştırıyorsunuz.

Farkın işleri bozduğu yer

Sunucu hatası gibi görünen kesintiler genellikle burada başlar. Ev adresinize sabitlenmiş bir erişim kuralı ISP kiralama süresi değiştikten sonra başarısız olur. Çevrilmiş bir adresle eşleşen fail2ban kuralı o ağ geçidinin arkasındaki tüm aboneleri bir anda engeller. Sabit uzak adresli bir site-site eşi mobil bağlantı değiştikten sonra anahtarları yenilemeyi bırakır. Tünel protokolü iyiydi; dış tuple hakkındaki varsayım değildi.

Aynı karışıklık sunucu tarafında da görülür. VPN kutusu kendisi NAT arkasındaysa bağlantı noktası yönlendirmesi ve çalışan bir yönlendirme yolu gerekir; strongSwan yönlendirme kılavuzu IPsec için bu durumu kapsar. Yalnızca özel bir adreste erişilebilen bir sunucu, istemcilerinin sunduğu çevrilmiş tuple'ı hiç görmez ve bu, istemcilerin çevrilmesinden farklı bir sorundur.

Bu dört denetimi sırayla yapın ve başarısız olan ilkinde durun:

• İki uçta aynı anda yakalayın; kaynak bağlantı noktası, hedef bağlantı noktası ve zaman damgalarının eşleştiğini doğrulayın.
• Sunucunun eş listesinde beklediğiniz adresi değil, şu anda tuttuğu adresi okuyun.
• Girdi ve kalan ömrü için conntrack veya NAT tablosunu kontrol edin.
• İstemcideki tünel arayüzü adresinin LAN adresiyle değil, sunucunun atadığı adresle eşleştiğini doğrulayın.

Her iki yakalama tuple üzerinde anlaşıyorsa ve tünel yine de başarısız oluyorsa, çeviri sizin sorununuz değildir; el sıkışmaya ve tünelin içindeki yönlendirme tablosuna geçin.