ტრაფიკის მარშრუტიზაცია ორ ფილიალს შორის Azure VPN კარიბჭის მეშვეობით
ორი Site-to-Site კავშირი ერთ Azure VPN კარიბჭეზე შეიძლება ფილიალების ტრაფიკის გატარებას უზრუნველყოფდეს, მაგრამ მხოლოდ მაშინ, როცა ორივე მხარე პრეფიქსს სწავლობს და LAN-ის დაბრუნების გზა არსებობს.
ორ ფილიალს შეუძლია ტრაფიკის გაცვლა Azure VPN კარიბჭის მეშვეობით მათ შორის პირდაპირი გვირაბის გარეშე. თითოეული ფილიალი ხსნის Site-to-Site კავშირს იმავე კარიბჭესთან, და კარიბჭე ნასწავლ პრეფიქსებს გადასცემს ორ კავშირს შორის. ამას ამუშავებს არა მეორე გვირაბი, არამედ მარშრუტების გაცვლა: A ფილიალმა უნდა ისწავლოს B ფილიალის პრეფიქსი, ხოლო B-მ A-ს პრეფიქსი. გაიარეთ ქვემოთ მოცემული შემოწმებები თანმიმდევრობით და გაჩერდით პირველ წარუმატებელზე, რადგან ყოველი შემდეგი ნაბიჯი მასზეა დამოკიდებული.
წინაპირობები, სანამ რამეს დააკონფიგურირებთ
ოთხი პირობა განსაზღვრავს, შეიძლება თუ არა ეს დიზაინი საერთოდ იმუშაოს. კარიბჭე უნდა იყოს მარშრუტზე დაფუძნებული და იყოს BGP-ის მხარდამჭერ SKU-ზე, ორივე კავშირზე BGP უნდა იყოს ჩართული, ფილიალების მისამართების სივრცეები არ უნდა ემთხვეოდეს, და არც ერთ მხარეს არ უნდა დაეყრდნოს NAT-ს რეალური პრეფიქსის დასამალად.
დაგეგმეთ ASN-ები განზრახ. Azure-ის დოკუმენტირებული ნაგულისხმევი მნიშვნელობაა 65515, და თითოეულ ფილიალის მარშრუტიზატორს სჭირდება საკუთარი კერძო ASN, რომელიც არ ეჯახება კარიბჭეს ან მეორე ფილიალს. ნაგულისხმევი მნიშვნელობის ხელახლა გამოყენება არსებული კარიბჭის კონფიგურაციის შემოწმების გარეშე ის გზაა, რომლითაც AS მარშრუტი მოგვიანებით უარყოფილია.
ასევე დაადასტურეთ, რომ არ ელით VNet peering-ის ქცევას. კარიბჭე ცვლის მარშრუტებს თქვენს მიერ კონფიგურირებულ ორ კავშირს შორის; ის არ აქცევს თვითნებურ peering-ებს ტრანზიტულად. თუ მესამე ქსელმა ორივე ფილიალამდე უნდა მიაღწიოს, მას სჭირდება საკუთარი კავშირი ან საკუთარი მარშრუტი, და არა ვარაუდი, რომ კარიბჭე ტრაფიკს გაანაწილებს. ჩაწერეთ ეს საზღვარი პირველ ცვლილების ფანჯარამდე, რადგან ეს არის ის დიზაინის გადაწყვეტილება, რომელსაც ხალხი უბრუნდება, როცა მოგვიანებით ახალი ადგილი ემატება.
დააკონფიგურირეთ ამ თანმიმდევრობით
თითოეულ ნაბიჯს აქვს დაკვირვებადი შედეგი, ამიტომ არ გადახვიდეთ შემდეგზე, სანამ ის არ გამოჩნდება.
- ჩართეთ BGP ვირტუალური ქსელის კარიბჭეზე და ჩაიწერეთ მისი ASN და peer მისამართი.
- შექმენით ლოკალური ქსელის კარიბჭე თითოეული ფილიალისთვის მისი რეალური მისამართების სივრცით, მისი ASN-ით და BGP peer მისამართით.
- შექმენით თითოეული Site-to-Site კავშირი და ჩართეთ BGP თავად კავშირზე.
- დააკონფიგურირეთ ფილიალის მარშრუტიზატორი Azure-ის მიერ მინიჭებულ კარიბჭის მისამართთან peering-ისთვის, და არა ვარაუდით კარიბჭის საჯარო IKE ბოლო წერტილთან.
მეოთხე ნაბიჯი არის ადგილი, სადაც უმეტესი მცდელობა იჭედება. BGP peer მისამართი, რომელსაც Azure იუწყება, არის ის, რომელიც ფილიალის მარშრუტიზატორმა უნდა გამოიყენოს მეზობლად, და ეს ყოველთვის არ არის ის მისამართი, რომელსაც ხალხი გვირაბის დიაგრამიდან ელის.
გამოაცხადეთ თავად ფილიალის პრეფიქსი, მაგალითად 10.10.0.0/16 A-დან და 10.20.0.0/16 B-დან. არ გამოაცხადოთ ნაგულისხმევი მარშრუტი ან ფართო აგრეგატი დაკარგული კონკრეტული ქსელის დასაფარად; უფსკრული მოგვიანებით ბრუნდება როგორც ჩუმი შავი ხვრელი.
შეამოწმეთ მარშრუტების გაცვლა ორივე მხარეს
კავშირის სტატუსი არ არის შემოწმება. IPsec შეიძლება იყოს აქტიური ორივე კავშირზე, მაშინ როცა მათ შორის არც ერთი პრეფიქსი არ გადადის. წაიკითხეთ კარიბჭის BGP peer-ები და მისი ნასწავლი მარშრუტები, შემდეგ დაადასტურეთ, რომ მეორე ფილიალის მიმართულებით მარშრუტი გამოყენებად ბილიკად ჩანს.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
BGP ცხრილში არსებული პრეფიქსი მაინც შეიძლება დათმოს გადაგზავნის გადაწყვეტილება სტატიკურ მარშრუტთან ან უფრო კონკრეტულ პრეფიქსთან. შეამოწმეთ შერჩეული მარშრუტი და არა მხოლოდ მიღებული.
მიჰყევით დაბრუნების გზას LAN-ის მხარეს
ეს არის ის ნაწილი, რომელიც Azure-ში სწორად გამოიყურება და ადგილზე ფარდება. A ფილიალის ჰოსტი თავის პაკეტს A-ს VPN მარშრუტიზატორს მხოლოდ მაშინ უგზავნის, თუ ეს მარშრუტიზატორი მისი ნაგულისხმევი კარიბჭეა, ან თუ ჰოსტს ან მის კარიბჭეს B-ის პრეფიქსის მარშრუტი აქვს. იგივე უნდა იყოს სწორი საპირისპირო მიმართულებითაც.
თუ ცალკე ბირთვული კომუტატორია LAN-ის ნაგულისხმევი კარიბჭე, მას სჭირდება მეორე ფილიალის მიმართულებით მარშრუტი, რომელიც VPN მარშრუტიზატორზე მიუთითებს. მის გარეშე მოთხოვნა მოდის და პასუხი ინტერნეტის გზით გადის, და მომხმარებელი ხედავს კავშირს, რომელიც იხსნება და შემდეგ ილევა.
ამის გამოსასწორებლად ნუ მიმართავთ ქსელური უსაფრთხოების ჯგუფს კარიბჭის ქვექსელზე. ამ ქვექსელს თავისი მოთხოვნები აქვს და იქ NSG არ არის ფილიალის მხარის პოლიტიკის მხარდაჭერილი შემცვლელი. ფილტრაცია ფილიალების ფაირვოლებზე და თავად სამუშაო დატვირთვებზე უნდა იყოს, სადაც წესებს მათი მფლობელები გადახედავენ. ამ წესების ქვექსელის NSG-ში გადატანა მათ იმ გუნდსაც უმალავს, რომელიც შემდეგ გაუმართაობას გაუმართავს.
დაუშვით ოპერაცია, შემდეგ დაამტკიცეთ უარყოფილი ტესტით
ნასწავლი მარშრუტი ნებართვა არ არის. დაუშვით ის წყარო, დანიშნულება და სერვისი, რომლებიც ნამდვილად გჭირდებათ, ფილიალების ფაირვოლების და ბოლო წერტილის პოლიტიკის მეშვეობით, და დანარჩენი უარყოფილი დატოვეთ.
ტესტეთ A ფილიალის ჩვეულებრივი სამუშაო დატვირთვიდან B ფილიალის რეალურ სერვისამდე, დაადასტურეთ პასუხი, შემდეგ სცადეთ ოპერაცია, რომელიც აკრძალული უნდა დარჩეს. VPN მოწყობილობის მიერ შექმნილმა ტრაფიკმა შეიძლება სხვა წყაროს მისამართი გამოიყენოს და LAN მარშრუტიზაციის ეტაპი გამოტოვოს, ამიტომ მარშრუტიზატორიდან წარმატებული ping ნაკლებს ამტკიცებს, ვიდრე ჩანს.
დაასრულეთ ოთხი ფაქტის ჩაწერით: გაცვლილი პრეფიქსები, გამოყენებული ASN-ები, თითოეული მხარის LAN დაბრუნების გზა და პოლიტიკა, რომელიც სერვისს უშვებს. თუ ერთი მათგანი აკლია, კონფიგურაცია მუშაობს პირველ ცვლილებამდე და შემდეგ ვერავინ ხსნის, რატომ.