რატომ კარგავს ოფისის ლოკალურ ქსელში VPN კლიენტი ყველა პასუხს
ლეპტოპი ოფისის ლოკალურ ქსელში და იმავე ქვექსელის გვირაბში არასწორი ინტერფეისიდან პასუხობს. ფხვიერი უკუგზის ფილტრაცია ხსნის ამ სიჩუმეს.
ლეპტოპი Ethernet-ით ზის ოფისის /24-ში და ამავე დროს უერთდება OpenVPN სერვერს, რომელიც იმავე /24-ში ცხოვრობს. კოლეგა გვირაბის მისამართზე ping-ს აკეთებს; მოთხოვნა აშკარად აღწევს და უკან არაფერი ბრუნდება. გვირაბის ჟურნალი სუფთაა და დათვალიერება ჯერ კიდევ მუშაობს, ამიტომ გვირაბი არასწორი ეჭვმიტანილია. IPv4 წყაროს ვალიდაცია მიმღებ მანქანაში აგდებს პაკეტს, სანამ რამე წაიკითხავს მას.
გადაგდება ხდება მანამ, სანამ რამე წაიკითხავს პაკეტს
წყაროს ვალიდაცია ერთ კითხვას სვამს ყოველ შემავალ პაკეტზე: თუ ეს ჰოსტი უპასუხებდა იმ წყაროს, გავიდოდა პასუხი იმ ინტერფეისიდან, რომლიდანაც პაკეტი ახლახან შემოვიდა? როცა პასუხი არაა, ბირთვი პაკეტს ჩამოსვლისთანავე აგდებს. არც სოკეტი და არც გადაცემის გზა ვერასოდეს ხედავს მას, ამიტომ გვირაბზე გაკეთებული ჩაწერა მაინც აღრიცხავს მოთხოვნას, რომელსაც აპლიკაცია არასოდეს იღებს.
კლიენტი აქ გვირაბზე ფლობს 10.66.0.9-ს, და OpenVPN სერვერი პასუხობს 192.168.80.10-იდან ოფისის პრეფიქსის შიგნით. კოლეგა 192.168.80.25-ზე გვირაბის მისამართზე ping-ს აკეთებს, ამიტომ მოთხოვნა გადაკვეთს ლოკალურ ქსელს, სერვერი მას გვირაბში მიმართავს და ის ოფისის წყაროს მისამართით აღწევს კლიენტის გვირაბის ინტერფეისზე. იმ მანქანის მარშრუტიზაციის ცხრილში ოფისის პრეფიქსი Ethernet მოწყობილობას ეკუთვნის, არა გვირაბს. ვალიდაცია ადარებს ჩამოსვლის ინტერფეისს მარშრუტს, პოულობს შეუსაბამობას და აგდებს პაკეტს, ამიტომ კოლეგა ხედავს სრულ დანაკარგს, მაშინ როცა ორივე ბოლო იტყობინება ჯანმრთელ გვირაბზე.
სარკისებურ მიმართულებას იგივე ფორმა აქვს: როცა კლიენტი ოფისისკენ იწყებს, პასუხები შეიძლება ოფისის მხარეს იქნას გადაგდებული იმავე მიზეზით. მხოლოდ ერთი მიმართულებით შემოწმებული შესწორება ჩვეულებრივ მეორე ბილეთად ბრუნდება.
დაამტკიცეთ მოქმედი რეჟიმი, სანამ რომელიმე sysctl-ს შეეხებით
წაიკითხეთ ეფექტური მნიშვნელობები დისტრიბუციის ნაგულისხმევის ნდობის ნაცვლად, რადგან ინტერფეისის პარამეტრი გადაწყვეტილების მხოლოდ ნახევარია. მოქმედი რეჟიმი ინტერფეისის მნიშვნელობასა და all მნიშვნელობას შორის უფრო მაღალია, ამიტომ გვირაბის ინტერფეისზე ნული არაფერს ნიშნავს, სანამ all ერთია. მკაცრი რეჟიმის გადაწყვეტილება მარშრუტიზაციის გადაწყვეტილებაა, ამიტომ გაუშვით ის ძიება, რომელსაც ბირთვი უშვებს, და შეადარეთ მისი პასუხი იმ ინტერფეისს, რომლიდანაც პაკეტი რეალურად შემოვიდა.
tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filterშემდეგ გაიმეორეთ ping შეცდომების მთვლელზე დაკვირვებით. მთვლელი, რომელიც იზრდება იმ მოთხოვნის გვერდით, რომელსაც ჩაწერა უკვე აჩვენებს, სწორედ ამ გადაგდების ხელმოწერაა, არა დაკარგული მარშრუტის. ჩართეთ მარსის პაკეტების ჟურნალი, სანამ იქ ხართ, რათა ბირთვმა დაასახელოს ის წყარო და ინტერფეისი, რომელიც უარყო. ერთად ისინი გამორიცხავენ შიფრს, ცეცხლგალავანს და დაკარგულ iroute-ს, როგორც ახსნებს.
ჩამოწერეთ საბაზისო ხაზი, სანამ რამეს შეცვლით: ორივე მნიშვნელობა, მოწყობილობა, რომელიც ძიებამ აირჩია, და მთვლელი, რომელსაც აკვირდებოდით. სწორედ ეს ჩანაწერი გეტყვით მოგვიანებით, გააკეთა თუ არა ცვლილებამ ის, რაც გგონიათ.
რას იღებს სინამდვილეში rp_filter-ის თითოეული რეჟიმი
ბირთვი აჩვენებს სამ მნიშვნელობას თითოეულ ინტერფეისზე და ეს არ არის ერთი წესის სამი ელფერი. ნული გამორთავს შემოწმებას. ერთი მკაცრია და მოითხოვს, რომ წყარო უკან გამარშრუტდეს ჩამოსვლის ინტერფეისით. ორი ფხვიერია და მხოლოდ იმას მოითხოვს, რომ ცხრილში არსებობდეს რაიმე მარშრუტი წყაროსკენ, სადაც არ უნდა მიუთითოს.
| Value | Name | Accepts | Still rejects |
|---|---|---|---|
| 0 | off | any source at all | nothing on this check |
| 1 | strict | a source routed back out the arrival interface | a source whose route points elsewhere |
| 2 | loose | a source with any route in the table | a source with no route at all |
აქ მთავარი ხაზი ფხვიერია, და ის, რასაც ის კვლავ უარყოფს. ყალბი წყარო, რომელიც თქვენს ცხრილში ყველგან მარშრუტიზებადია, გადის, მაშინ როცა საერთოდ მარშრუტის გარეშე წყარო კვლავ უარყოფილია. ლეპტოპზე ეს ვიწრო დათმობაა; როუტერზე, რომელიც სხვა ადამიანების ტრაფიკს გადასცემს, ის ფართოა. რეჟიმი ჰოსტს ეკუთვნის, ამიტომ იგივე რიცხვი ორ ადგილას სხვადასხვა წონას ატარებს.
რომელი ხაზი სჭირდება ამ ტოპოლოგიას, ცხრილიდან გამომდინარეობს და არა ჩვევიდან. პაკეტი კანონიერია და მისი წყარო მარშრუტიზებადია, ამიტომ ფხვიერი იღებს მას, მკაცრი კი არა. ამ საქმეში არაფერი ითხოვს ნულს, და ნულის არჩევა მოხსნიდა შემოწმებას, რომელიც აქ არაფერი ღირს.
აირჩიეთ უმცირესი ცვლილება, რომელიც აშორებს გაურკვევლობას
ფხვიერი რეჟიმი ყველაზე პატარა შესაფერისი ცვლილებაა და ეს სიმკაცრის ნამდვილი შემცირებაა, არა უვნებელი გადამრთველი. უკეთესი ვარიანტი არსებობს ყოველთვის, როცა ტოპოლოგია იძლევა საშუალებას: მოხსენით გადაფარვა და გაურკვევლობა გაქრება.
სადაც ოფისის პრეფიქსი მხოლოდ Ethernet-ით არის საჭირო, ამოიღეთ ის იმ მარშრუტებიდან, რომლებსაც პროფილი იწევს, და მისამართი ერთი გზით მისაწვდომი გახდება. როცა ორივე გზა ნამდვილად უნდა თანაარსებობდეს, დაამაგრეთ წყარო და მოწყობილობა პოლიტიკის წესით, ნაცვლად იმისა, რომ ყოველ ინტერფეისზე შეასუსტოთ ვალიდაცია. ეს ინარჩუნებს მკაცრ ფილტრაციას მანქანის ყველა დანარჩენისთვის და ადასტურებს გამონაკლისს იქ, სადაც შემდეგი ინჟინერი მოძებნის მას.
რომელ გზასაც აირჩევთ, ჩაწერეთ ის sysctl drop-in-ში და არა ცოცხალ ბრძანებაში. დააყენეთ all და default გასაღებები ერთად, რათა ხელახალი დაკავშირება ვერ შეძლოს მკაცრი რეჟიმის ჩუმად დაბრუნება.
# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --systemრას თმობს ფხვიერი რეჟიმი, და სად
ფხვიერი რეჟიმი კვლავ უარყოფს წყაროს, რომელსაც ვერც ერთი მარშრუტი ვერ მიაღწევდა, და წყვეტს შემთხვევით მარშრუტიზებადი ყალბი წყაროს უარყოფას. ლეპტოპზე ეს ვიწრო დათმობაა. მოწყობილობაზე, რომელიც თავისი არასაკუთარ ტრაფიკს გადასცემს, იგივე არჩევანი გაცილებით ფართოა. ამიტომ იგივე პარამეტრი ორ ძალიან განსხვავებულ მნიშვნელობას ატარებს იმის მიხედვით, სად მუშაობს.
შემოწმების სრულად გამორთვა ჰოსტზე, რომელიც სხვა ადამიანებისთვის ტრაფიკს გადასცემს, ერთადერთი შესწორებაა, რომელიც უნდა მოერიდოთ. ნული აგდებს იმ ვალიდაციას, რომელსაც ფხვიერი რეჟიმი ფრთხილად ინახავს. თუ ჰოსტი სხვებისთვის გადასცემს, სამაგიეროდ დაიცავით წინა ნაწილის პოლიტიკის წესის ვარიანტი.
დატოვეთ ჩანაწერი, რომელიც ასახელებს ორ ინტერფეისს, გადაფარვად პრეფიქსს და ზუსტ ტესტს, რომელიც ახლა წარმატებულია. ეს უფრო სასარგებლოა შემდეგი ინჟინერისთვის, ვიდრე ხაზი იმის შესახებ, რომ ფილტრაცია დაზუსტდა.