Szüksége van a peeringgel összekapcsolt Azure VNetnek saját VPN-átjáróra?
A peeringgel összekapcsolt VNet használhatja a hub VPN-átjáróját támogatott SKU-val és egy-egy beállítással minden peering-irányban. A hatékony útvonalakat ellenőrizze, ne a peering állapotát.
Megjelenik egy új spoke VNet, a hub már rendelkezik működő site-to-site átjáróval, és a kézenfekvő kérdés, hogy fizetnie kell-e egy második átjáróért. Általában nem: az átjáró-tranzit lehetővé teszi, hogy a spoke a peering-en keresztül használja a hub átjáróját. Három feltétel dönti el, hogy ez működik-e, és egyik sem látszik a peering állapotjelvényén. A peering-kapcsolat és a más átjárójának használatára vonatkozó engedély külön beállítás, ezért két VM, amelyek már pingelik egymást, semmit sem bizonyít a VPN-útvonalról.
Első feltétel: az átjáró, és a spoke sajátjának hiánya
Az Azure a Basic kivételével támogatja az átjáró-tranzitot a VPN Gateway SKU-k esetében, és regionális és globális peering is hordozhatja. A spoke nem a saját tulajdonában lévő átjárót használ, ezért nem lehet sajátja: ha a spoke-ban már létezik átjáró, vagy már ki van választva a távoli átjáró beállítás, akkor a kívánt tranzitbeállítás nem lesz elérhető vagy hatástalan. Ezt még bármilyen hibakeresés előtt ellenőrizze, mert a letiltott jelölőnégyzet a tünet, nem a hiba. Először olvassa el az SKU-t és a meglévő átjárót, aztán nézze meg a peering beállításait.
Ne törölje a meglévő spoke átjárót, hogy megjelenjen a beállítás, amíg nem tudja, mi függ tőle. A migráció sorrendje fontosabb a jelölőnégyzetnél.
Második feltétel: egy beállítás minden peering-irányban
A peering két objektum, egy-egy minden VNeten, és a tranzitbeállítások ennek a párnak a különböző oldalain élnek. A hub spoke felé irányuló peeringjének engedélyeznie kell, hogy a hub átjárója kiszolgálja a spoke-ot; a spoke hub felé irányuló peeringjének el kell fogadnia a hub átjáróját. A Microsoft átjáró-tranzit útmutatója irányonként nevezi meg őket, és ez az egyetlen módja annak, hogy helyesen tartsa őket:
| 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 |
A remote feliratú vezérlő jelentése attól függően változik, melyik VNet peeringjét szerkeszti, ezért az irányt olvassa, ne a szót. Állítsa be mindkét oldalt, mentse, és erősítse meg, hogy a peering mindkét helyen kapcsolódottként jelentkezik.
Harmadik feltétel: címterület és engedélyhatárok
A tranzit nem teheti meg, hogy ugyanaz a célprefix két hálózatot jelentsen, ezért a hub, a spoke és a helyi hálózat tartományainak elkülönülőknek kell lenniük, mielőtt bármi ebből működik. A VNetek különböző előfizetésekben vagy különböző bérlőkben is lehetnek; ez nem tiltás, de a peeringet létrehozó vagy frissítő identitásnak rendelkeznie kell a szükséges engedélyekkel azon a hálózaton. Az előfizetések közötti változtatások gyakran engedélyek miatt hiúsulnak meg, és a hibát könnyű topológiai problémaként félreolvasni.
A változtatás előtt írja le a tartományokat és a tulajdonosokat. Bármelyiknek a találgatása olyan peeringet eredményez, amely csatlakozik, és semmit nem irányít.
Hatékony útvonalakkal ellenőrizze, ne a peering állapotával
Nézze meg a hatékony útvonalakat a spoke számítási feladat hálózati adapterén, és keresse meg a tényleges helyi prefixet. Ellenőrizze az alhálózat útvonaltábláját, és hogy le van-e tiltva az átjáró-útvonalak terjesztése, mert egy felhasználó által meghatározott útvonal vagy egy vizsgáló eszköz felülírhatja a peering-jelzők által javasolt útvonalat. Ezután erősítse meg a másik irányt: a helyi hálózatnak tudnia kell, hogyan érje el a spoke prefixét a site-to-site kapcsolaton keresztül, akár megtanult hirdetések, akár egy explicit útvonal és az ügyféleszközön lévő megfelelő védett hálózati bejegyzés révén. Ha a prefix bármelyik oldalon hiányzik, nem a peering-jelzőket kell módosítani.
Teszteljen egy szolgáltatást a spoke számítási feladatából, és kövesse a választ. A VPN-átjáróról vagy egy hub VM-ről végzett teszt más forrás-prefixet és más útvonalat gyakorol.
Ha a topológia point-to-site ügyfeleket is kiszolgál, külön ellenőrizze a telepített útvonalaikat. A Windows ügyfélcsomagjait topológiaváltozás után újra kell generálni, és ez ügyfél-útválasztási feladat, nem annak bizonyítéka, hogy az átjáró megosztása meghiúsult.
Mit nem ad meg az átjáró megosztása
Az átjáró-tranzit útválasztási kényelem, nem felhatalmazás. A hálózati biztonsági csoportok, a helyi szűrők és a szolgáltatási szintű szabályok továbbra is eldöntik, mit érhet el a spoke számítási feladata, ezért engedélyezze a konkrét forrás-cél szolgáltatást, ahelyett hogy feltételezné, hogy a megosztott alagút mindent engedélyez mögötte.
A peering sem tranzitív úgy, ahogy az emberek remélik. Egy újabb spoke vagy egy privát végpont hozzáadása saját útválasztási és hozzáférési követelményeket hoz, amelyeket a meglévő tranzitbeállítás nem fed le.