Linux-da IPsec olmadan L2TP: xl2tpd, pppd və NAT

Adi L2TP zərfin içindəki PPP-dir, başqa heç nə deyil. O, kadrlarınızı daşıyır; onları şifrələmir və digər ucda kimin oturduğunu sübut etmir, buna görə də demək olar ki, hər yerləşdirmə onun altına IPsec qoyur. Quru versiyanı işlətmək üçün dürüst səbəblər hələ də var: laboratoriya stendi, miqrasiya addımı və ya artıq başqa qorunan yolun içində olan əlaqə.

Əgər davam edirsinizsə, bu xəbərdarlığı dizayn qeydinə yazın və orada saxlayın. Bundan sonrası Debian və RHEL ailəsi hostlarda istifadə etdiyim əməliyyat yoludur: hansı fayl nəyə cavabdehdir, klassik dayanmanın qarşısını alan MTU və tuneli dəyərli edən yönləndirmə qaydaları.

Üç fayl işi bölür

xl2tpd nəzarət bağlantısını sonlandırır və hər sessiyanı PPP demonuna təhvil verir, buna görə konfiqurasiya bir-birinin fayllarını heç vaxt oxumayan iki proqram arasında bölünür. Dinləyici /etc/xl2tpd/xl2tpd.conf faylında, [lns default] bölməsinin içində yaşayır; həmin bölmə ünvan hovuzunu ip range ilə, server tərəfini local ip ilə və PPP-yə təhvil verməni pppoptfile ilə adlandırır. require authentication = yes seçimini yandırın, length bit və flow bit aktiv qalsın, hostda başqa heç nənin istifadə etmədiyi hovuz seçin.

PPP siyasəti həmin seçimin göstərdiyi faylda olur, adətən /etc/ppp/options.xl2tpd: auth, pap, chap və mschap üçün imtinalar, require-mschap-v2, 1460 MTU və MRU, və əlaqə qurulduqdan sonra müştərinin çata bildiyi DNS ünvanı. Etimad məlumatları yenə üçüncü fayldır, /etc/ppp/chap-secrets; orada ikinci sahə LNS bölmə adına uyğun olmalı, dördüncü sahə isə hovuzdan konkret ünvanı bərkidə bilər.

Tunel niyə qoşulur və sonra dayanır

1500 baytlıq Ethernet kadrı öz başlıqlarına artıq bayt xərcləyən yolun içinə sığmır. Xarici IPv4 başlığı 20, UDP 8, L2TP başlığı isə təxminən 12 bayt tutur və PPP ilə yükü üçün 1460 qalır. PPP-də məhz bu kiçik rəqəmin elan edilməsi böyük paketlərin parçalanmasının və ya ortada səssizcə atılmasının qarşısını alır.

Simptom real trafik gələnə qədər sağlam görünən tuneldir: pinglər və nəzarət mesajları keçir, fayl köçürməsi donur, jurnalda heç nə bunu izah etmir. MTU və MRU-nu hər iki ucda birlikdə aşağı salın. Yalnız müştərini düzəltmək adətən sərt dayanmanı arabir dayanmaya çevirir ki, bu da diaqnoz üçün daha pisdir.

Bir port iki söhbət daşıyır

UDP 1701 protokolun hər iki yarısının altındadır və bu tək fakt qurğunun hər hansı digər hissəsindən daha çox firewall qaydasını pozur. Əvvəlcə başlanğıc-nəzarət-bağlantısı sorğusu və cavabı gəlir; sonra gələn sessiya sorğusu və təsdiqi identifikator cütündən başqa heç nə qurmur. Sonra PPP özü idarəni götürür: əlaqə nəzarəti, sonra autentifikasiya, sonra ünvanları həll etmək üçün IP nəzarət protokolu. Hər mərhələnin jurnalda öz lüğəti var və heç biri özünü L2TP nasazlığı kimi elan etmir.

Çapı məhz bu sıra ilə oxumaq hansı mərhələnin uğursuz olduğunu deyir və PPP autentifikasiya nasazlığı xl2tpd-ni redaktə etməklə düzəlməz. Ortaq port başqa bir geniş yayılmış nasazlığı izah edir: axının yalnız ilk paketlərinə icazə verən qayda sessiyanın qurulmasına imkan verir, sonra ötürməni bloklayır. 1701-i bütün söhbət üçün, hər iki istiqamətdə açın.

Tuneli faydalı etmək: yönləndirmə və NAT

Sessiya özlüyündə yalnız serverə çatır. Müştərinin internetə çıxışı üçün yönləndirmə, uplinkdə hovuz üçün NAT qaydası və əlaqə qurulduqdan sonra müştərinin həqiqətən sorğu göndərə biləcəyi DNS lazımdır. Hovuz LAN diapazonundan kənarda qalmalıdır, əks halda müştərilərə ünvanlanmış cavablar tunelə geri itələnmək əvəzinə yerli olaraq çatdırılır.

Serverdə yönləndirməni sysctl -w net.ipv4.ip_forward=1 ilə aktivləşdirin, hovuzu iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE ilə çevirin, sonra -i ppp0 -o eth0 üçün FORWARD qaydası ilə çıxan tunel trafikini və güzgü qaydası üstəgəl -m state --state RELATED,ESTABLISHED ilə qayıdan trafiki qəbul edin. Bu qaydaları yenidən başlatmalar arasında saxlayın, çünki onlarsız qayıdan server məhz pozulmuş L2TP konfiqurasiyası kimi görünür.

Serverin öz LAN-na çatmaq ayrı vəzifədir: LAN marşrutlaşdırıcısında hovuz üçün geri marşrut əlavə edin və ya serverdə proxy ARP işə salın. LAN-ın içindəki bir şey müştərilərə birbaşa müraciət etməli olduğu halda onları NAT arxasında gizlətmək sadəcə sonraya ikinci bir sazlama sessiyası planlaşdırır.

Quru yığın nə etmir və necə yoxlamaq olar

Bu yığının heç bir hissəsi PPP kadrlarını şifrələmir və içində heç nə uzaq tərəfi həqiqətən seçdiyiniz server kimi autentifikasiya etmir. MS-CHAPv2 yalnız izləyən dinləyicidən etimad mübadiləsini qoruyur, lakin yolda yerləşən hücumçu yenə də sessiyaya müdaxilə edə bilər. Windows-un yerli müştərisi L2TP-ni yalnız IPsec ilə birlikdə təklif edir, buna görə peer-ləriniz kimi Linux, marşrutlaşdırıcı firmware-i və üçüncü tərəf müştərilərini nəzərdə tutun. Quru konfiqurasiyaya diaqnostik pillə kimi baxın, heç vaxt dayanacaq yer kimi deyil.

Sabit sıra ilə yoxlayın: xl2tpd -D əmrini ön planda işlədin, jurnalda PPP mərhələsini izləyin, hər iki ucda ip addr çıxışından təyin edilmiş ünvanı oxuyun, sonra sessiya qurulduqdan sonra məlumatın axdığını təsdiqləmək üçün UDP 1701-i tutun. Dördü də üst-üstə düşürsə və trafik yenə uğursuz olursa, qüsur L2TP-nin özündə deyil, marşrutlaşdırma, NAT və ya MTU-dadır.