TCP MSS-ის დაყენება Linux IPsec კარიბჭეზე: რას ასწორებს ის

Ping მუშაობს, SSH მუშაობს, პატარა გვერდი იტვირთება, და შემდეგ ყოველი დიდი პასუხი ჩერდება ვადის გასვლამდე. კლასიკური ნიმუში პაკეტის ზომაზე მიუთითებს და არა ხელმისაწვდომობაზე: გზა ატარებს ხელის ჩამორთმევას და პირველ რამდენიმე კილობაიტს, შემდეგ სრული ზომის სეგმენტი ქრება. Linux IPsec კარიბჭეზე TCP MSS წესი ხშირად გამოსავალია, მაგრამ მხოლოდ მაშინ, თუ გესმით, რას ცვლის ის და სად არის სინამდვილეში ის პაკეტი, რომელსაც ის ეხება. ქვემოთ მოცემული თანმიმდევრობა პაკეტს მიჰყვება სიმპტომიდან წესის განთავსებამდე, რათა შეწყვიტოთ მაშინვე, როცა ახსნა აღარ ერგება.

სიმპტომი, რომელიც MSS-ზე მიუთითებს

TCP ხელის ჩამორთმევისას სეგმენტის მაქსიმალურ ზომაზე შეთანხმდება. თუ ეს მნიშვნელობა მეტია იმაზე, რისი გადატანაც გზას ინკაფსულაციის შემდეგ შეუძლია, გამომგზავნი აგრძელებს სეგმენტების შექმნას, რომლებიც არასოდეს აღწევს, და კავშირი პირველი რაუნდის შემდეგ ჩერდება. პატარა პასუხები ეტევა; დიდი არა.

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

რას აკეთებს TCPMSS წესი და რას არა

წესი გადაწერს MSS პარამეტრს TCP-ის ხელის ჩამორთმევის პაკეტებში მათი გავლისას. ის არ ადგენს გვირაბის ინტერფეისის MTU-ს, არ ცვლის IPsec პოლიტიკას, და მიმდინარე ბირთვებზე მხოლოდ ამცირებს გამოცხადებულ მნიშვნელობას უკვე უფრო პატარას გაზრდის ნაცვლად. ის ასევე მხოლოდ TCP-ს ეხება; UDP დატვირთვები, DNS-ის ქცევა და შეთანხმებული ტრაფიკის სელექტორები მისი მიღწევის მიღმაა.

რადგან ცვლილება ხელის ჩამორთმევის დროს ხდება, წესამდე დამყარებული არსებული კავშირი თავის ძველ მნიშვნელობას ინარჩუნებს. შეამოწმეთ ახალი კავშირით და დაელოდეთ, რომ ცვლილების შემდეგ პირველი მცდელობა იქნება ის, რაც რამეს გეტყვით. წესში არაფერი აღწევს უკვე ღია კავშირამდე. ამიტომ ინციდენტის შუაში გამოყენებული შესწორება შეიძლება ისე გამოიყურებოდეს, თითქოს საერთოდ არაფერი გაუკეთებია.

მოათავსეთ წესი შიდა TCP გზაზე

პოლიტიკაზე დაფუძნებულ Linux კარიბჭეზე გადაგზავნილი პაკეტი კვლავ ჩვეულებრივ TCP-ს ჰგავს, როცა firewall მას ხედავს. IPsec პოლიტიკა წყვეტს, რომ პაკეტი დაცული იქნება; firewall შიდა ნაკადისთვის ESP სათაურს არ ხედავს, ამიტომ აქ ESP-თან შედარება სულ სხვა პაკეტს აღწერს. სწორედ ეს შეუსაბამობაა მიზეზი იმისა, რომ ზოგი წესი სწორად გამოიყურება და არასოდეს ემთხვევა.

iptables-ის ტერმინებში წესი გადაგზავნის გზის mangle ცხრილს ეკუთვნის, შემოიფარგლება ხელის ჩამორთმევის პაკეტებით: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270. რიცხვი მაგალითია, არა უნივერსალური მუდმივა; გამოიყვანეთ ის ინკაფსულაციის დანახარჯიდან და გზის რეალური MTU-დან. nftables-ის ეკვივალენტი მაქსიმალურ სეგმენტის ზომას forward ან postrouting ჯაჭვში ადგენს.

IKE-სა და ESP-ის გარე მოსმენის წესები შიდა გადაგზავნის წესებისგან განაცალკევეთ. ერთი წესი, რომელიც აპლიკაციის ნაკადისა და გარე პროტოკოლის ორივეს ავტორიზაციას ცდილობს, საბოლოოდ არც ერთთან საიმედოდ არ ემთხვევა.

პატივი ეცით firewall-ის მფლობელსა და NAT-ის თანმიმდევრობას

თუ UFW ფლობს ჰოსტის firewall-ს, დაამატეთ mangle-ისა და გადაგზავნის ცვლილებები მისი მხარდაჭერილი მუდმივი კონფიგურაციის გავლით, ნაცვლად იმისა, რომ აკრიფოთ ბრძანება, რომელიც შემდეგ გადატვირთვაზე გაქრება. არასწორ ცხრილში ან საბოლოო წესის შემდეგ ჩასმულ წესს არავითარი ეფექტი არ აქვს, და მოქმედი ცხრილი ამას თქვენგან მალავს.

წყაროს თარგმნა ცალკე გადაწყვეტილებაა, რომელიც ხშირად ამ ერთთან ურთიერთქმედებს. ზოგადი masquerade წესის წინ მოთავსებული გამონაკლისი ხელს უშლის დაცულ ტრაფიკს დაკარგოს ის წყარო, რომელსაც მისი პოლიტიკა ითხოვს; ის ზომის პრობლემას არ ასწორებს, და ზომის წესი თარგმნის პრობლემას არ ასწორებს.

ვიწროდ შეამოწმეთ, შემდეგ გაჩერდით

გახსენით ახალი კავშირი წარუმატებელ სერვისთან და დააკვირდით როგორც აპლიკაციას, ისე წესის მთვლელებს. თუ ჩერდომა გაქრა, გაქვთ მტკიცებულება იმ TCP გზის შესახებ იმ ინკაფსულაციით. არ გაქვთ მტკიცებულება, რომ ყოველი VPN პროტოკოლი ერგება, ყოველი UDP აპლიკაცია გასწორდა, ან რომ კონკრეტული ზედა დინების სერვისი იყო თავდაპირველი მიზეზი.

სადაც პოლიტიკა ნებას რთავს, ICMP ზომის უკუკავშირი იმუშაოს, და ფრთხილად მოეკიდეთ გზის MTU-ზე დაფუძნებულ ავტომატურ შეზღუდვას, როცა გარე IPsec გზა შიდა მარშრუტით არ არის წარმოდგენილი. რაც უფრო ვიწროა დასკვნა, მით უფრო ადვილია შემდეგი ინციდენტის დიაგნოსტიკა.