ორი ფიჭური ობიექტი შიდა პორტების გარეშე: ააშენეთ მომუშავე ჰაბი

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

არც ერთ ობიექტზე ზარი ვერ შედის, ამიტომ ორივემ უნდა დარეკოს გარეთ

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

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

ორი ბრძანება პასუხობს თქვენს წინ მდგარი ობიექტის მისამართების კითხვას. გაუშვით ისინი ობიექტის მარშრუტიზატორზე და არა მის უკან მდგარ ნოუთბუქზე:

ip -4 addr show scope global
ip -6 addr show scope global

ვინ წარმოადგენს თანატოლებს და ვინ ატარებს პაკეტებს

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

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

ერთი მარშრუტი თითო ობიექტზე, რომელსაც თანატოლი ფლობს

ჰაბს სჭირდება ერთი გვირაბი თითო ობიექტზე, ცალკე LAN პრეფიქსი თითოეულის უკან და მარშრუტი თითოეული პრეფიქსისთვის, რომელიც მის მფლობელს ასახელებს. მაგალითში ჰაბი არის 10.61.0.1, ობიექტი A არის 10.61.0.11 LAN 10.60.10.0/24-ით, ხოლო ობიექტი B არის 10.61.0.12 LAN 10.60.20.0/24-ით. ქვემოთ ყოველი მარშრუტი მიუთითებს პრეფიქსის მფლობელ თანატოლზე და არა გვირაბის ინტერფეისზე:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

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

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

შეინარჩუნეთ ყოველი ასახვა ცოცხალი ოპერატორის გავლით

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

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

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

დაამტკიცეთ ორივე მიმართულება, შემდეგ აღდგენა

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

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

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