Маршрутызацыя трафіку паміж дзвюма філіямі праз шлюз VPN Azure
Два злучэнні «сайт-сайт» на адным шлюзе VPN Azure могуць перадаваць трафік філій, але толькі калі абодва канцы вывучаць прэфікс і існуе зваротны шлях у LAN.
Дзве філіі могуць абменьвацца трафікам праз шлюз VPN Azure без якога-небудзь прамога тунеля паміж імі. Кожная філія адкрывае злучэнне «сайт-сайт» да таго ж шлюза, і шлюз перадае вывучаныя прэфіксы паміж двума злучэннямі. Працуе гэта не дзякуючы другому тунелю, а дзякуючы абмену маршрутамі: філія A павінна вывучыць прэфікс філіі B, а B — прэфікс A. Прайдзіце праверкі ніжэй па парадку і спыніцеся на першай, якая не пройдзе, бо кожны наступны крок залежыць ад яе.
Папярэднія ўмовы, перш чым нешта наладжваць
Чатыры ўмовы вырашаюць, ці можа гэтая схема ўвогуле працаваць. Шлюз павінен быць заснаваны на маршрутах і мець SKU, які падтрымлівае BGP, на абодвух злучэннях павінен быць уключаны BGP, адрасныя прасторы філій не павінны перакрывацца, і ні адзін бок не павінен спадзявацца на NAT, каб схаваць свой сапраўдны прэфікс.
Плануйце ASN свядома. Дакументаванае значэнне па змаўчанні ў Azure — 65515, і кожнаму маршрутызатару філіі патрэбны ўласны прыватны ASN, які не сутыкаецца са шлюзам ці іншай філіяй. Паўторнае выкарыстанне значэння па змаўчанні без праверкі існуючай канфігурацыі шлюза — гэта спосаб, якім шлях AS пазней адхіляецца.
Таксама пераканайцеся, што вы не чакаеце паводзін пірынгу VNet. Шлюз абменьваецца маршрутамі паміж двума злучэннямі, якія вы наладзілі; ён не робіць адвольныя пірынгі транзітыўнымі. Калі трэцяя сетка павінна дасягаць абедзвюх філій, ёй патрэбна ўласнае злучэнне або ўласны шлях маршруту, а не здагадка, што шлюз размеркуе трафік. Запішыце гэтую мяжу да першага акна змен, бо гэта тое праектнае рашэнне, да якога людзі вяртаюцца, калі пазней дадаюць сайт.
Наладжвайце ў такім парадку
Кожны крок мае назіраны вынік, таму не рухайцеся далей, пакуль ён не з'явіцца.
- Уключыце BGP на шлюзе віртуальнай сеткі і запішыце яго ASN і адрас піра.
- Стварыце лакальны шлюз сеткі для кожнай філіі з яе сапраўднай адраснай прасторай, яе ASN і адрасам піра BGP.
- Стварыце кожнае злучэнне «сайт-сайт» і ўключыце BGP на самім злучэнні.
- Наладзьце маршрутызатар філіі на пірынг з адрасам шлюза, які прызначыў Azure, а не з публічнай канцавой кропкай IKE шлюза па здагадцы.
Чацвёрты крок — гэта месца, дзе большасць спроб захрасае. Адрас піра BGP, які паведамляе Azure, — гэта той, які маршрутызатар філіі павінен выкарыстоўваць як сусед, і ён не заўсёды той адрас, які людзі чакаюць па схеме тунеля.
Абвяшчайце сам прэфікс філіі, напрыклад 10.10.0.0/16 з A і 10.20.0.0/16 з B. Не абвяшчайце маршрут па змаўчанні або шырокі агрэгат, каб пакрыць адсутную канкрэтную сетку; прабел пазней вернецца як ціхая чорная дзірка.
Праверце абмен маршрутамі на абодвух канцах
Стан злучэння — гэта не праверка. IPsec можа быць уключаны на абодвух злучэннях, пакуль ні адзін прэфікс не перасякае паміж імі. Прачытайце піраў BGP шлюза і яго вывучаныя маршруты, затым пераканайцеся, што маршрут да іншай філіі выглядае як прыдатны шлях.
| 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 адпраўляе свой пакет маршрутызатару VPN філіі A толькі калі гэты маршрутызатар з'яўляецца яго шлюзам па змаўчанні, або калі хост ці яго шлюз мае маршрут да прэфікса B. Тое ж павінна быць праўдай і ў адваротным кірунку.
Калі асобны асноўны камутатар з'яўляецца шлюзам LAN па змаўчанні, яму патрэбны маршрут да іншай філіі, які паказвае на маршрутызатар VPN. Без яго запыт прыходзіць, а адказ сыходзіць праз інтэрнэт-шлях, і карыстальнік бачыць злучэнне, якое адкрываецца, а потым завісае.
Не бярыце групу сеткавай бяспекі на падсетцы шлюза, каб гэта выправіць. У гэтай падсеткі свае патрабаванні, і NSG там не з'яўляецца падтрыманай заменай палітыкі на баку філіі. Фільтраванне належыць брандмаўэрам філій і самім нагрузкам, дзе правілы могуць праглядаць іх уладальнікі. Перанясенне гэтых правілаў у NSG падсеткі таксама хавае іх ад каманды, якая будзе адладжваць наступны збой.
Дазвольце аперацыю, затым дакажыце яе адмоўным тэстам
Вывучаны маршрут — гэта не дазвол. Дазвольце крыніцу, пункт прызначэння і службу, якія вам сапраўды патрэбны, праз брандмаўэры філій і палітыку канцавой кропкі, а астатняе пакіньце забароненым.
Тэстуйце са звычайнай нагрузкі ў філіі A да рэальнай службы ў філіі B, пацвердзіце адказ, затым паспрабуйце аперацыю, якая павінна застацца забароненай. Трафік, створаны самім прыладай VPN, можа выкарыстоўваць іншы адрас крыніцы і прапускаць этап маршрутызацыі LAN, таму паспяховы ping з маршрутызатара даказвае менш, чым здаецца.
Завяршыце, запісаўшы чатыры факты: прэфіксы, якімі абмяняліся, ASN, якія выкарыстоўваюцца, зваротны шлях LAN для кожнага боку і палітыку, якая дазваляе службу. Калі аднаго з іх няма, налада працуе да першай змены, а потым ніхто не можа растлумачыць чаму.