რატომ თქვენი საჯარო Linux სერვისი VPN-ის გავლით პასუხობს

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

არასწორი წარმოდგენა: პასუხები მიჰყვება იმ ინტერფეისს, რომლიდანაც მოვიდა

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

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

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

რას ამარშრუტებს ბირთვი სინამდვილეში: წყაროს მისამართი

საჭირო სახელური არის ლოკალური მისამართი, რომელსაც სერვისი პასუხებისთვის იყენებს. ჰოსტზე, რომლის საილუსტრაციო eth0 მისამართია 192.0.2.10/24 და კარიბჭე 192.0.2.1, ეს მისამართი ინტერფეისზე არსებობს. ღრუბლოვან VM-ზე საჯარო მისამართი შეიძლება ზემოთ იყოს გარდაქმნილი და სტუმარში არ იყოს, ამიტომ გამოიყენეთ ის მისამართი, რომელიც ჰოსტს ნამდვილად აქვს.

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

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

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

ააშენეთ სრული დაბრუნების ცხრილი, და არა ნახევარი ნაგულისხმევი

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

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

გამოიყენეთ ნამდვილი პრეფიქსი და კარიბჭე და არ დააკოპიროთ მაგალითი. on-link კარიბჭით /32-ად კონფიგურირებულ ღრუბლოვან ინტერფეისს სხვა დაკავშირებული მარშრუტი სჭირდება, და არასწორი პრეფიქსიდან აშენებული ცხრილი პირველივე ნახტომზე ვარდება. src ატრიბუტი ამ მარშრუტის სასურველ წყაროს მიუთითებს; ის წყაროს წესს არ ცვლის.

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

გადაამოწმეთ წყაროთი განსაზღვრული ძებნით

სთხოვეთ ბირთვს, სერვისის მისამართიდან სატესტო დანიშნულება ამარშრუტოს. პასუხმა უნდა დაასახელოს eth0 და WAN კარიბჭე, და არა გვირაბი:

ip -4 route get 198.51.100.25 from 192.0.2.10

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

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

სად ჩერდება ეს გამონაკლისი

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

ის ასევე არ აჩენს ჰოსტის საჯარო მისამართს ინტერფეისზე. როცა ზემოთა NAT ფლობს ამ მისამართს, პასუხი მაინც უნდა გავიდეს იმ გზით, რომელსაც ეს NAT მოელის, ამიტომ WAN ცხრილმა უნდა აირეკლოს პირვანდელი კარიბჭე და პრეფიქსი და არა გამოცნობილი საჯარო დიაპაზონი.

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

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