L2TP IPsec-ის გარეშე Linux-ზე: xl2tpd, pppd და NAT

შიშველი L2TP არის PPP კონვერტში და მეტი არაფერი. ის ატარებს თქვენს კადრებს; არ შიფრავს მათ და არ ამტკიცებს, ვინ ზის მეორე მხარეს, ამიტომ თითქმის ყველა განლაგება მის ქვეშ IPsec-ს დებს. შიშველი ვერსიის გაშვების პატიოსანი მიზეზები ჯერ კიდევ არსებობს: ლაბორატორიული სკამი, მიგრაციის საფეხური ან კავშირი, რომელიც უკვე სხვა დაცული გზის შიგნითაა.

თუ მაინც გააგრძელებთ, ჩაწერეთ ეს გაფრთხილება დიზაინის ჩანაწერში და იქვე დატოვეთ. შემდეგი არის ოპერაციული გზა, რომელსაც Debian-ისა და RHEL-ის ოჯახის ჰოსტებზე ვიყენებ: რომელი ფაილი რაზეა პასუხისმგებელი, MTU, რომელიც კლასიკურ გაჩერებას ხელს უშლის, და გადამისამართების წესები, რომლებიც გვირაბს ღირებულს ხდის.

სამი ფაილი იყოფს სამუშაოს

xl2tpd ამთავრებს კონტროლის კავშირს და ყოველ სესიას PPP დემონს გადასცემს, ამიტომ კონფიგურაცია ორ პროგრამაზეა განაწილებული, რომლებიც ერთმანეთის ფაილებს არასდროს კითხულობენ. მსმენელი ცხოვრობს /etc/xl2tpd/xl2tpd.conf-ში, [lns default] სექციის შიგნით, რომელიც მისამართების აუზს ip range-ით, სერვერის მხარეს local ip-ით და PPP-ზე გადაცემას pppoptfile-ით ასახელებს. ჩართეთ require authentication = yes, დატოვეთ length bit და flow bit ჩართული და აირჩიეთ აუზი, რომელსაც ჰოსტზე სხვა არაფერი იყენებს.

PPP პოლიტიკა ეკუთვნის იმ ფაილს, რომელსაც ეს პარამეტრი ასახელებს, ჩვეულებრივ /etc/ppp/options.xl2tpd-ს: auth, უარები pap-ისთვის, chap-ისთვის და mschap-ისთვის, require-mschap-v2, 1460-ის MTU და MRU, და DNS მისამართი, რომელსაც კლიენტი კავშირის აწევის შემდეგ მიაღწევს. სერთიფიკატები ისევ მესამე ფაილია, /etc/ppp/chap-secrets, სადაც მეორე ველი LNS სექციის სახელს უნდა შეესაბამებოდეს, ხოლო მეოთხე ველს შეუძლია აუზიდან კონკრეტული მისამართის მიმაგრება.

რატომ უკავშირდება გვირაბი და შემდეგ იკიდებს

1500 ბაიტიანი Ethernet კადრი არ ეტევა გზაში, რომელიც უკვე ხარჯავს ბაიტებს საკუთარ თავსართებზე. გარე IPv4 სათაური 20-ს ხარჯავს, UDP — 8-ს, ხოლო L2TP სათაური დაახლოებით 12-ს, რაც PPP-სა და მის დატვირთვას 1460-ს უტოვებს. სწორედ ამ პატარა რიცხვის გამოცხადება PPP-ში უშლის ხელს დიდი პაკეტების დაყოფას ან სადღაც შუაში ჩუმად დაკარგვას.

სიმპტომია გვირაბი, რომელიც ჯანმრთელად გამოიყურება ნამდვილი ტრაფიკის მოსვლამდე: ping-ები და კონტროლის შეტყობინებები გადის, ფაილის კოპირება იკიდებს, ჟურნალში ვერაფერი ხსნის მას. შეამცირეთ MTU და MRU ერთად ორივე ბოლოში. მხოლოდ კლიენტის მორგება, ჩვეულებრივ, მკვეთრ გაჩერებას წყვეტილად აქცევს, რაც დიაგნოსტიკისთვის უარესია.

ერთი პორტი ორ საუბარს ატარებს

UDP 1701 პროტოკოლის ორივე ნახევრის ქვეშ ზის და ეს ერთი ფაქტი უფრო მეტ ფაირვოლის წესს არღვევს, ვიდრე დაყენების ნებისმიერი სხვა ნაწილი. ჯერ მოდის კონტროლის კავშირის დაწყების მოთხოვნა და მისი პასუხი; შემდეგ სესიის მოთხოვნა და დადასტურება იდენტიფიკატორთა წყვილზე მეტს არაფერს ამყარებს. შემდეგ PPP იღებს სადავეებს: კავშირის კონტროლი, შემდეგ აუთენტიფიკაცია, შემდეგ IP კონტროლის პროტოკოლი მისამართების შესათანხმებლად. ყოველ საფეხურს ჟურნალში საკუთარი ლექსიკა აქვს და არც ერთი მათგანი თავს L2TP-ის უკმარისობად არ აცხადებს.

