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

შეამოწმეთ სამი პირობა წესის დაწერამდე

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

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

შეადარეთ პასუხი და არა კლიენტის დანიშნულების პორტი

TCP 443-ზე მოსმენილი სერვერის პასუხი ჰოსტს ტოვებს წყარო პორტით 443. იმავე ჰოსტის ბრაუზერი, რომელიც დაშორებულ HTTPS საიტს უკავშირდება, აგზავნის წარმავალ წყარო პორტს და დანიშნულების პორტს 443. ორივე 443 პორტის ტრაფიკია და მხოლოდ ერთმა უნდა აიღოს WAN ცხრილი, ამიტომ დანიშნულების პორტის დამთხვევა არასწორ ნახევარს დაიჭერდა.

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

ააგეთ სრული დაბრუნების ცხრილი სანამ წესი მასზე მიუთითებს

ცარიელი ცხრილი ნიშნავს მარშრუტი არ არის, რაც გატეხილ პოლიტიკაზე მეტად გატეხილ სერვისს ჰგავს. ჯერ შეავსეთ ის, ისეთი ცხრილის ნომრითა და პრიორიტეტით, რომლებზეც ჰოსტზე სხვა არაფერი აცხადებს პრეტენზიას:

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

წაიკითხეთ ნომრები ცოცხალი ჰოსტიდან, ნაცვლად მათი კოპირებისა. ip -4 rule show გეტყვით, რომელი პრიორიტეტებია დაკავებული, და უკვე არსებულ პრიორიტეტზე წესის დამატება ჩუმად ცვლის ორი წესის რიგითობას, რომლებიც ცალ-ცალკე წესიერად გამოიყურება.

აქ ნამდვილ საქმეს ორი ამომრჩევი აკეთებს. iif lo არის ის, როგორც ბირთვი იტყობინება ჰოსტის მიერ თავად შექმნილ პაკეტებზე, ამიტომ წესი ვერ შეიპყრობს შემთხვევით გარედან მომავალ გადამისამართებულ ტრაფიკს. ipproto tcp sport 443 ავიწროებს მას ერთ ტრანსპორტზე და ერთ პორტზე, რაც იმდენად მჭიდროა, რამდენადაც მოთხოვნა იძლევა საშუალებას. მოხსენით პროტოკოლის ამომრჩევი და წესი UDP 443-საც დაიჭერს, რაც სხვა ქცევის მქონე სხვა სერვისია.

შეინახეთ კერძო პასუხები გვირაბის შიგნით

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

ip -4 route add table 100 throw 10.90.0.0/24

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

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

შეამოწმეთ TCP, შემდეგ QUIC, შემდეგ გადატვირთვა

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

HTTP/3 UDP-ზე მიეწოდება და TCP წესით არ დაემთხვევა, ამიტომ QUIC მსმენელს საკუთარი ამომრჩევი სჭირდება, წინააღმდეგ შემთხვევაში ის გვირაბს გააგრძელებს გამოყენებას სანამ HTTPS მუშაობს. შეინახეთ წესები, რომლებზეც შეჩერდებით, ინტერფეისის მფლობელ კომპონენტში, და დაადასტურეთ ისინი ხელახალი დაკავშირების ან DHCP განახლების შემდეგ. როცა კონკურენტი მენეჯერი გადატვირთვის შემდეგ ხსნის მუშაობის დროის მარშრუტს, ეს საკუთრების პრობლემაა, რომელიც წყაროში უნდა გამოსწორდეს და არა მიზეზი ზემოდან უფრო ფართო NAT წესების დასამატებლად.

დაკავშირებული სტატიები