Vai ar peering savienotam Azure VNet ir vajadzīga sava VPN vārteja?
Ar peering savienots VNet var izmantot hub VPN vārteju ar atbalstītu SKU un vienu iestatījumu katrā peering virzienā. Pārbaudiet efektīvos maršrutus, nevis peering statusu.
Parādās jauns spoke VNet, hub jau ir strādājoša site-to-site vārteja, un acīmredzamais jautājums ir, vai jāmaksā par otru vārteju. Parasti nē: vārtejas tranzīts ļauj spoke izmantot hub vārteju caur peering. Vai tas darbosies, izšķir trīs nosacījumi, un neviens no tiem nav redzams peering statusa emblēmā. Peering savienojamība un atļauja izmantot cita vārteju ir atsevišķi iestatījumi, tāpēc divi VM, kas jau var pingot viens otru, neko nepierāda par VPN ceļu.
Pirmais nosacījums: vārteja un tās trūkums spoke
Azure atbalsta vārtejas tranzītu VPN Gateway SKU, izņemot Basic, un to var pārvadāt gan reģionālais, gan globālais peering. Spoke patērē vārteju, kas tam nepieder, tāpēc tam nevar būt savas: ja spoke jau ir vārteja vai jau ir izvēlēts attālās vārtejas variants, vēlamais tranzīta iestatījums būs nepieejams vai neefektīvs. Pārbaudiet to pirms kaut kā atkļūdošanas, jo atspējotā izvēles rūtiņa ir simptoms, nevis defekts. Vispirms izlasiet SKU un esošo vārteju, tad apskatiet peering iestatījumus.
Nedzēsiet esošo spoke vārteju, lai parādītos opcija, kamēr nezināt, kas no tās ir atkarīgs. Migrācijas secība ir svarīgāka par izvēles rūtiņu.
Otrais nosacījums: viens iestatījums katrā peering virzienā
Peering ir divi objekti, pa vienam katrā VNet, un tranzīta iestatījumi atrodas dažādās šī pāra pusēs. Hub peering pret spoke ir jāļauj hub vārtejai apkalpot spoke; spoke peering pret hub ir jāpieņem hub vārteja. Microsoft vārtejas tranzīta rokasgrāmata tos nosauc pa virzieniem, un tas ir vienīgais veids, kā tos noturēt pareizi:
| 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 |
Vadīklis ar apzīmējumu remote maina nozīmi atkarībā no tā, kura VNet peering jūs rediģējat, tāpēc lasiet virzienu, nevis vārdu. Iestatiet abas puses, saglabājiet un apstipriniet, ka peering abās vietās ziņo par savienojumu.
Trešais nosacījums: adrešu telpa un atļauju robežas
Tranzīts nevar panākt, ka viens un tas pats galamērķa prefikss nozīmē divus tīklus, tāpēc hub, spoke un vietējā tīkla diapazoniem ir jābūt atšķirtiem pirms kaut kas no tā darbojas. VNet var būt arī dažādos abonementos vai dažādos nomniekos; tas nav aizliegums, bet identitātei, kas izveido vai atjaunina katru peering, ir vajadzīgas nepieciešamās atļaujas šajā tīklā. Izmaiņas starp abonementiem bieži neizdodas atļauju dēļ, un kļūdu ir viegli nepareizi nolasīt kā topoloģijas problēmu.
Pirms izmaiņām pierakstiet diapazonus un īpašniekus. Minējumi par jebkuru no tiem rada peering, kas savienojas un neko nemaršrutē.
Pārbaudiet ar efektīvajiem maršrutiem, nevis ar peering statusu
Apskatiet efektīvos maršrutus spoke darba slodzes tīkla saskarnē un atrodiet faktisko vietējā tīkla prefiksu. Pārbaudiet apakštīkla maršrutu tabulu un vai vārtejas maršrutu izplatīšana ir atspējota, jo lietotāja definēts maršruts vai pārbaudes ierīce var pārspēt ceļu, ko ierosina peering karodziņi. Pēc tam apstipriniet pretējo virzienu: vietējam tīklam jāzina, kā sasniegt spoke prefiksu pa site-to-site savienojumu, vai nu ar apgūtiem paziņojumiem, vai ar skaidru maršrutu un atbilstošu aizsargātā tīkla ierakstu klienta ierīcē. Ja prefikss trūkst kaut vienā pusē, mainīt vajag nevis peering karodziņus.
Pārbaudiet vienu pakalpojumu no spoke darba slodzes un sekojiet atbildei. Tests no VPN vārtejas vai hub VM izmanto citu avota prefiksu un citu ceļu.
Ja topoloģija apkalpo arī point-to-site klientus, atsevišķi validējiet to instalētos maršrutus. Windows klienta pakotnēm pēc topoloģijas maiņas var būt nepieciešama atkārtota ģenerēšana, un tas ir klienta maršrutēšanas uzdevums, nevis pierādījums, ka vārtejas koplietošana ir neizdevusies.
Ko vārtejas koplietošana nedod
Vārtejas tranzīts ir maršrutēšanas ērtība, nevis autorizācija. Tīkla drošības grupas, vietējie filtri un pakalpojuma līmeņa noteikumi joprojām izlemj, ko spoke darba slodze var sasniegt, tāpēc iespējojiet konkrēto avota–galamērķa pakalpojumu, nevis pieņemiet, ka koplietotais tunelis atļauj visu aiz tā.
Peering arī nav transitīvs tā, kā cilvēki cer. Pievienojot vēl vienu spoke vai privātu galapunktu, tiek ieviestas tā paša maršrutēšanas un piekļuves prasības, ko esošais tranzīta iestatījums neaptver.