Peering арқылы қосылған Azure VNet-ке өз VPN шлюзі қажет пе?
Peering арқылы қосылған VNet hub-тың VPN шлюзін қолдау көрсетілетін SKU-мен және peering-тің әр бағытында бір параметрмен пайдалана алады. Peering күйін емес, тиімді маршруттарды тексеріңіз.
Жаңа spoke VNet пайда болады, hub-та жұмыс істеп тұрған site-to-site шлюзі бар, ал айқын сұрақ — екінші шлюз үшін төлеу керек пе. Әдетте жоқ: шлюз транзиті spoke-қа peering арқылы hub шлюзін пайдалануға мүмкіндік береді. Бұл жұмыс істей ме, жоқ па — үш шарт шешеді, және олардың ешқайсысы peering күйінің белгісінен көрінбейді. Peering байланысы мен біреудің шлюзін пайдалану рұқсаты бөлек параметрлер, сондықтан бір-бірін ping ете алатын екі VM VPN жолы туралы ештеңе дәлелдемейді.
Бірінші шарт: шлюз және spoke-та оның болмауы
Azure Basic-тен басқа VPN Gateway SKU-лары үшін шлюз транзитін қолдайды, оны аймақтық та, жаһандық та peering көтере алады. Spoke өзіне тиесілі емес шлюзді тұтынады, сондықтан өзінің шлюзі бола алмайды: егер spoke-та шлюз бұрыннан бар болса немесе қашықтағы шлюз опциясы бұрын таңдалған болса, қалаған транзит параметрі қолжетімсіз немесе тиімсіз болады. Кез келген нәрсені жөндеуден бұрын мұны тексеріңіз, өйткені өшірілген құсбелгі — белгі, ақау емес. Алдымен SKU мен бар шлюзді оқыңыз, содан кейін peering параметрлерін қараңыз.
Опция көрінуі үшін бар spoke шлюзін оған не тәуелді екенін білмейінше жоймаңыз. Көшу реті құсбелгіден маңыздырақ.
Екінші шарт: peering-тің әр бағытында бір параметр
Peering — екі нысан, әр VNet-те біреу, ал транзит параметрлері сол жұптың әр түрлі жағында орналасқан. Hub-тың spoke-қа қарай peering-і hub шлюзінің spoke-қа қызмет көрсетуіне рұқсат беруі керек; spoke-тың hub-қа қарай peering-і hub шлюзін қабылдауы керек. Microsoft-тың шлюз транзиті жөніндегі нұсқаулығы оларды бағыт бойынша атайды, және оларды дұрыс ұстаудың жалғыз жолы осы:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
remote деп таңбаланған басқару элементі қай VNet-тің peering-ін өңдеп жатқаныңызға қарай мағынасын өзгертеді, сондықтан сөзді емес, бағытты оқыңыз. Екі жақты орнатыңыз, сақтаңыз және peering екі жерде де қосылған деп хабарлайтынын растаңыз.
Үшінші шарт: мекенжай кеңістігі және рұқсат шекаралары
Транзит бір мақсатты префиксті екі желі білдіруге мәжбүрлей алмайды, сондықтан hub, spoke және жергілікті желі ауқымдары бұлардың кез келгені жұмыс істеуінен бұрын бір-бірімен қиылыспауы керек. VNet-тер әртүрлі жазылымдарда немесе әртүрлі тұрғындарда болуы мүмкін; бұл тыйым емес, бірақ әр peering-ті жасайтын немесе жаңартатын сәйкестікке сол желіде қажетті рұқсаттар керек. Жазылымдар арасындағы өзгерістер жиі рұқсатқа байланысты сәтсіз болады, ал қатені топология мәселесі деп қате оқу оңай.
Өзгеріске дейін ауқымдар мен иелерін жазып қойыңыз. Екеуінің бірін болжау қосылатын, бірақ ештеңені маршруттамайтын peering береді.
Peering күйімен емес, тиімді маршруттармен тексеріңіз
Spoke жұмыс жүктемесінің желілік интерфейсіндегі тиімді маршруттарды қарап, жергілікті желінің нақты префиксін табыңыз. Ішкі желінің маршрут кестесін және шлюз маршруттарының таралуы өшірілгенін тексеріңіз, өйткені пайдаланушы анықтаған маршрут немесе тексеру құрылғысы peering жалаушалары ұсынатын жолды басып кетуі мүмкін. Содан кейін қарсы бағытты растаңыз: жергілікті желі site-to-site байланысы арқылы spoke префиксіне қалай жетуді білуі керек, бұл үйренген хабарландырулар арқылы немесе нақты маршрут және клиент құрылғысындағы сәйкес қорғалған желі жазбасы арқылы болсын. Егер префикс екі жақтың бірінде жоқ болса, өзгерту керек нәрсе peering жалаушалары емес.
Spoke жұмыс жүктемесінен бір қызметті сынап көріп, жауапты бақылаңыз. VPN шлюзінен немесе hub VM-нен сынау басқа бастау префиксі мен басқа жолды пайдаланады.
Егер топология point-to-site клиенттеріне де қызмет көрсетсе, олардың орнатылған маршруттарын бөлек тексеріңіз. Топология өзгергеннен кейін Windows клиент пакеттерін қайта жасау қажет болуы мүмкін, және бұл шлюзді бөлісу сәтсіз болғанының дәлелі емес, клиент маршруттау міндеті.
Шлюзді бөлісу нені бермейді
Шлюз транзиті — маршруттауға қолайлылық, рұқсат емес. Желі қауіпсіздігі топтары, жергілікті сүзгілер және қызмет деңгейіндегі ережелер әлі де spoke жұмыс жүктемесінің неге жете алатынын шешеді, сондықтан ортақ туннель оның артындағының бәріне рұқсат береді деп болжаудың орнына нақты бастаудан мақсатқа қызметті қосыңыз.
Peering де адамдар күткендей транзитивті емес. Тағы бір spoke немесе жеке соңғы нүктені қосу оның өз маршруттау және қатынау талаптарын әкеледі, оларды қолданыстағы транзит параметрі қамтымайды.