WireGuard 5G ფილიალი: ფილიალმა თავად დარეკოს ჰაბს

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

კონფიგურაცია გააკეთეთ განზრახ და შემდეგ შეამოწმეთ ის ნაწილი, რომელიც ხალხს მიაჩნია, რომ მუშაობს. ორივე ნაბიჯს წუთები სჭირდება და სწორედ მეორეში ხშირად ფარდება ეს დიზაინები.

რომელი მხარე ფლობს სტაბილურ საბოლოო წერტილს

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

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

მიეცით ფილიალს კონფიგურაცია, რომელიც ხელახალ ნუმერაციას უძლებს

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

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

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

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

შეამოწმეთ დაკავშირება და გადართვა

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

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

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

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

რას არ ხსნის ეს დიზაინი

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

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

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