ცალკე გასასვლელი: VPN-ის აუზი usb0-ზე, კარიბჭის ტრაფიკი eth0-ზე

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

დაადასტურეთ, რომ წყაროს მისამართი მარშრუტიზაციის გადაწყვეტილებამდე რჩება

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

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

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

ააგეთ შერჩეული ცხრილი, რომელიც სრულია

ცხრილი არ არის ნაგულისხმევი მარშრუტი მეგობართან ერთად. მას სჭირდება საკმარისი მარშრუტები, რომ ყოველი ძიება მის შიგნით გადაწყდეს, მათ შორის WAN ქვექსელის დაკავშირებული მარშრუტი, რათა შემდეგი ნახტომი მისაწვდომი იყოს. tun1-ზე 10.77.0.0/24 აუზისთვის, 203.0.113.1 შემდეგი ნახტომით WAN მისამართისთვის 203.0.113.20/24 და ცხრილი 600-ისთვის:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

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

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

შეინარჩუნეთ მსმენელის საკუთარი ტრაფიკი პოლიტიკის გარეთ

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

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

თანმიმდევრობა ასევე მნიშვნელოვანია მოწყობილობაზე არსებულ ყველაფერთან მიმართებაში. Docker-ის ხიდები, მეორე VPN და პროვაიდერის იმიჯიდან უკვე არსებული ნებისმიერი წესი ყველა ამატებს პრიორიტეტებს, ამიტომ წაიკითხეთ წესების სრული სია იმის ნაცვლად, რომ ჩათვალოთ პრიორიტეტი 100 მარტო.

შეათანხმეთ გადამისამართება და თარგმნა მარშრუტთან

მარშრუტიზაცია ირჩევს ზედა კავშირს; ის გადამისამართების ნებართვას არ იძლევა. ბირთვში უნდა იყოს IPv4 გადამისამართება ჩართული, ხოლო ფაირვოლმა უნდა მიიღოს მიმართულება კლიენტიდან WAN-ისკენ და დაბრუნების ტრაფიკი. სწორი ცხრილი FORWARD ჯაჭვით, რომელიც ნაკადს ყრის, იძლევა იგივე სიმპტომს, რაც დაკარგული მარშრუტი, ამიტომ ორივე ერთ გავლაში მოწმდება.

თუ მეორე WAN კერძო აუზს თქვენკენ უკან არ გაამარშრუტებს, თარგმნეთ წყარო იმ გასასვლელზე. დინამიკური მისამართის ინტერფეისისთვის ჩვეულებრივი არჩევანია ვიწრო masquerade წესი, შემოსაზღვრული აუზითა და ინტერფეისით:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

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

გვირაბის დანახარჯი ასევე საჭიროებს ყურადღებას, როცა გზები განსხვავდება. თუ კლიენტები დიდ TCP MSS-ზე შეთანხმდებიან და ალტერნატიულ WAN-ს აქვს დაბალი MTU ან შიგნით გვირაბი, დიდი სეგმენტები ჩერდება, პატარები კი მუშაობს. გადამისამართების გზაზე MSS-ის შეკვრა ამას წინასწარმეტყველებად ქცევად აქცევს, და არა დროდადრო ჩავარდნად.

გადაწყვიტეთ, რა მოხდება, როცა usb0 გაქრება

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

სადაც ეს უკან დაბრუნება მიუღებელია, დაამატეთ ცხადი ტერმინალური მარშრუტი ცხრილ 600-ში, მაგალითად blackhole ნაგულისხმევი, ან ჩააგდეთ აუზი ფაირვოლში, სანამ ინტერფეისი გამორთულია. ორივე მათგანი გადაწყვეტილებაა, რომლის ჩაწერაც შეგიძლიათ; დუმილი — არა.

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