NAT üzerinden L2TP/IPsec: gerçekte ne kırılır ve neden

NAT'ın L2TP/IPsec'i kırdığı iddiası yarı doğrudur ve bu yüzden işe yaramaz. Adres çevirisi normaldir, NAT traversal tam da onu atlatmak için vardır ve her gün milyonlarca istemci bir yönlendiricinin arkasından bağlanır. Kırılan şey belirli bir alışverişin belirli bir aşamasıdır: IKE hiç yanıt almaz, kapsüllenmiş tünel yalnızca tek bir protokole izin veren bir politikayla düşürülür veya tünel boştayken çeviri eşlemesi sona erer. Hangi aşamada olduğunuzu bildiğinizde düzeltme genellikle tek bir kural veya bir keepalive olur, yeni bir VPN tasarımı değil.

Efsane yanlış sorudur

Yararlı soru «NAT bunu kırar mı» değil, «alışverişin hangi kısmı çevriliyor ve çeviren cihaz onunla ne yapıyor» sorusudur. L2TP/IPsec katmanlı bir protokoldür: IKE pazarlık eder, ESP korur ve L2TP o korumanın içinde PPP taşır. Adres çevirisi her katmanı farklı etkiler ve hata imzaları, hata penceresine değil pazarlık aşamasına bakarsanız ayırt edilebilir.

Web'de sorunsuz gezinen bir yönlendirici yalnızca kaynak bağlantı noktası çevirisiyle TCP'nin çalıştığını kanıtlar. UDP 500, UDP 4500 veya protokol 50 hakkında hiçbir şey söylemez ve bu kurulum tam olarak o üç şeye bağlıdır.

Aşama 1: IKE her şeyden önce yanıt almalı

İlk alışveriş UDP 500 üzerinden yanıtlayıcıya gider. Hiç yanıt dönmezse başka hiçbir şey önemli değildir: önceden paylaşılan anahtar, öneri ve kimlik bilgileri okunmadan kalır. İstemcinin zaman aşımından tahmin yürütmek yerine isteği ve yanıtı izleyin:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Yanıtsız bir istek genellikle bir güvenlik duvarının veya yukarıdaki operatörün paketi attığı anlamına gelir, sunucunun reddettiği değil. Öneri veya sertifika sorunu belirten bir bildirim yüküyle gelen yanıt, paketlerin ulaştığı ve pazarlığın içerik yüzünden başarısız olduğu anlamına gelir; bu tamamen başka bir onarımdır.

Her iki taraf da çevirinin arkasındaysa başlatan yalnızca yanıtlayıcıya ulaşmalıdır, bu yüzden istemci tarafındaki kurulumların çoğu aşama 1'den itibaren çalışır. Sunucu tarafında barındırma, gelen trafik sorununun başladığı yerdir ve bu yüzden iki durum asla tek bir durum olarak tartışılmamalıdır.

Aşama 2: kapsülleme güvenlik duvarının gördüğünü değiştirir

ESP bir IP protokolüdür, TCP veya UDP bağlantı noktası değildir ve olağan bağlantı noktası adres çevirisinde yeniden yazılacak bir bağlantı noktası alanı yoktur. Bu yüzden NAT traversal korunan yükü UDP 4500 içine taşır: kapsülleme, çeviren cihaza nasıl çevireceğini bildiği bir şey verir. Bu olduğunda, yalnızca UDP 500 için yazılmış bir güvenlik duvarı kuralı pazarlığa izin verip tüneli düşürür, bu da günlüğün başarılı 1. fazı ve hiç trafik olmadığını gösterdiği kafa karıştırıcı sonucu üretir.

IKE alışverişinin kendisi de NAT algılandıktan sonra UDP 4500'e geçebilir; bu, yalnızca 500'e izin verenleri şaşırtır. Yolda iki bağlantı noktasına da iki yönde izin verin ve durum tutan bir güvenlik duvarının akışı yalnızca trafik gördüğü sürece tuttuğunu unutmayın.

Protokol 50 çeviri olmayan yollarda ve ara kutunun izin vermek için yapılandırıldığı yollarda hâlâ önemlidir. Eleme yoluyla teşhis yapıyorsanız, kuralları topluca eklemek yerine varsayımı kapatın: 500, 4500 ve ESP'ye izin verin, tünelin kalktığını doğrulayın, sonra gereksiz çıkanı kaldırın. Kimsenin açıklayamadığı bir kural, bir sonraki kesintinin nedeni olduğunda kimsenin kaldırmayacağı bir kuraldır. Daraltmayı, düzelttiği aşamayla birlikte değişiklik kaydına yazın ki bir sonraki mühendis aynı pratik kuraldan değil sizin kanıtlarınızdan başlasın.

Aşama 3: eşleme sona erer ve tünel ölür

Çeviren cihaz ilettiği akışlar için durum tutar ve bu durumun bir ömrü vardır. L2TP/IPsec tüneli kimse kullanmadığında az trafik taşır, bu yüzden boştaki bir tünel eşlemesinden daha uzun yaşayabilir ve dönüş trafiği almayı bırakabilir. İstemci bağlı olduğuna inanmaya devam eder, sunucu hiçbir şey görmez ve ilk belirti genellikle bir uygulama zaman aşımıdır, VPN hatası değil.

Ölü eş algılama ve NAT keepalive'ları bunun içindir ve iki uç da bunları göndermeye istekli olmalıdır. Sunucunuz çevirinin arkasındaysa Windows tarafındaki gereksinim, sunucunun kendi giden paketleri için UDP kapsüllemesi varsaymasını sağlayan belgelenmiş bir kayıt defteri ayarıdır; o olmadan yanıtlayıcı, çeviren cihazın geri eşleyemediği ESP gönderir. Bu bir sunucu yapılandırması sorunudur, istemci sorunu değil.

WAN adresinin değişmesi aynı sonucu başka bir yönden verir: eşleme yeni bir adres etrafında yeniden kurulur ve eski güvenlik ilişkilendirmesi artık var olmayan bir demeti gösterir. Yeniden bağlanma davranışı istemci uygulamasına aittir, bu yüzden «yönlendirici yeniden başladıktan sonra yeniden bağlan» bir istemcide çalışır, diğerinde elle düğme gerekir.

Operatör düzeyinde NAT arkasında barındırma başka bir sorundur

Evde bir L2TP/IPsec sunucusu barındırıp ona dışarıdan ulaşmak istiyorsanız gereksinim, istenmeyen gelen erişilebilirliktir ve NAT traversal bunu sağlamaz. Yönlendiricinizin önünde operatör düzeyinde NAT olması, sizi erişilebilir kılacak yönlendirebileceğiniz hiçbir bağlantı noktası olmadığı anlamına gelir, çünkü genel adres paylaşılır ve eşleme yalnızca gidendir.

Hiçbir IPsec pass-through kutusu bunu değiştirmez ve hiçbir istemci yapılandırması bunu telafi etmez. Desteklenen yanıtlar gerçekten erişilebilir bir adres, barındırılan bir uç nokta veya her katılımcının giden bağlantı kurduğu bir mimaridir. UDP kapsülleme belirtimi var olan akışlar için çeviri sorununu çözer; operatörün sunmadığı yerde gelen yol oluşturmaz.

Bu yüzden tahmin etmek yerine ağları karşılaştırın. Aynı cihazı ve profili başka bir izin verilen ağa götürün ve orada hangi aşamanın başarısız olduğuna bakın. Başka yerde çalışıyorsa fark yoldadır ve bu, aramayı tüm yapılandırma yerine yukarıdaki üç aşamaya daraltır.