Linux'ta IPsec olmadan L2TP: xl2tpd, pppd ve NAT

Yalın L2TP, bir zarf içindeki PPP'dir ve başka bir şey değildir. Çerçevelerinizi taşır; onları şifrelemez ve diğer uçta kimin oturduğunu kanıtlamaz, bu yüzden neredeyse her kurulum altına IPsec koyar. Çıplak sürümü çalıştırmak için dürüst nedenler hâlâ var: bir laboratuvar tezgâhı, bir geçiş adımı veya zaten başka bir korumalı yolun içinde olan bir bağlantı.

Yine de devam edecekseniz, bu uyarıyı tasarım notuna yazın ve orada bırakın. Aşağıdakiler Debian ve RHEL ailesi ana makinelerde kullandığım işletim yoludur: hangi dosya neyden sorumlu, klasik takılmayı önleyen MTU ve tüneli değerli kılan yönlendirme kuralları.

Üç dosya işi paylaşır

xl2tpd denetim bağlantısını sonlandırır ve her oturumu bir PPP daemonuna devreder, bu yüzden yapılandırma birbirinin dosyalarını asla okumayan iki program arasında dağılır. Dinleyici /etc/xl2tpd/xl2tpd.conf içinde, adres havuzunu ip range ile, sunucu ucunu local ip ile ve PPP'ye devri pppoptfile ile adlandıran [lns default] bölümünün içinde yaşar. require authentication = yes ayarını açın, length bit ve flow bit etkin kalsın ve ana makinede başka hiçbir şeyin kullanmadığı bir havuz seçin.

PPP ilkesi o seçeneğin adlandırdığı dosyaya aittir, genellikle /etc/ppp/options.xl2tpd: auth, pap, chap ve mschap için reddetmeler, require-mschap-v2, 1460 MTU ve MRU ile bağlantı açıldıktan sonra istemcinin ulaşabileceği bir DNS adresi. Kimlik bilgileri yine üçüncü bir dosyadır, /etc/ppp/chap-secrets; orada ikinci alan LNS bölüm adıyla eşleşmeli ve dördüncü alan havuzdan belirli bir adresi sabitleyebilir.

Tünel neden bağlanır ve sonra takılır

1500 baytlık bir Ethernet çerçevesi, kendi başlıklarına zaten bayt harcayan bir yolun içine sığmaz. Dış IPv4 başlığı 20, UDP 8 ve L2TP başlığı yaklaşık 12 bayt tutar; PPP ve yükü için 1460 kalır. PPP'de bu daha küçük sayıyı duyurmak, büyük paketlerin parçalanmasını veya yolun ortasında sessizce düşmesini engeller.

Belirti, gerçek trafik gelene kadar sağlıklı görünen bir tüneldir: pingler ve denetim iletileri geçer, bir dosya kopyası takılır, günlükte hiçbir şey bunu açıklamaz. MTU ve MRU'yu iki uçta birlikte düşürün. Yalnızca istemciyi ayarlamak genellikle sert takılmayı aralıklı bir takılmaya çevirir; bu da tanılaması daha zordur.

Bir bağlantı noktası iki konuşma taşır

UDP 1701 protokolün iki yarısının da altındadır ve bu tek gerçek, kurulumun herhangi bir parçasından daha fazla güvenlik duvarı kuralını bozar. Önce denetim bağlantısı başlatma isteği ve yanıtı gelir; ardından gelen oturum isteği ve onayı tanımlayıcı çiftinden fazlasını kurmaz. Sonra PPP devralır: bağlantı denetimi, ardından kimlik doğrulama, ardından adresleri kararlaştırmak için IP denetim protokolü. Her aşamanın günlükte kendi sözlüğü vardır ve hiçbiri kendini L2TP arızası olarak duyurmaz.

Bir kaydı tam olarak bu sırayla okumak hangi aşamanın başarısız olduğunu söyler ve PPP kimlik doğrulama arızası xl2tpd düzenlenerek giderilmez. Paylaşılan bağlantı noktası bir başka yaygın arızayı açıklar: bir akışın yalnızca ilk paketlerine izin veren kural, oturumun kurulmasına izin verip sonra aktarımı engeller. Tüm konuşma için 1701'e iki yönde de izin verin.

Tüneli kullanışlı kılmak: yönlendirme ve NAT

Oturum kendi başına yalnızca sunucuya ulaşır. İstemcilerin internet erişimi yönlendirme, üst bağlantıda havuz için bir NAT kuralı ve bağlantı açıldıktan sonra istemcinin gerçekten sorgulayabileceği DNS gerektirir. Havuz ayrıca LAN aralığının dışında kalmalıdır, yoksa istemcilere gönderilen yanıtlar tünele geri itilmek yerine yerel olarak teslim edilir.

Sunucuda yönlendirmeyi sysctl -w net.ipv4.ip_forward=1 ile açın, havuzu iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE ile çevirin, sonra -i ppp0 -o eth0 için FORWARD kuralıyla giden tünel trafiğini ve ayna kuralıyla birlikte -m state --state RELATED,ESTABLISHED ile dönen trafiği kabul edin. Bu kuralları yeniden başlatmalar arasında kalıcı yapın, çünkü onlar olmadan geri gelen bir sunucu tam olarak bozuk bir L2TP yapılandırması gibi görünür.

Sunucunun kendi LAN'ına ulaşmak başka bir iştir: LAN yönlendiricisinde havuz için bir dönüş yolu ekleyin veya sunucuda proxy ARP kullanın. LAN içindeki bir şey istemcilere doğrudan hitap etmek zorundayken onları NAT arkasına saklamak yalnızca daha sonrası için ikinci bir hata ayıklama oturumu planlar.

Çıplak yığının yapmadıkları ve nasıl doğrulanacağı

Bu yığının hiçbir parçası PPP çerçevelerini şifrelemez ve içindeki hiçbir şey uzak ucu gerçekten seçtiğiniz sunucu olarak doğrulamaz. MS-CHAPv2 kimlik bilgilerinin değişimini yalnızca izleyen bir dinleyiciden korur, ama yolun üzerine yerleştirilmiş bir saldırgan yine de oturuma müdahale edebilir. Windows'un yerel istemcisi L2TP'yi yalnızca IPsec ile birlikte sunar, bu yüzden Linux, yönlendirici yazılımı ve üçüncü taraf istemcileri karşı tarafınız olarak hesaba katın. Çıplak yapılandırmayı bir tanılama basamağı olarak görün, asla durulacak yer olarak değil.

Sabit bir sırayla doğrulayın: xl2tpd -D komutunu ön planda çalıştırın, PPP aşaması için günlüğü izleyin, atanan adresi iki uçta ip addr çıktısından okuyun, sonra oturum açıldıktan sonra verinin aktığını doğrulamak için UDP 1701'i yakalayın. Dördü de eşleşiyor ama trafik yine başarısız oluyorsa hata yönlendirme, NAT veya MTU'dadır, L2TP'nin kendisinde değil.