ვარსკვლავი და სხივები თუ სრული ქსელი: რომელი VPN ტოპოლოგია შეესაბამება თქვენს ობიექტებს

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

უპირველეს ყოვლისა დაითვალეთ თანატოლთა ურთიერთობები

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

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

გადაწყვეტილება ტრაფიკის ნარევმა მიიღოს, არა ნახატმა

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

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

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

ჰაბს უნდა უთხრათ, რომ გაატაროს

ორი მომუშავე სხივ-ჰაბ გვირაბი სხივ-სხივ წვდომას არ ქმნის. ჰაბს სჭირდება ჩართული IP გატარება, მარშრუტი ყოველ სხივის ქსელზე, ფაირვოლის წესი, რომელიც ტრანზიტს უშვებს და გამოთვლილი დაბრუნების გზა; ყოველ სხივს სჭირდება მარშრუტი მეორე ობიექტის პრეფიქსებისთვის. Linux ჰაბზე ეს არის net.ipv4.ip_forward=1 პლუს FORWARD ჯაჭვი, რომელიც წყვილს ჩუმად არ ყრის, ხოლო პოლიტიკაზე დაფუძნებულ IPsec-ში ეს ტრაფიკის სელექტორებია, რომლებიც ორივე ბოლოში დისტანციური სხივის ქვექსელს ჩამოთვლიან. strongSwan-ში გატარების შენიშვნები ფარავს ბირთვისა და ფაირვოლის მხარეს, როცა სწორედ ეს ფენა გაკლიათ. იაფი გამოცდაა ტრაფიკის გაგზავნა ერთი სხივიდან მეორის სერვისზე ჰაბის მრიცხველებზე დაკვირვებისას; წესი, რომელიც არასდროს იზრდება, ნიშნავს რომ რიგი არასწორია და არა მარშრუტი.

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

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

ჯერ ხარვეზი დააპროექტეთ, შემდეგ ჩვეულებრივი გზა

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

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

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

აირჩიეთ ცვლილების ღირებულებით, შემდეგ გადაამოწმეთ მარშრუტები

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

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

შეინახეთ ორივე ნახატი წვდომის მატრიცასთან ერთად და გადახედეთ მათ, როცა ობიექტი ემატება; ღირებულება, რომელსაც მართავთ, შემდეგი ცვლილების ღირებულებაა და არა მიმდინარე სურათის ელეგანტურობა.