L2TP/IPsec Neden IPsec'e Ek Olarak UDP 1701'e İhtiyaç Duyar

IKE ve ESP'ye izin verip UDP 1701'e izin vermeyen güvenlik duvarları, L2TP bağlantılarını kimlik bilgisi sorunu gibi görünen bir biçimde bozar. Bunun nedeni L2TP'nin birincinin içinde seyahat eden ikinci bir protokol olmasıdır. IPsec alışverişi taşır ve doğrular, L2TP ise UDP 1701 üzerinde kendi tünelini çalıştırır ve yerel yığın bunu yine de teslim etmelidir. Her başlığın nerede göründüğünü bilmek, hangi cihazın hangi kurala ihtiyacı olduğunu açıklar.

İki protokol, iki bağlantı noktası kümesi

Bir L2TP/IPsec bağlantısı UDP 500 üzerinde IKE, çeviri olan yerde UDP 4500 üzerinde NAT geçişi ve olmayan yerde IP protokolü 50 olarak ESP kullanır. L2TP'nin kendisi UDP 1701 üzerinde bir tünel protokolüdür ve IPsec karşı tarafı doğruladıktan sonra çalışır. İki yarı farklı biçimde başarısız olur ve bunları bildiren günlük satırları farklı bileşenlerden gelir. Yalnızca ilk yarıyı kapsayan bir kural kümesi, pazarlık yapıp ardından tünel aşamasında ölen bir bağlantı üretir.

Bağlantı noktası numaraları taşıma uç noktalarını tanımlar ve ESP hiç de bağlantı noktası değildir. Bu yüzden yalnızca TCP ve UDP kuralı sunan bir güvenlik duvarı arayüzü tam bir IPsec ilkesini ifade edemez. Protokol 50'nin protokol olarak izin verilmesi gerekir ve yalnızca UDP'den söz eden bir kural onunla asla eşleşmeyecektir.

Sarmalayıcı bağlantı noktasını açıklar

Kabloda, bir L2TP/IPsec bağlantısı genellikle 500 üzerinde IKE ve 4500 üzerinde sarmalanmış ESP gösterir. UDP 1701 başlığı korunan yükün içinde oturur, bu yüzden dış arayüzdeki bir yakalama onu göstermez. Yerel ana bilgisayar o veri birimini yine de L2TP artalan sürecine teslim etmelidir ve teslim çözümlemeden sonra gerçekleşir. Bu nedenle 1701 kuralı, hiçbir ara cihaz bağlantı noktasını hiç görmese bile uç noktanın kendi güvenlik duvarına aittir.

İşleme sırası karışıklığın çoğunu açıklar. Yığın IPsec ilkesini ana bilgisayar süzgecinden önce uygularsa, çözümlenmiş L2TP paketi UDP 1701 olarak eşleştirilir; sıra tersse kural kümesinin gördüğü dış bağlantı noktalarıdır. İki davranış da pratikte vardır, bu yüzden aynı kural kümesi bir platformda çalışıyor, diğerinde başarısız oluyor gibi görünür.

Yolu sırayla denetleyin

Önce dış arayüzde yakalama yapın ve IKE ile sarmalanmış ESP'nin iki yönde de hareket ettiğini doğrulayın. Ardından çözümlenmiş trafik için yerel güvenlik duvarı sayaçlarını denetleyin. Sıra önemlidir, çünkü hiçbir şey göstermeyen bir yakalama sorunun ana bilgisayarın yukarısında olduğu anlamına gelir.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

Yakalama alışverişin ilk yarısını doğrular ve karşı tarafın yanıt verip vermediğini gösterir. Kural listesi 1701 kuralının var olup olmadığını ve herhangi bir düşürme ilkesine göre nerede durduğunu gösterir. Soket listesi L2TP artalan sürecinin bağlı olduğunu ve dinlediğini doğrular; bu da hiç başlamamış bir hizmeti eler. Bir kuralı değiştirmeden önce üçünü de okuyun, çünkü eksik bir dinleyici ve süzülmüş bir bağlantı noktası kullanıcıdan aynı şikâyeti doğurur.

Bağlantı noktası taramasının gösteremeyeceği şey

Doğru yapılandırılmış bir sunucuya karşı UDP 1701'in dış taraması genellikle hiçbir şey bildirmez ve beklenen sonuç budur. Bağlantı noktası internete açık değildir; ona ancak IPsec karşı tarafı doğruladıktan sonra ulaşılır. Kapalı sonucu arıza saymak, kapalı kalması gereken bir bağlantı noktasını açmaya yol açar. Tarama, uygulama trafiğini göremediği kadar tünelin içini de göremez.

Bunun yerine gerçek bir istemciyle deneyin ve hangi aşamaya ulaştığını okuyun. Bağlantı pazarlık yapıp sonra takılırsa şüpheli L2TP artalan süreci ya da yerel süzgeçtir; hiç pazarlık yapmazsa dış bağlantı noktaları suçludur. Bu tek ayrım, hangi kuralın ekleneceğine dair tahminlerin çoğunu ortadan kaldırır ve protokol katmanlaması bunu gizemli olmaktan çıkarıp öngörülebilir kılar.