AllowedIPs მარშრუტიზაციის სიაა და არა ფაიერვოლის წესი

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

ერთი ველი, ორი მკითხველი: გამავალი არჩევანი და წყაროს შემოწმება

კლიენტთან პრეფიქსები წყვეტს, რომელი დანიშნულებები მიდიან ამ პარტნიორთან და რომელი რჩება ჩვეულებრივ ქსელში. ამიტომ 0.0.0.0/0-ის ჩანაწერი იჭერს ყველა IPv4 დანიშნულებას, და ამიტომ სრული გვირაბის პროფილის იმპორტი ჩვეულებრივ დათვალიერებას დისტანციურ მანქანაზე გზავნის. ვიწრო ჩანაწერები პირიქით აკეთებენ: მარშრუტიზაციას უკეთებენ მხოლოდ თქვენს მიერ ჩამოთვლილ ქსელებს და დანარჩენს იქ ტოვებენ, სადაც იყო. WireGuard-ის დოკუმენტაციის კრიპტოგასაღების მარშრუტიზაციის ნაწილი ორივე საქმეს ერთ ადგილას ასახელებს: გამავალი პარტნიორის არჩევასა და შემომავალი წყაროს შემოწმებას.

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

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

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

ორივე ფორმა თავისთავად სრულია და ისინი ალტერნატივებია და არა ნაბიჯები. პირველი მხოლოდ იმ ორ ქსელს ატარებს გვირაბში; მეორე ყველა დანიშნულებას აგზავნის, და ::/0 ჩანაწერი IPv6-ს ამატებს IPv4-ის ნაგულისხმევს. რომელსაც აირჩევთ, ეს პრეფიქსები არის მთელი მარშრუტიზაციის გადაწყვეტილება ამ პარტნიორისთვის, როგორც კი wg-quick დაიწყებს მარშრუტების დაყენებას.

ჰაბს სხვა სია სჭირდება

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

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

ჰოსტის პრეფიქსი ატარებს გვირაბის მისამართს, ხოლო ქსელის პრეფიქსი — იმას, რაც კლიენტის უკანაა, და ორივე საჭიროა. ჰოსტის პრეფიქსის გარეშე ჰაბი ვერ დააბრუნებს კლიენტის საკუთარ ტრაფიკს, ხოლო ქსელის პრეფიქსის გარეშე მის უკან არსებული LAN მიუწვდომელი რჩება; პარტნიორი, რომლის უკანაც არაფერია, იღებს მხოლოდ ჰოსტის პრეფიქსს.

მარშრუტების დაყენების გამოტოვება ტოვებს ხარვეზს

wg-quick, დამხმარე, რომელიც ინტერფეისს კონფიგურაციის ფაილიდან ხსნის, ამ სამუშაოს ნაწილად აყენებს ინტერფეისის მისამართებსა და მარშრუტებს. Table = off-ის დაყენება ეუბნება დამხმარეს, გამოტოვოს მარშრუტების სამუშაო, რაც არ აყენებს შემცვლელებს და პირად ქსელს მისაწვდომს არ ხდის. როცა ავტომატური მარშრუტები უკვე ასრულებენ საქმეს, საჭირო პრეფიქსების დასახელება უფრო ნათელი კონფიგურაციაა. მარშრუტების მართვის გამორთვა და შემცვლელის დაუწერელად დატოვება დიზაინი არ არის, ეს გამოტოვებაა.

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

DNS და IPv6 ცალ-ცალკე წყდება

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

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