ჩადგმული WireGuard: შუა ნახტომი საკუთარ პორტს ვერ პასუხობს
როცა შუა ნახტომი ყველაფერს ერთ გვირაბში აგზავნის, შემომავალი სერვისის პასუხები არასწორი გზით გადის. ინტერფეისზე წყარო-პორტის წესი ამას ასწორებს.
სამი WireGuard ნახტომი აღწევს ქსელამდე, რომელსაც საჯარო მისამართი არ აქვს, და შემდეგ შუა მანქანა წყვეტს პასუხს იმ პორტზე, რომელზეც უნდა მოესმინა. გვირაბი შემდგომ მუშაობს, შორეული ჰოსტი კვლავ პასუხობს, და მხოლოდ შუა სერვერი გაჩუმდა გარედან. ეს კომბინაცია დამაბნეველია ზუსტად იმიტომ, რომ თავად შექმნილია: შუა ნახტომი ემორჩილება საკუთარ მარშრუტიზაციის ცხრილს, და ცხრილი მის პასუხებს არასწორი მიმართულებით აგზავნის.
ჯაჭვი, რომელიც მუშაობს მანამ, სანამ შუა ყუთს ელაპარაკები
ავიღოთ საილუსტრაციო ჯაჭვი: კლიენტი A აღწევს B სერვერამდე UDP 500-ზე, და B აგრძელებს C სერვერამდე UDP 500-ზე. C ტრაფიკს იღებს მხოლოდ თავისი ერთადერთი პირის მისამართიდან, რაც მას ფოთლად აქცევს და მის ქცევას მარტივად ინახავს. B ფოთოლი არ არის, და ამ ხარვეზში ყველაფერი საინტერესო სწორედ იქ ხდება.
განსხვავება მნიშვნელოვანია, რადგან ფოთლისა და შუა როლები საპირისპირო მიმართულებებით იზიდება. ფოთოლს შეუძლია ყველაფერი გაგზავნოს ერთ გვირაბში შედეგების გარეშე, რადგან სხვა არაფერია მასზე დამოკიდებული. შუა ნახტომი ერთდროულად კლიენტებისთვის დასასრული წერტილია და შორეული მხარისკენ კლიენტი, და ეს ორი სამუშაო სხვადასხვა მარშრუტიზაციას ითხოვს.
რატომ გადის პასუხი გვირაბით
B-ზე, C-ისკენ მიმართული ინტერფეისი ატარებს AllowedIPs = 0.0.0.0/0-ს შესაბამის ნაგულისხმევ მარშრუტთან ერთად. ამიტომ B-ის მიერ შექმნილი ყველა პაკეტი შედის იმ გვირაბში, თუ უფრო კონკრეტულმა რამემ უპირატესობა არ მიიღო.
A-დან B-ზე მისამართიანი პაკეტი ჩამოდის და მიიღება, რადგან B დანიშნულებაა და ლოკალური მიწოდება პირველი ხდება. პასუხი სულ ახალი, ლოკალურად შექმნილი პაკეტია A-ს საჯარო მისამართზე, და ეს დანიშნულება ემთხვევა გვირაბში მიმავალ ნაგულისხმევ მარშრუტს. C იღებს მას, არ ფლობს ამ მისამართს და ყრის მას.
სიმპტომი იკითხება როგორც ბანგის პრობლემა ან გასაღების შეუთავსებლობა, და აქ არც ერთი არ არის მართალი. C-ისკენ გვირაბზე გადაღება აჩვენებს, რომ პასუხები არასწორი მიმართულებით მიდის. ეს ერთი დაკვირვება მეტ დროს ზოგავს, ვიდრე კონფიგურაციის ნებისმიერი რაოდენობის კითხვა, ამიტომ ჩაწერეთ იგი სანამ გასაღებების შეცვლას დაიწყებთ. ვინც გადაღება არ უნახავს, იფიქრებს რომ თავად გვირაბი გატეხილია.
ვიწრო შეკეთება: პოლიტიკის წესები, რომლებიც წყარო-პორტს ემთხვევა
B-ის მოსმენის სოკეტიდან პასუხები გადის წყარო-პორტ 500-ით. პოლიტიკის წესს შეუძლია ამას დაემთხვეს და ეს პაკეტები ჩვეულებრივ ცხრილში დააბრუნოს:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101პოლიტიკის წესები განიხილება პრიორიტეტის რიგით, და მთავარი ცხრილი 32766-ზეა, ამიტომ 100-ზე მდებარე წესი იკითხება მანამ, სანამ გვირაბის ნაგულისხმევი მარშრუტი იტყვის რამეს. დაამატეთ ერთი ჩანაწერი თითოეული პორტისთვის, რომელიც გარედან ხელმისაწვდომი უნდა დარჩეს, და მეტი არაფერი, რათა გადამისამართებული ტრაფიკი კვლავ იყენებდეს იმ გვირაბს, რომლისთვისაც აშენდა.
იცოდეთ ამ ხრიკის საზღვარი. sport ამომრჩევი ემთხვევა ლოკალურად შექმნილ პაკეტებს, რაც ზუსტად ფარავს პასუხის შემთხვევას და განზრახ არ ფარავს ტრაფიკს, რომელსაც B მხოლოდ სხვისთვის გადასცემს. B-ის უკან განთავსებულ სერვისს მაინც სჭირდება საკუთარი პასუხი, და საწინააღმდეგოს თამაში იძლევა შეკეთებას, რომელიც მუშაობს პირველი სერვისისთვის და ვარდება მეორეზე.
მიეცით წესს მფლობელი
ბრძანების სტრიქონში აკრეფილი წესი ქრება შემდეგ ჯერზე, როცა ინტერფეისი ხელახლა აშენდება. WireGuard-ის კონფიგურაციაში მოათავსეთ ის იქ, სადაც ინტერფეისი იქმნება და იშლება:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100თუ ინტერფეისს ფლობს NetworkManager, დისტრიბუციის კაუჭი ან კონტეინერის შესვლის წერტილი, წყვილი ეკუთვნის იმ მფლობელს და არა ხელით რედაქტირებულ ფაილს. შეამოწმეთ მოქმედი წესები ხელახალი დაკავშირების შემდეგ, და არა მხოლოდ პირველი გაშვების შემდეგ, რადგან პირველი გაშვება ის შემთხვევაა, რომელიც ყოველთვის მუშაობს.
შეადარეთ ალტერნატივები პატიოსნად
წყარო-პორტის წესი ოთხი გამოსავლიდან ერთია და მათგან ყველაზე ვიწრო. მას აქვს უპირატესობა, რომ საერთოდ არ ეხება გვირაბის პოლიტიკას, ამიტომ ჩვეულებრივ გადაურჩება მოგვიანებით ცვლილებებს. ვიწრო შეკეთებები ხმამაღლა ვარდება, როცა წყვეტს მოქმედებას, მაშინ როცა ფართო გამონაკლისი ჩუმად აგრძელებს მუშაობას მისი მიზეზის გაქრობიდან დიდი ხნის შემდეგ. ეს განსხვავება უფრო მნიშვნელოვანია, ვიდრე ელეგანტურობა, როცა ორი წლის შემდეგ ყუთი სხვას ეკუთვნის.
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
დაამოწმეთ ორივე მხრიდან მას შემდეგ, რაც აირჩევთ. A-დან დაიწყეთ კავშირი B-ის პორტზე და ცოტა ხნით დატვირთული შეინახეთ. B-ზე აიძულეთ ბირთვი, გაამართლოს პასუხის გზა რაღაცით, როგორიცაა ip route get <address-of-A> sport 500, და დაადასტურეთ, რომ ასახელებს WAN ინტერფეისს და არა გვირაბს. ამის შემდეგ შეამოწმეთ, რომ C-ის უკან რაღაც კვლავ პასუხობს ჯაჭვის გავლით, რაც ამტკიცებს, რომ გამონაკლისი ვიწრო დარჩა და არ გადაიქცა გვერდის ავლად. ბოლოს, ჩაწერეთ პორტები დიზაინის ჩანაწერებში, თორემ შემდეგი ოპერატორი ამას სხვა სერვისზე ხელახლა აღმოაჩენს.