ლოკალური აპი, VPN წესი: რატომ არასდროს ირთვება თქვენი FORWARD ჯაჭვი
მანქანაზე მომუშავე პროცესი იყენებს OUTPUT-ს და არა FORWARD-ს. აირჩიეთ კაუჭი სწორ სახელთა სივრცეში და შემდეგ გადაწყვიტეთ, საკმარისია ნიშანი თუ ჩვეულებრივი მარშრუტი.
თქვენ ამატებთ წესს VPN ტრაფიკისთვის FORWARD ჯაჭვში, ითვისებთ მოთხოვნას იმავე Linux მანქანიდან და მრიცხველი ნულზე რჩება. წესი, სავარაუდოდ, სწორია. პაკეტი ამ გზას არასდროს გაჰყოლია, რადგან მანქანაზე წარმოქმნილ მოთხოვნას ის არ გადაგზავნის. პაკეტის სიცოცხლის თვალყურის დევნება სოკეტიდან მავთულამდე ხსნის, რატომ და სად უნდა იყოს წესი სინამდვილეში.
იპოვეთ, სად დაიბადა პაკეტი
Netfilter-ის კაუჭების რიგი ჰყოფს სამ შემთხვევას და მათგან მხოლოდ ერთი მოიცავს FORWARD-ს:
| Origin | Path | Hook that sees it |
|---|---|---|
| Local process | OUTPUT then POSTROUTING | OUTPUT, POSTROUTING |
| Addressed to a local service | PREROUTING then INPUT | PREROUTING, INPUT |
| Received for another host | PREROUTING, FORWARD, POSTROUTING | FORWARD |
ლოკალური აპლიკაცია იწყება OUTPUT გზაზე, რადგან ბირთვმა უკვე დაადგინა, რომ პაკეტი აქ წარმოიქმნება და არასდროს არის გადაგზავნის კანდიდატი. გვირაბის შექმნა ამ კლასიფიკაციას არ ცვლის; გვირაბი მოწყობილობაა, რომლიდანაც პაკეტს შეუძლია გასვლა, და არა საფეხური, რომელიც ლოკალურ გამომავალს ტრანზიტად აქცევს.
ორი პაკეტი, ერთი ისტორია
გვირაბის აწევის შემდეგ აპის შიდა პაკეტი და დაშიფრული გარე პაკეტი სხვადასხვა ობიექტია. შიდა პაკეტი ატარებს იმ დანიშნულებასა და ტვირთს, რომელიც აპმა აირჩია. გარე პაკეტი დაშიფრულ ტექსტს ატარებს პარტნიორის მისამართსა და პორტზე და სწორედ ის კვეთს რეალურად ფიზიკურ ინტერფეისს.
თქვენი პოლიტიკა ეხება ერთ-ერთ მათგანს და არასწორის არჩევა ხშირი მიზეზია, რომ წესი თითქოს არაფერს აკეთებს. წესი, რომელიც ემთხვევა პარტნიორის გარე მისამართს, ყველა გვირაბის პაკეტს ერთნაირად ხედავს, რასაც არ უნდა აკეთებდეს შიდა აპი. შიდა დანიშნულებასთან დამთხვევა ხედავს იმ ტრაფიკს, რომელიც გაინტერესებთ და ის ამუშავდება მხოლოდ მაშინ, როცა ეს პაკეტი მიაღწევს იმ კაუჭს, რომელზეც წესი დააყენეთ.
სახელთა სივრცეები ზღვარს აადგილებენ
კონტეინერი ამას ართულებს პრინციპის შეცვლის გარეშე. აპის მოთხოვნა ლოკალური გამომავალია კონტეინერის ქსელური სახელთა სივრცის შიგნით. მასპინძელი ამ ტრაფიკს იღებს ვირტუალურ Ethernet ინტერფეისზე და შეუძლია გადაგზავნოს, ამიტომ მასპინძელზე FORWARD წესს შეიძლება ჰქონდეს აზრი, თუმცა მოთხოვნის შემქმნელ პროცესს მასპინძლის OUTPUT ჯაჭვი არასდროს შეხებია.
კაუჭის არჩევამდე დაადგინეთ, სად ცხოვრობენ სინამდვილეში წესების ნაკრები და გვირაბი. გვირაბი კონტეინერის შიგნით, გვირაბი მასპინძელზე კონტეინერის მის გავლით მარშრუტიზაციით და გვირაბი ცალკე სახელთა სივრცეში სამი განსხვავებული ტოპოლოგიაა სამი განსხვავებული წესის ადგილით. წესები წაიკითხეთ იმ სახელთა სივრცის შიგნით, რომელსაც მოწყობილობა ეკუთვნის და არა მხოლოდ ნაგულისხმევში.
იკითხეთ, საერთოდ გჭირდებათ თუ არა ნიშანი
თუ მიზანია ერთი დანიშნულების პრეფიქსის გვირაბით გაგზავნა, ამ პრეფიქსისთვის მარშრუტი შეიძლება საკმარისი იყოს. ჯერ შეამოწმეთ მოქმედი მარშრუტები, მათ შორის ყველაფერი, რაც სერვერმა შეაყენა: გადამისამართებული ნაგულისხმევი მარშრუტი VPN-ით ბევრად მეტ ტრაფიკს აგზავნის, ვიდრე ის ვიწრო პოლიტიკა, რომელიც გქონდათ მხედველობაში და ნიშნის არც რაოდენობა გახდის შედეგს განზრახვის შესაბამისს.
კლასიფიკაცია საჭიროა მაშინ, როცა გადაწყვეტილება დამოკიდებულია იმაზე, რასაც მარშრუტი ვერ გამოხატავს, მაგალითად, წყაროზე, მომხმარებელზე ან პროცესზე. მიღებული ტრაფიკისთვის PREROUTING-ში ნიშანი მუშაობს. ლოკალური ტრაფიკისთვის ნიშანი უნდა დაისვას გამომავალ საფეხურზე, რომელსაც შეუძლია ნიშნის დაყენების შემდეგ ახალი მარშრუტის ძებნა გამოიწვიოს. nftables-ში ეს გამომავალ კაუჭზე route ტიპის ჯაჭვია; ჩვეულებრივი გამომავალი ფილტრის ჯაჭვი მნიშვნელობას დააყენებს და მარშრუტს უცვლელად დატოვებს.
iptables-ში ეკვივალენტი ცხოვრობს mangle OUTPUT განლაგებაში და იგივე მოთხოვნა მოქმედებს: მარშრუტიზაციის გადაწყვეტილება უნდა გადაიხედოს ნიშნის არსებობის შემდეგ. შემდეგ პოლიტიკის წესმა უნდა მოიხმაროს ნიშანი და მიუთითოს ცხრილზე, რომელიც შეიცავს გამოსაყენებელ მარშრუტს. conntrack ნიშნის დაყენება მესამე, ცალკე ოპერაციაა; ის ინახავს მნიშვნელობას ნაკადზე და თავისთავად არ აყენებს ამ მნიშვნელობას მიმდინარე პაკეტზე, რომ მარშრუტიზაციამ წაიკითხოს.
შეამოწმეთ ძებნა და მრიცხველი ერთად
nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1მისამართი და ნიშანი საილუსტრაციოა და ორი მარშრუტის მოთხოვნა სხვადასხვა კითხვას პასუხობს. მეორე იკითხავს, რას იზამდა ბირთვი, თუ პაკეტს ეს ნიშანი ექნებოდა; ის არ აჩვენებს, რომ თქვენი წესების ნაკრები რომელიმეს ანიჭებს. მოეპყარით როგორც ჰიპოთეზის გამოცდას და არა როგორც მტკიცებას, რომ პოლიტიკა მუშაობს.
შემდეგ გაუშვით უვნებელი მოთხოვნა და ერთდროულად დააკვირდით ორ რამეს: მრიცხველს არჩეულ კაუჭზე და იმ გასასვლელს, რომელიც პაკეტმა რეალურად აიღო. თუ მრიცხველი იძვრება და პაკეტი სხვაგან გადის, ნიშანი ან ცხრილი არასწორია. თუ არც ერთი არ იძვრება, პაკეტი საერთოდ არ აღწევს ამ კაუჭს და შემდეგი კითხვა სახელთა სივრცე ან გზაა.
დაბოლოს, შეზღუდეთ გამოცდა იმით, რისი გამოხატვაც მექანიზმს შეუძლია. ერთი მისამართისთვის ერთი მარშრუტი არ ხდება მუდმივი პოლიტიკა სერვისისთვის, რომლის მისამართებიც იცვლება. ჯერ გადაწყვიტეთ პაკეტების ფარგლები, შემდეგ შეამოწმეთ, შეუძლია თუ არა მარშრუტიზაციისა და ნიშნის დიზაინს ამ ფარგლების შენარჩუნება ხელახალი დაკავშირების შემდეგ.