Miért igényel a pont–hely kapcsolat útvonalalapú Azure VPN-átjárót

A szabályzatalapú átjáró forgalomválasztókkal kiválasztott IPsec-alagutat épít, és nincs interfésze, amelyre az ügyfélútvonalakat átadhatná. A pont–hely kapcsolat útválasztási funkció: az átjáró ügyfélcímkészlettel rendelkezik, és útvonalakat telepít ezekhez az ügyfelekhez a virtuális hálózatban. Ez az eltérés az oka annak, hogy a portál nem mutat semmilyen lehetőséget a hozzáadására. A meglévő átjárón semmi sem kapcsolható át az interfész létrehozásához, ezért a változás csere, nem pedig konfigurációszerkesztés.

A sorrend fontosabb az egyes lépéseknél. Ha a sorrend rossz, a helyek közötti kiesés túllépi a karbantartási ablakot.

Mit tesz valójában a szabályzatalapú átjáró

A szabályzatalapú átjáró a csomagokat a kapcsolaton beállított forgalomválasztókhoz illeszti, és az egyezéseket egyetlen alagútba küldi. Nincs címmel rendelkező alagútinterfész, és a virtuális hálózatban sehol nem jelenik meg ügyfelenkénti útvonal. Az útvonaltábla egyszerűen megkapja az átjáróra mutató helyi előtagokat. Ez a modell elegendő két rögzített címtér közötti helyek közötti kapcsolathoz.

Az útvonalalapú átjáró fordítva működik: alagútinterfészt tesz elérhetővé, és az útvonalak döntik el, mi lép be rajta. A pont–hely kapcsolat és minden olyan kialakítás, amelynek partnerei köre változik, ezen interfész létezésétől függ.

Miért van szüksége az ügyfélkészletnek erre az interfészre

Amikor egy laptop csatlakozik, az átjáró címet oszt ki neki a pont–hely készletből. A virtuális hálózatnak ekkor olyan útvonalra van szüksége, amely kimondja, hogy ez a cím az átjárón keresztül elérhető. Alagútinterfész nélkül nincs mihez csatlakoztatni azt az útvonalat.

A készlet abból a tartományból származik, amelyet ön kijelöl, és az átjáró abból oszt ki. Ha ez a tartomány átfedésben van a helyi hálózattal vagy egy társított virtuális hálózattal, az ütközés csak azután derül ki, hogy egy ügyfél csatlakozott, ami rossz pillanat a felfedezésére. Foglalja le a készletet a migráció megkezdése előtt.

A típus sem kapcsolatonkénti beállítás. Egy átjárónak egy típusa van, és minden kapcsolat, amelyet tart, ennek megfelelően viselkedik, ezért a vegyes kialakításhoz második átjáró kell, nem második kapcsolat.

A típus létrehozáskor rögzül

A Microsoft szerint a virtuális hálózati átjáró üzembe helyezés után nem változtatható meg szabályzatalapú és útvonalalapú között. Nincs átalakítási parancs és nincs kapcsoló a portálon. A második átjáró létrehozása ugyanabban az alhálózatban szintén nem megoldás, mert az Azure virtuális hálózatonként egy átjárót engedélyez. A migráció tehát eltávolítás, újjáépítés és újracsatlakozás.

Ez az SKU-döntést is ugyanabba az építésbe vonja. A későbbi nagyobb SKU-ra váltás egy újabb átjárócsere egy újabb kieséssel.

Egy átjáró, egy GatewaySubnet

Az átjáró a GatewaySubnet nevű alhálózatban lakik, és csak egy átjáró foglalja el. Az alhálózat méretezése az előkészítés része, mert a nagyobb SKU több címet igényel, és az alhálózat utólag nem csökkenthető. Jegyezze fel az aktuális helyek közötti beállításokat, a megosztott kulcsot, a helyi hálózati átjárót és a tényleges útvonalakat, mielőtt bármihez hozzányúlna. Utána kezelje az ablakot kiesésként, mert a helyek közötti alagút leállva marad, amíg az új kapcsolat be nem állítódik.

Az újjáépítési sorrend, amely korlátozza a kiesést: hozza létre az útvonalalapú átjárót, hozza létre újra a helyek közötti kapcsolatot ugyanahhoz a helyi hálózati átjáróhoz, igazolja az alagutat és egy gép–gép kérést, és csak ezután adja hozzá a pont–hely kapcsolatot, és állítson elő új ügyfélcsomagot.

Mit nem javít meg a csere

Egy második korlát a partnerhez tartozik, nem az Azure-hoz. A szabályzatalapú helyi eszköz csak azt a virtuális hálózatot érheti el, amelyhez kapcsolódik, és ugyanazon az átjárón keresztül nem tud átlépni más helyi hálózatokba vagy más virtuális hálózatokba. Az Azure-oldal cseréje nem változtatja meg, mit választhat a partner.

Ha a követelmény valóban helyek közötti átjárás, a válasz egy útvonalalapú partnereszköz vagy olyan topológia, amelyben minden cél külön végződik. Ezt még azelőtt rendezze, hogy dátumot ígér, mert a puszta átjárócsere nem szállítja ezt.

A műveletek és ellenőrzések sorrendje

Minden képességet külön ellenőrizzen. Először a helyek közötti alagút állapotát és egy gép–gép kérést, majd egy pont–hely kapcsolatot és egy privát erőforrást, majd minden átjárási útvonalat, amelyet a kialakítás állít. A zöld átjáróállapot csak azt bizonyítja, hogy a biztonsági társítás feljött, és semmi többet. Tartsa az ellenőrzéseket ebben a sorrendben, hogy a hiba arra a szakaszra mutasson, amely behozta.

Minden topológiaváltozás után állítsa elő újra az ügyfélcsomagokat, és tartsa a készletet minden helyi és társított tartományon kívül. A korlátok és az SKU-különbségek az Azure VPN Gateway beállítási referenciájában vannak összegyűjtve.