WireGuard-ის ჰოსტის პრეფიქსი: რატომ მუშაობს ერთი მისამართი და დანარჩენი — არა
/32 ინტერფეისზე ვალიდური ჰოსტის პრეფიქსია და მხოლოდ იმ ერთ მისამართს მარშრუტიზებს. დაამატეთ მარშრუტი, რომელსაც AllowedIPs გულისხმობს, შემდეგ შეამოწმეთ დაბრუნების გზა.
გვირაბი აწეულია, handshake ყოველ ორ წუთში ხდება და მეორე მხარეს ზუსტად ერთი მისამართი პასუხობს. პინგები პირის გვირაბის მისამართზე მუშაობს; მის უკან კი არაფერი. ვიღაც კითხულობს ინტერფეისის კონფიგურაციას, ხედავს ჰოსტის პრეფიქსს და ასკვნის, რომ ნიღაბი არასწორია. მისი /24-მდე გაფართოება პინგს ცოტა ხნით ასწორებს და შემდეგ სხვა რამეს ამტვრევს. პრეფიქსი არასდროს ყოფილა მიზეზი, ხოლო დაკარგული მარშრუტი არ არის ის, რასაც ნიღაბი მართავს.
რას ქმნის სინამდვილეში ინტერფეისის პრეფიქსი
Linux-ზე ინტერფეისზე მისამართის მინიჭება ქმნის დაკავშირებულ მარშრუტს ამ პრეფიქსისთვის. თუ ჰოსტის პრეფიქსს მიანიჭებთ, დაკავშირებული მარშრუტი ერთ მისამართს ფარავს. თუ /24-ს მიანიჭებთ, ის 256-ს ფარავს და თითოეული მათგანი ახლა ამ რგოლზე ხელმისაწვდომად ითვლება.
ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1
ჰოსტის პრეფიქსი წერტილიდან წერტილამდე გვირაბისთვის სრულიად ნორმალური არჩევანია, რადგან მეორე ბოლოში ზუსტად ერთი პირია. მესამე ბრძანება პასუხობს მომხმარებლის კითხვას: ამბობს, რომელი ინტერფეისს გამოიყენებდა ბირთვი ამ დანიშნულებისთვის და არაფერს სასარგებლოს არ აჩვენებს, თუ არც ერთი მარშრუტი არ ემთხვევა.
ეს არის სიმპტომის სრული ახსნა. ერთი მისამართი პასუხობს იმიტომ, რომ მისთვის დაკავშირებული მარშრუტი არსებობს, ან იმიტომ, რომ პირის ნებადართული სია შემთხვევით მოიცავს მას. დანარჩენს მარშრუტი არ აქვს და იშლება მანამდე, სანამ WireGuard საერთოდ ჩაერთვება. გვირაბი მთელი ამ ხნის განმავლობაში ჯანსაღია, ამიტომ handshake-ის მრიცხველი კვლავ დამამშვიდებლად გამოიყურება.
AllowedIPs ორი წესია ერთი სახელის ქვეშ
WireGuard-ის პირზე ნებადართული სია ერთდროულად ორ საქმეს აკეთებს და კონფიგურაციის სინტაქსი მათ ერთად აჩენს. შემოსვლისას ის ნებას რთავს, რომელი წყარო მისამართები შეიძლება წარმოადგინოს პირმა. გასვლისას ის ირჩევს, რომელ პირზე გაიგზავნოს პაკეტი, ყველაზე სპეციფიკური დამთხვევის მოძებნით.
არც ერთი ეს საქმე არ არის მარშრუტიზაცია. ბირთვმა მაინც უნდა გადაწყვიტოს, რომ პაკეტი გვირაბის ინტერფეისს ეკუთვნის, სანამ WireGuard მას შეხედავს, და ეს გადაწყვეტილება მარშრუტიზაციის ცხრილიდან მოდის. პირის ჩანაწერი ფართო ნებადართული სიით თავისთავად მარშრუტს არ აყენებს.
ამიტომ კონფიგურაცია სრულად შეიძლება გამოიყურებოდეს და ასიმეტრიულად მოიქცეს. კლიენტი მეორე მხარეს აგზავნის იმიტომ, რომ მარშრუტი არსებობს, ხოლო პასუხები არასდროს აღწევს იმიტომ, რომ მეორე მხარის ნებადართული სია კლიენტის წყაროს არ უშვებს, ან იმიტომ, რომ მეორე მხარეს დაბრუნების გზა არ აქვს. ორივე მიმართულება ცალკე გადაწყვეტილებაა ცალკე მარცხის რეჟიმებით. ჩაწერა, რომელსაც ამოწმებთ, დიაგნოზის ნახევარია.
საიდან მოდის მარშრუტი
თუ იყენებთ wg-quick-ს, მარშრუტები თქვენთვის იქმნება თითოეული პირის ნებადართული სიიდან, თუ თქვენ არ დააყენეთ Table = off და თავად არ აიღეთ კონტროლი. ეს არის ინსტრუმენტის დოკუმენტირებული ქცევა და ის მიზეზი, რის გამოც კონფიგურაცია მკაფიო მარშრუტის დირექტივების გარეშე მაინც მუშაობს.
sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0
შეადარეთ ნებადართული სია რეალურად არსებულ მარშრუტებს. პირი, რომელიც მთელ ქვექსელს უშვებს, მაგრამ მხოლოდ ჰოსტის მარშრუტი შექმნა, ნიშნავს, რომ დამხმარე არასდროს გაშვებულა, ან რომ ინტერფეისს უშუალოდ wg-ით და ip-ით მართავთ, და ამ შემთხვევაში არაფერი ქმნის თქვენთვის მარშრუტებს.
როცა ხელით მართავთ, მარშრუტი ერთი ხაზია და მისი ფორმა მკაფიოა: დანიშნულება ინტერფეისის გავლით, შესასვლელის გარეშე, რადგან რგოლი წერტილიდან წერტილამდეა. მისი დამატება ცუდი პრეფიქსისთვის შემოვლითი გზა არ არის; ეს არის დიზაინის დაკარგული ნახევარი, რომელმაც შეგნებულად თავად აიღო მარშრუტიზაცია.
უფრო ფართო პრეფიქსი პირის ჩანაწერს არ ამატებს
მაცდური შესწორებაა მისამართის /24-ად შეცვლა, რათა დაკავშირებულმა მარშრუტმა სერვერის ლოკალური ქსელი დაფაროს. თითქოს მუშაობს, და იმის მიზეზი, რომ თითქოს მუშაობს, არის ის, რომ დაკავშირებული მარშრუტი ახლა ემთხვევა, და არა ის, რომ WireGuard-მა რაიმე ახალი ისწავლა.
ის, რაც ასევე გააკეთეთ, არის მთელი დიაპაზონის მოთხოვნა, როგორც უშუალოდ ხელმისაწვდომისა ამ რგოლზე, მათ შორის მისამართების, რომლებიც სხვა პირებს ან სინამდვილეში სერვერის უკან მდებარე ლოკალურ ქსელს ეკუთვნის. ტრაფიკი ამ მისამართებზე ახლა გვირაბში შედის, და გამოვა თუ არა ის მეორე მხარეს, დამოკიდებულია თავად სერვერის მარშრუტიზაციასა და ნებადართულ სიებზე.
კრიპტოგრაფიული მხარე არავითარ შემთხვევაში არ ირღვევა. WireGuard-ს კვლავ სჭირდება ჩანაწერი ნებადართულ სიაში, რომელიც დანიშნულებას ფარავს, პირის ასარჩევად, ხოლო მეორე მხარეს კვლავ სჭირდება ჩანაწერი, რომელიც თქვენს წყაროს ფარავს, მის მისაღებად. უფრო ფართო ინტერფეისის პრეფიქსი არც ერთს ვერ უზრუნველყოფს.
დაადასტურეთ ორივე მიმართულება, სანამ რამეს შეცვლით
დაამუშავეთ ორი ბოლო ცალკე და ჩაწერეთ, რას ამბობს თითოეული. კლიენტზე მარშრუტი და პირის ჩანაწერი; სერვერზე სარკული სურათი პლუს მისი საკუთარი დაბრუნების გზა:
ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10
ჩაჭერა არის ის, რაც წყვეტს კამათს მიმართულებაზე. თუ გამავალი პაკეტები გვირაბის ინტერფეისზე ჩნდება და სერვერი არაფერს არ იწერს, შორეული ბოლო მათ უარყოფს, ჩვეულებრივ იმიტომ, რომ თქვენი წყარო მის ნებადართულ სიაში არ არის. თუ საერთოდ არაფერი არ ჩნდება, მარშრუტი აკლია ან სხვა ადგილისკენ მიუთითებს.
შემდეგ შეაკეთეთ უფრო ვიწრო ბოლო. ჩანაწერი ნებადართულ სიაში სერვერის მხარეს თქვენი კლიენტის მისამართისთვის და ჩანაწერი კლიენტის მხარეს დანიშნულების ქვექსელისთვის ჩვეულებრივი ფორმაა და ინტერფეისის პრეფიქსს ხელუხლებლად ტოვებს. გააფართოეთ პრეფიქსი მხოლოდ მაშინ, თუ მისამართების გეგმა ნამდვილად ითხოვს საერთო ქვექსელს ამ რგოლზე, და გააკეთეთ ეს როგორც გეგმის ცვლილება და არა როგორც გამართვის ნაბიჯი.