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 же жеке акыркы чекитти кошуу анын өз маршруттоо жана кирүү талаптарын алып келет, аларды учурдагы транзит параметри камтыбайт.