Hat in Azure VNet mei peering in eigen VPN-poarte nedich?
In VNet mei peering kin de VPN-poarte fan ’e hub brûke mei in stipe SKU en ien ynstelling yn elke peering-rjochting. Kontrolearje de effektive rûtes, net de peering-status.
In nije spoke-VNet ferskynt, de hub hat al in wurkjende site-to-site-poarte, en de foar de hân lizzende fraach is oft jo foar in twadde poarte betelje moatte. Meastentiids net: poartetransyt lit de spoke de poarte fan ’e hub oer peering brûke. Trije betingsten beslisse oft dat wurkje sil, en gjinien is te sjen op it peering-statusskyldsje. Peering-ferbining en tastimming om de poarte fan in oar te brûken binne aparte ynstellings, dus twa VM’s dy’t inoar al pingje kinne, bewiisje neat oer it VPN-paad.
Earste betingst: de poarte, en it ûntbrekken fan in eigen poarte yn ’e spoke
Azure stipet poartetransyt foar VPN Gateway-SKU’s oars as Basic, en sawol regionale as globale peering kinne it drage. De spoke brûkt in poarte dy’t er net besit, dus kin er gjin eigen hawwe: as der al in poarte yn ’e spoke bestiet, of in opsje foar in poarte op ôfstân is al keazen, dan sil de transyt-ynstelling dy’t jo wolle net beskikber of net effektyf wêze. Kontrolearje dat foardat jo wat dan ek debugge, want it útskeakele kontrôlefakje is it symptoom, net de fout. Lês earst de SKU en de besteande poarte, en sjoch dan nei de peering-ynstellings.
Skraspje gjin besteande spoke-poarte om de opsje ferskine te litten oant jo witte wat derfan ôfhinklik is. De folchoarder fan ’e migraasje is wichtiger as it kontrôlefakje.
Twadde betingst: ien ynstelling yn elke peering-rjochting
In peering binne twa objekten, ien op elke VNet, en de transyt-ynstellings libje oan ferskillende kanten fan dat pear. It peering fan ’e hub nei de spoke moat de hub-poarte tastean de spoke te betsjinjen; it peering fan ’e spoke nei de hub moat de poarte fan ’e hub akseptearje. de hantlieding foar poartetransyt fan Microsoft neamt se per rjochting, en dat is de iennige manier om se goed te hâlden:
| 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 |
In kontrôle mei it label remote feroaret fan betsjutting ôfhinklik fan hokker VNet har peering jo bewurkje, lês dus de rjochting, net it wurd. Set beide kanten, bewarje en befêstigje dat it peering op beide plakken as ferbûn rapportearet.
Tredde betingst: adresromte en grinzen fan tastimmingen
Transyt kin net meitsje dat itselde bestimmingsprefiks twa netwurken betsjut, dus de berikken fan ’e hub, de spoke en it lokale netwurk moatte los fan inoar wêze foardat ien fan dit wurket. De VNet’s kinne ek yn ferskillende abonneminten of ferskillende tenants sitte; dat is gjin ferbod, mar de identiteit dy’t elke peering makket of bywurket, hat de needsaaklike tastimmingen op dat netwurk nedich. Feroarings tusken abonneminten mislearje faak op tastimmingen, en de flater is maklik ferkeard te lêzen as in topologyprobleem.
Skriuw de berikken en de eigners foar de feroaring op. Rieden oan ien fan beide leveret in peering op dy’t ferbynt en neat rûtelet.
Ferifiearje mei effektive rûtes, net mei peering-status
Sjoch nei de effektive rûtes op ’e netwurkynterface fan in spoke-wurkbelesting en fyn it werklike lokale prefiks. Kontrolearje de rûtetabel fan it subnet en oft de fersprieding fan poartetrûtes útskeakele is, want in brûker definiearre rûte of in ynspeksje-apparaat kin it paad oerskriuwe dat de peering-flaggen suggerearje. Befêstigje dêrnei de oare rjochting: it lokale netwurk moat witte hoe’t it it spoke-prefiks troch de site-to-site-ferbining berikt, itsij troch learde oankundigings, itsij troch in eksplisite rûte en in oerienkommende ynskriuwing foar beskerme netwurk op it klantapparaat. As it prefiks oan ien fan beide kanten ûntbrekt, binne de peering-flaggen net wat feroare wurde moat.
Test ien tsjinst fan in spoke-wurkbelesting en folgje it antwurd. In test fan ’e VPN-poarte of fan in hub-VM brûkt in oar boarneprefiks en in oar paad.
As de topology ek point-to-site-klanten betsjinnet, falidearje dan har ynstalleare rûtes apart. Windows-klantpakketten kinne nei in topologyferoaring opnij generearre wurde moatte, en dat is in klantrûte-taak, net in bewiis dat it dielen fan ’e poarte mislearre is.
Wat it dielen fan in poarte net jout
Poartetransyt is in rûtegemak, gjin autorisaasje. Netwurkfeiligensgroepen, lokale filters en regels op tsjinstnivo beslisse noch altyd wat in spoke-wurkbelesting berikke mei, dus skeakelje de spesifike tsjinst fan boarne nei bestimming yn, ynstee fan oan te nimmen dat de dielde tunnel alles dêrefter tastean.
Peering is ek net transityf sa’t minsken hoopje. It tafoegjen fan noch in spoke, of fan in privee-einpunt, yntrodusearret syn eigen rûte- en tagongsfoarmen dy’t de besteande transyt-ynstelling net dekt.