ერთი OpenVPN ჰაბი, სამი LAN: მისამართების გეგმა და iroute ფაილები

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

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

დაიწყეთ გეგმით, რომლის გამოცნობაც არავის უწევს

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

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

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

უამბეთ ჰაბის ბირთვს, სად არიან ფილიალები

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

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

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

მიეცით თითოეულ ფილიალს საჭირო მარშრუტები

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

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

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

სანამ დასრულებულს უწოდებთ, ორივე მიმართულებით გამოსცადეთ

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

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

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

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