ჩანაწერის ზუსტად ამ თანმიმდევრობით კითხვა გეუბნებათ, რომელი საფეხური ჩავარდა, ხოლო PPP აუთენტიფიკაციის ჩავარდნას xl2tpd-ის რედაქტირება არ გამოასწორებს. საერთო პორტი კიდევ ერთ ჩვეულებრივ უკმარისობას ხსნის: წესი, რომელიც მხოლოდ ნაკადის პირველ პაკეტებს უშვებს, სესიას აყალიბებს და შემდეგ გადაცემას ბლოკავს. დაუშვით 1701 მთელი საუბრისთვის, ორივე მიმართულებით.

გვირაბის სასარგებლოდ ქცევა: გადამისამართება და NAT

სესია თავისთავად მხოლოდ სერვერამდე აღწევს. კლიენტის ინტერნეტ წვდომას სჭირდება გადამისამართება, NAT წესი აუზისთვის აღმავალ კავშირზე და DNS, რომელსაც კლიენტი კავშირის აწევის შემდეგ ნამდვილად შეეკითხება. აუზი ასევე უნდა დარჩეს LAN-ის დიაპაზონის გარეთ, თორემ კლიენტებისთვის მიმართული პასუხები ლოკალურად მიეწოდება, ნაცვლად იმისა, რომ გვირაბში უკან გაიწიოს.

სერვერზე ჩართეთ გადამისამართება sysctl -w net.ipv4.ip_forward=1-ით, გადათარგმნეთ აუზი iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE-ით, შემდეგ მიიღეთ გამავალი გვირაბის ტრაფიკი FORWARD წესით -i ppp0 -o eth0-ისთვის და დაბრუნებული ტრაფიკი სარკისებური წესით პლუს -m state --state RELATED,ESTABLISHED. გახადეთ ეს წესები გამძლე გადატვირთვებს შორის, რადგან სერვერი, რომელიც მათ გარეშე ბრუნდება, ზუსტად გატეხილ L2TP კონფიგურაციას ჰგავს.

თავად სერვერის LAN-ზე მისვლა სხვა ამოცანაა: დაამატეთ დაბრუნების მარშრუტი აუზისთვის LAN-ის როუტერზე, ან proxy ARP სერვერზე. კლიენტების NAT-ის უკან დამალვა მაშინ, როცა LAN-ის შიგნით რაღაცას პირდაპირ უნდა მიმართოს მათ, მხოლოდ მეორე გამართვის სესიას გეგმავს მოგვიანებით.

რას არ აკეთებს შიშველი სტეკი და როგორ შევამოწმოთ

ამ სტეკის არც ერთი ნაწილი არ შიფრავს PPP კადრებს და მასში არაფერი ადასტურებს შორეულ მხარეს იმ სერვერად, რომელიც თქვენ ნამდვილად აირჩიეთ. MS-CHAPv2 მართლაც იცავს სერთიფიკატების გაცვლას მხოლოდ დამკვირვებელი მსმენელისგან, მაგრამ გზაზე მოთავსებულ თავდამსხმელს მაინც შეუძლია სესიაში ჩარევა. Windows-ის მშობლიური კლიენტი L2TP-ს მხოლოდ IPsec-თან ერთად გთავაზობთ, ამიტომ გაითვალისწინეთ Linux, როუტერების firmware და მესამე მხარის კლიენტები როგორც თქვენი პარტნიორები. მოეპყარით შიშველ კონფიგურაციას როგორც დიაგნოსტიკურ საფეხურს, არასდროს როგორც გაჩერების ადგილს.

შეამოწმეთ ფიქსირებული თანმიმდევრობით: გაუშვით xl2tpd -D წინა პლანზე, დააკვირდით ჟურნალს PPP საფეხურისთვის, წაიკითხეთ მინიჭებული მისამართი ip addr-იდან ორივე ბოლოში, შემდეგ დაიჭირეთ UDP 1701, რათა დაადასტუროთ, რომ მონაცემები მიედინება სესიის აწევის შემდეგ. თუ ოთხივე ემთხვევა და ტრაფიკი მაინც ვერ გადის, ბრალი მარშრუტიზაციაში, NAT-ში ან MTU-შია და არა თავად L2TP-ში.