VPN Gateway – gyakori kérdések

Ez a cikk az Azure VPN Gateway helyek közötti kapcsolataival, hibrid konfigurációs kapcsolataival és virtuális hálózati (VNet) átjáróival kapcsolatos gyakori kérdésekre ad választ. Átfogó információkat tartalmaz a helyek közötti (P2S), a helyek közötti (S2S) és a virtuális hálózatok közötti konfigurációs beállításokról, beleértve az Internet Protocol Security (IPsec) és az Internet Key Exchange (IKE) protokollokat.

Csatlakozás virtuális hálózatokhoz

Összekapcsolhatok eltérő Azure-régiókban található virtuális hálózatokat?

Igen. Nincs régiókorlátozás. Egy virtuális hálózat csatlakozhat egy másik virtuális hálózathoz ugyanabban az Azure-régióban vagy egy másik régióban.

Összekapcsolhatok egymással különböző előfizetésekben található virtuális hálózatokat?

Igen.

Megadhatok privát DNS-kiszolgálókat a virtuális hálózatomban VPN-átjáró konfigurálásakor?

Ha dns-kiszolgálót vagy -kiszolgálókat ad meg a virtuális hálózat létrehozásakor, a virtuális magánhálózati (VPN) átjáró ezeket a DNS-kiszolgálókat használja. Ellenőrizze, hogy a megadott DNS-kiszolgálók képesek-e feloldani az Azure-hoz szükséges tartományneveket.

Csatlakozhatok több helyhez egyetlen virtuális hálózatból?

A Windows PowerShell és az Azure REST API-k használatával kapcsolódhat több helyhez is. Lásd a többhelyes és a virtuális hálózatok közötti kapcsolattal kapcsolatos gyakori kérdések szakaszt .

Van-e további költség a VPN-átjáró aktív-aktívként való beállításához?

Nem A további nyilvános IP-címek költségei azonban ennek megfelelően kerülnek felszámításra. Lásd az IP-címek díjszabását.

Milyen lehetőségeim vannak a létesítmények közötti kapcsolódásra?

Az Azure VPN Gateway a következő helyek közötti átjárókapcsolatokat támogatja:

További információ a VPN Gateway-kapcsolatokról: Mi az Az Azure VPN Gateway?

Mi a különbség a helyek közötti és a pont–hely kapcsolatok között?

  • A helyek közötti (IPsec/IKE VPN-alagút) konfigurációk a helyszíni hely és az Azure között vannak. A helyszínen levő bármely számítógépéről csatlakozhat bármely virtuális géphez vagy szerepkörpéldányhoz a virtuális hálózatán belül, attól függően, hogyan konfigurálja az útválasztást és az engedélyeket. Kiváló lehetőség a mindig elérhető helyszíni kapcsolatokhoz, és kiválóan alkalmas hibrid konfigurációkhoz.

    Ez a kapcsolattípus egy IPsec VPN-berendezésre (hardvereszközre vagy puha berendezésre) támaszkodik. A berendezést a hálózat szélén kell üzembe helyezni. Az ilyen típusú kapcsolat létrehozásához külső IPv4-címmel kell rendelkeznie.

  • A pont–hely (VPN SSTP-n keresztüli) konfigurációk lehetővé teszik, hogy bárhonnan egyetlen számítógépről csatlakozzon a virtuális hálózaton található bármihez. A Windows beépített VPN-ügyfelet használja.

    A pont–hely konfiguráció részeként egy tanúsítványt és egy VPN-ügyfélkonfigurációs csomagot telepít. A csomag tartalmazza azokat a beállításokat, amelyek lehetővé teszik a számítógép számára, hogy a virtuális hálózaton belül bármely virtuális géphez vagy szerepkörpéldányhoz csatlakozzon.

    Ez a konfiguráció akkor hasznos, ha virtuális hálózathoz szeretne csatlakozni, de nem a helyszínen található. Akkor is jó megoldás, ha nincs hozzáférése VPN-hardverhez vagy egy külső IPv4-címhez, amelyek mind a helyek közötti kapcsolathoz szükségesek.

A virtuális hálózatot úgy konfigurálhatja, hogy egyszerre használja a helyek közötti és a pont–hely kapcsolatot is, ha a helyek közötti kapcsolatot útvonalalapú VPN-típus használatával hozza létre az átjáróhoz. Az útvonalalapú VPN-típusokat dinamikus átjáróknak nevezzük a klasszikus üzemi modellben.

Az egyéni DNS helytelen konfigurálása megszakítja a VPN-átjáró normál működését?

A normál működés érdekében a VPN-átjárónak biztonságos kapcsolatot kell létesítenie az Azure vezérlősíkjával, amely nyilvános IP-címeken keresztül érhető el. Ez a kapcsolat a kommunikációs végpontok nyilvános URL-címeken keresztüli feloldására támaszkodik. Az Azure-beli virtuális hálózatok alapértelmezés szerint a beépített Azure DNS-szolgáltatást (168.63.129.16) használják a nyilvános URL-címek feloldásához. Ez az alapértelmezett viselkedés segít zökkenőmentes kommunikációt biztosítani a VPN-átjáró és az Azure-vezérlősík között.

Amikor egyéni DNS-t implementál egy virtuális hálózaton belül, elengedhetetlen az Azure DNS-re (168.63.129.16) hivatkozó DNS-továbbító konfigurálása. Ez a konfiguráció segít fenntartani a VPN-átjáró és a vezérlősík közötti folyamatos kommunikációt. Ha nem állít be DNS-továbbítót az Azure DNS-be, az megakadályozhatja, hogy a Microsoft műveleteket és karbantartásokat végezzen a VPN-átjárón, ami biztonsági kockázatot jelent.

A VPN-átjáró megfelelő működésének és kifogástalan állapotának biztosításához fontolja meg a következő DNS-konfigurációk egyikét a virtuális hálózaton:

  • Térjen vissza az Alapértelmezett Azure DNS-hez az egyéni DNS eltávolításával a virtuális hálózat beállításai között (ajánlott konfiguráció).
  • Adjon hozzá az egyéni DNS-konfigurációhoz egy Olyan DNS-továbbítót, amely az Azure DNS-re mutat (168.63.129.16). Az egyéni DNS adott szabályaitól és jellegétől függően előfordulhat, hogy ez a beállítás nem a várt módon oldja meg a problémát.

Amikor konfigurálja az Azure DNS Private Resolver továbbítási szabályát azon a virtuális hálózaton, amelyen a VPN Gateway telepítve van, ha helyettesítő karaktert tartalmaz a DNS-továbbítási szabálykészletben, győződjön meg arról, hogy a továbbítási cél IP-címe a beépített Azure DNS-szolgáltatásra (168.63.129.16) mutat a nyilvános URL-címek feloldásához.

Befolyásolhatja-e egy virtuális hálózathoz kapcsolt privát DNS zóna az Azure VPN átjáró működését?

Igen. Az Azure VPN Gateway bizonyos szolgáltatási műveletekhez hozzáférést igényel az Azure Blob Storage végpontjaihoz. Ha a privatelink.blob.core.windows.net privát DNS-zónát az átjáró virtuális hálózatához társítja, a rendszer a Blob Storage-hoz tartozó DNS-lekérdezéseket az adott zóna alapján értékeli ki. Ha a szükséges tárolófióknak nincs privát végpontja vagy hozzá tartozó privát DNS rekordja a zónában, a lekérdezés visszaadja az NXDOMAIN-t a tárolófiók nyilvános végpontja helyett. Ennek eredményeként a VPN átjáró nem tudja elérni a szükséges Blob Storage végpontot, ami befolyásolhatja a normál működését. A probléma elkerülése érdekében engedélyezd a(z) Azure saját DNS-zónák internetes tartalékútvonalát a(z) privatelink.blob.core.windows.net privát DNS-zóna virtuálishálózat-hivatkozásán. Amikor az NxDomainRedirect felbontási szabályzat engedélyezve van egy virtuális hálózati kapcsolaton, az Azure rekurzív resolver újra megpróbálja a lekérdezést. Ez lehetővé teszi, hogy a VPN átjáró feloldja és elérje a szükséges nyilvános Blob Storage végpontot, ha nincs privát DNS rekord a privát DNS zónában.

Kommunikálhat két VPN-ügyfél pont–hely kapcsolaton belül ugyanahhoz a VPN-átjáróhoz?

Igen. Az ugyanahhoz a VPN-átjáróhoz pont–hely kapcsolattal rendelkező VPN-ügyfelek kommunikálhatnak egymással.

Ha két VPN-ügyfél csatlakozik ugyanahhoz a pont–hely VPN-átjáróhoz, az átjáró automatikusan átirányíthatja közöttük a forgalmat a címkészletből hozzárendelt IP-cím meghatározásával.

Hatással lehet a pont–hely VPN-kapcsolatokra az "alagútlátás" néven ismert potenciális biztonsági rés?

A Microsoft tud a VPN-beágyazást megkerülő hálózati technikáról szóló jelentésekről. Ez iparági szintű probléma. Hatással van minden olyan operációs rendszerre, amely az RFC-specifikációnak megfelelően implementál egy DHCP-ügyfelet, és támogatja a DHCP 121-es útvonalait, beleértve a Windowst is.

A kutatás szerint a mérséklési megoldások közé tartozik a VPN futtatása egy olyan virtuális gépen belül, amely egy virtualizált DHCP-kiszolgálótól szerez be IP-címet, hogy megakadályozza, hogy a helyi hálózat DHCP-kiszolgálója útvonalakat telepítsen. A biztonsági résről további információt az NIST nemzeti biztonságirés-adatbázisában talál.

Adatvédelem

A VPN szolgáltatás tárolja vagy dolgozza fel az ügyféladatokat?

Nem

Virtuális hálózati átjárók

A VPN Gateway virtuális hálózati átjáró?

A VPN-átjáró a virtuális hálózati átjárók egyik típusa. A VPN Gateway titkosított adatforgalmat továbbít nyilvános kapcsolaton keresztül a virtuális hálózat és az Ön telephelye között. VPN Gateway használatával a virtuális hálózatok között is továbbíthat adatforgalmat. VPN-átjáró létrehozásakor az -GatewayType értéket Vpnhasználja. További információ: Tudnivalók a VPN Gateway konfigurációs beállításairól.

Miért nem tudok szabályzatalapú és útvonalalapú VPN-típusokat megadni?

2023. október 1-étől nem hozhat létre szabályzatalapú VPN-átjárót az Azure Portalon keresztül. Minden új VPN-átjáró automatikusan útvonalalapúként jön létre. Ha már rendelkezik szabályzatalapú átjáróval, nem kell az átjárót útvonalalapúra frissítenie. A szabályzatalapú átjárók létrehozásához használhatja az Azure PowerShellt vagy az Azure CLI-t.

Korábban a régebbi átjárók termékszintjei (SKU-k) nem támogatták az IKEv1-et az útvonalalapú átjárók esetében. A jelenlegi átjáró-termékváltozatok többsége támogatja az IKEv1 és az IKEv2 szolgáltatást is.

Átjáró VPN-típusa Átjáró termékkód Támogatott IKE-verziók
Szabályzatalapú átjáró Alapszintű IKEv1
Útvonalalapú átjáró Alapszintű IKEv2
Útvonalalapú átjáró VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ IKEv1 és IKEv2

Frissíthetem a szabályzatalapú VPN-átjárómat útvonalalapúra?

Nem Az átjárótípus nem módosítható szabályzatalapúról útvonalalapúra, illetve útvonalalapúról szabályzatalapúra. Az átjáró típusának módosításához törölnie kell és újra létre kell hoznia az átjárót az alábbi lépésekkel. Ez a folyamat körülbelül 60 percet vesz igénybe. Az új átjáró létrehozásakor nem őrizheti meg az eredeti átjáró IP-címét.

  1. Törölje az átjáróhoz társított kapcsolatokat.

  2. Törölje az átjárót az alábbi cikkek egyikével:

  3. Hozzon létre egy új átjárót a kívánt átjárótípussal, majd végezze el a VPN-beállításokat. A lépésekért tekintse meg a helyek közötti oktatóanyagot.

Megadhatok saját szabályzatalapú forgalomválasztókat?

Igen, a trafficSelectorPolicies Azure PowerShell-paranccsal definiálhat forgalomválasztókat egy kapcsolat attribútumával. Ahhoz, hogy a megadott forgalomválasztó érvénybe lépjen, mindenképpen engedélyezze a szabályzatalapú forgalomválasztókat.

Az egyénileg konfigurált forgalomválasztók csak akkor javasoltak, ha egy VPN-átjáró kezdeményezi a kapcsolatot. A VPN-átjárók elfogadják a távoli átjáró (helyszíni VPN-eszköz) által javasolt forgalomválasztókat. Ez a viselkedés az összes kapcsolati mód (Defaultés InitiatorOnlyResponderOnly) között konzisztens.

Szükségem van átjáró-alhálózatra?

Igen. Az átjáróalhálózat tartalmazza a virtuális hálózati átjáró-szolgáltatások által használt IP-címeket. A virtuális hálózati átjáró konfigurálásához létre kell hoznia egy átjáróalhálózatot a virtuális hálózathoz.

A megfelelő működéshez minden átjáró-alhálózatot el kell nevezni GatewaySubnet . Ne nevezze el másként az átjáróalhálózatát. Ne helyezzen üzembe virtuális gépeket vagy bármi mást a gateway alhálózatra.

Az átjáróalhálózat létrehozásakor meg kell adnia, hogy hány IP-címet tartalmaz az alhálózat. Az átjáróalhálózatban lévő IP-címeket az átjárószolgáltatás számára foglalja le a rendszer.

Egyes konfigurációk a többinél nagyobb számú IP-cím kiosztását követelik meg az átjárószolgáltatásokhoz. Győződjön meg arról, hogy az átjáróalhálózat elegendő IP-címet tartalmaz a jövőbeli növekedéshez és a lehetséges új kapcsolatkonfigurációkhoz.

Bár akár /29-ben is létrehozhat átjáróalhálózatot, javasoljuk, hogy hozzon létre egy /27 vagy nagyobb átjáróalhálózatot (/27, /26, /25 stb.). Ellenőrizze, hogy a meglévő átjáróalhálózat megfelel-e a létrehozni kívánt konfiguráció követelményeinek.

Üzembe helyezhetek virtuális gépeket vagy szerepkörpéldányokat az átjáró alhálózatán?

Nem

Megszerezhetem a VPN-átjáróm IP-címét, mielőtt létrehozom az átjárót?

Az Azure Standard termékváltozat nyilvános IP-erőforrásainak statikus foglalási módszert kell használniuk. Megkapja a nyilvános IP-címet a VPN-átjáróhoz, amint létrehozza a Standard SKU nyilvános IP-erőforrást, amelyet használni szeretne.

Kérhetek statikus nyilvános IP-címet a VPN-átjárómhoz?

A standard termékváltozat nyilvános IP-címerőforrásai statikus kiosztási módszert használnak. Az új VPN-átjáró létrehozásakor a továbbiakban standard termékváltozatú nyilvános IP-címet kell használnia.

A korábban létrehozott nem zónaredundáns és nem zonális átjárók esetében (az olyan átjáró-termékváltozatok esetében, amelyek nevében nem szerepel az AZ ), a dinamikus IP-címhozzárendelés támogatott, de a kivezetés folyamatban van. Dinamikus IP-cím használatakor az IP-cím nem változik a VPN-átjáróhoz való hozzárendelés után. A VPN-átjáró IP-címe csak akkor változik, ha az átjárót törlik, majd újra létrehozták. A nyilvános IP-cím nem változik a VPN-átjáró frissítése (átméretezése), alaphelyzetbe állítása vagy egyéb belső karbantartása és frissítése során.

Hogyan befolyásolja az alapszintű termékváltozat nyilvános IP-címeinek kivonása a VPN-átjárókat?

Az alapszintű termékváltozat nyilvános IP-címeinek kivonása folyamatban van. A VPN-átjáró létrehozásakor a standard termékváltozat nyilvános IP-címét kell használnia.

Az alapszintű termékváltozat nyilvános IP-címeinek kivonásával kapcsolatos részleteket az Azure Updates közleményében találja.

Feljegyzés

Az Azure Basic nyilvános IP-címeket használó VPN Gateway ütemezése gyakran frissül. A legújabb migrálási ütemtervért tekintse meg a VPN Gateway Az új lapot.

Hogyan történik a VPN-alagút hitelesítése?

Az Azure VPN Gateway előre meghatározott kulcsú (PSK) hitelesítést használ. A VPN-alagút létrehozásakor létrehozunk egy PSK-t. Az automatikusan létrehozott PSK-t a Set Pre-Shared Key REST API-val vagy a PowerShell-parancsmaggal módosíthatja a sajátjára.

Használhatom az előre megosztott kulcsú REST API-t a szabályzatalapú (statikus útválasztási) átjáró VPN-jének konfigurálásához?

Igen. A Set Pre-Shared Key REST API és a PowerShell parancsmag használatával konfigurálhatja az Azure policy-alapú (statikus) VPN-eket és az útvonalalapú (dinamikus) útválasztási VPN-eket.

Használhatok más hitelesítési módszert?

A hitelesítéshez csak előre megosztott kulcsokat használhat.

Támogatja az Azure VPN Gateway az IPv6-ot?

Igen. További információért lásd: Létrehozni egy helyszínről helyszínre VPN kapcsolatot IPv4 és IPv6 dupla stack-ben , valamint About Point-to-Site VPN.

Hogyan határozhatom meg, milyen adatforgalom haladjon át a VPN-átjárón?

Az Azure Resource Manager telepítési modell esetében:

  • Azure PowerShell: A helyi hálózati átjáró forgalmának megadására használható AddressPrefix .
  • Azure Portal: Nyissa meg a helyi hálózati átjáró>konfigurációs>címterét.

A klasszikus üzembe helyezési modell esetén:

  • Azure Portal: Nyissa meg a klasszikus virtuális hálózatot, majd lépjen a VPN-kapcsolatok>helyek közötti VPN-kapcsolatok>helyi helynév>helyi hely>ügyfélcímtartományára.

Használhatom a NAT-T-t a VPN-kapcsolataimon?

Igen, a hálózati címfordítási áthidalás (NAT-T) támogatott. Az Azure VPN Gateway nem végez NAT-szerű funkciókat az IPsec-alagutakba vagy azokból érkező belső csomagokon. Ebben a konfigurációban győződjön meg arról, hogy a helyszíni eszköz kezdeményezi az IPSec-alagutat.

Üzembe helyezhetem a saját VPN-kiszolgálómat az Azure-ban, és csatlakozhatok vele a helyszíni hálózatomhoz?

Igen. Saját VPN-átjárókat vagy -kiszolgálókat helyezhet üzembe az Azure-ban az Azure Marketplace-en vagy saját VPN-útválasztók létrehozásával. Konfigurálnia kell a felhasználó által megadott útvonalakat a virtuális hálózatban, hogy a forgalom megfelelően legyen irányítva a helyszíni hálózatok és a virtuális hálózati alhálózatok között.

Miért vannak megnyitva bizonyos portok a virtuális hálózati átjárómon?

Ezek szükségesek az Azure-infrastruktúra-kommunikációhoz. Az Azure-tanúsítványok a zárolásukkal segítenek megvédeni őket. Megfelelő tanúsítványok nélkül a külső entitások, beleértve az átjárók ügyfeleit, nem okozhatnak semmilyen hatást ezekre a végpontokra.

A virtuális hálózati átjáró alapvetően többhomed eszköz. Egy hálózati adapter az ügyfél magánhálózatára koppint, egy hálózati adapter pedig a nyilvános hálózatra néz. Az Azure-infrastruktúra-entitások megfelelőségi okokból nem tudnak csatlakozni az ügyfél privát hálózataihoz, ezért nyilvános végpontokat kell használniuk az infrastruktúra-kommunikációhoz. Az Azure biztonsági auditja rendszeresen ellenőrzi a nyilvános végpontokat.

Hol találhatok információt az átjárótípusokról, a követelményekről és az átviteli sebességről?

Tekintse meg az alábbi cikkeket:

Az IP-csomagok töredezettségének támogatása lehetséges a helyek közötti VPN-alagutakban?

Nem Az IP-töredezettség nem támogatott az ESP-csomagok és a helyközi VPN-alagútba ágyazott bármely csomag számára.

Gyökértanúsítvány migrálása pont–hely közötti VPN-átjárókhoz

Az Azure-ban időnként szükség van a pont–hely (P2S) kapcsolatokhoz használt VPN-átjárók gyökértanúsítványának migrálására. Tanúsítványmigrálás esetén a VPN-rendszergazdáknak le kell tölteniük egy frissített VPN-ügyfélprofilt, és újra kell terjeszteniük az összes P2S-felhasználónak. Annak megállapításához, hogy érinti-e Önt a változás, valamint az ügyfélprofilok frissítésére vonatkozó utasításokért tekintse meg az Az átjárótanúsítvány migrálása című cikket.

A régebbi termékváltozatok elavulása

A standard és a nagy teljesítményű termékváltozatok kivonásra kerülnek. A bejelentést az Azure Updates webhelyén tekintheti meg. További információkért tekintse meg a VPN Gateway örökölt termékváltozatainak cikkét.

Az ütemtervekről az VPN Gateway Az új oldalon talál további információt.

Létrehozhatok egy új átjárót, amely standard vagy nagy teljesítményű termékváltozatot használ az elavulás után?

Nem

Mennyi ideig lesznek támogatottak a meglévő átjárók a Standard és Nagy Teljesítményű SKU-kon?

Az ügyfél kezdeményezte a migrálást, valamint az átjárókat a kivonási dátumig támogatjuk.

Megváltozik az IP-címem az örökölt VPN-átjáró termékváltozatának migrálásakor?

Nem, az IP-cím nem változik, amikor migrál az Azure Portal használatával. Dönthet úgy, hogy egy alapszintű termékváltozat IP-címét egy standard termékváltozat IP-címére migrálja. További információ: Az alapszintű termékváltozat nyilvános IP-címének migrálása a VPN Gateway standard termékváltozatára.

Most át kell migrálnom az átjárókat a Standard vagy a Nagy teljesítményű termékváltozatból?

Ha meg szeretné őrizni az IP-címet, migrálnia kell az átjáró alapszintű IP-címét az Azure Portal használatával. A migrálás részeként az átjárók automatikusan át lesznek migrálva a rendelkezésre állási zónák által támogatott átjáró-termékváltozatokra.

Lesz-e díjszabási különbség az átjárók esetében a migrálás után?

A termékváltozatok automatikus migrálása és frissítése a rendelkezésre állási zónák által támogatott termékváltozatokra az alapszintű IP-címmigrálás részeként történik. További részletekért tekintse meg a VPN Gateway díjszabását .

Befolyásolja-e a migrálás a teljesítményt az átjárókon?

Igen. Jobb teljesítményt érhet el a VpnGw1AZ és a VpnGw2AZ termékváltozatokkal. Az SKU átviteli sebességével kapcsolatos további információkért lásd az átjáró termékváltozatairól szóló témakört.

Mi történik, ha nem migrálok a nyugdíjba vonulási dátum szerint?

A zökkenőmentes átmenet érdekében határozottan javasoljuk, hogy az ügyfelek az alapszintű IP-migrálási eszközzel migrálják az alapszintű IP-címeiket és a társított átjárókat. 2026. június után megpróbáljuk automatikusan migrálni az összes olyan átjárót, amely továbbra is a Standard vagy a Nagy teljesítményű termékváltozatot használja:

  • A Standard SKU átjárók automatikusan VpnGw1AZ-re frissülnek.
  • A High Performance SKU átjárói automatikusan VpnGw2AZ-re frissülnek.

Ha olyan korlátozásokba ütközünk, mint például az alhálózat elégtelen mérete, az automatikus átjárómigrálás nem hajtható végre. Ebben az esetben meg kell tennie a szükséges lépéseket a probléma megoldásához. Folytathatja az átjáró migrálását az Azure Portal használatával, amíg el nem érhető a háttérbeli migrálási támogatás.

A VPN Gateway alapszintű termékváltozata is nyugdíjba vonul?

Nem, a VPN Gateway alapszintű termékváltozata nem nyugdíjba vonul. VPN-átjárót az Alapszintű termékváltozat használatával hozhat létre az Azure PowerShell vagy az Azure CLI használatával. A VPN Gateway alapszintű termékváltozata jelenleg csak az alapszintű termékváltozat nyilvános IP-címerőforrását támogatja.

Alapszintű termékváltozat nyilvános IP-címének migrálása standard termékváltozatba

Azon VPN Gateway-telepítések esetében, amelyek jelenleg Basic SKU-jú nyilvános IP-címet használnak, a Basic SKU-jú nyilvános IP-címről Standard SKU-jú nyilvános IP-címre történő migrálással kapcsolatos információkért lásd: Tudnivalók a Basic SKU-jú nyilvános IP-cím migrálásáról. Az ütemterveket a VPN Gateway Az új lapon tekintheti meg.

Helyek közötti kapcsolatok és VPN-eszközök

Mit érdemes figyelembe venni a VPN-eszköz kiválasztásakor?

Szabványos helyek közötti VPN-eszközöket ellenőriztünk az eszközgyártókkal együttműködve. Az ismert kompatibilis VPN-eszközök listáját, azok konfigurációs utasításait vagy mintáit, valamint az eszköz specifikációit a VPN-eszközökkel kapcsolatos cikkben találja.

Az ismertként kompatibilisként felsorolt eszközcsaládok összes eszközének működnie kell a virtuális hálózatokkal. A VPN-eszköz konfigurálásához tekintse meg a megfelelő eszközcsaládnak megfelelő eszközkonfigurációs mintát vagy hivatkozást.

Hol találom a VPN-eszközök konfigurációs beállításait?

A vpn-eszköztől függően előfordulhat, hogy letölthet egy VPN-eszközkonfigurációs szkriptet. További információ: VPN-eszközkonfigurációs szkriptek letöltése.

Az alábbi hivatkozások további konfigurációs információkat tartalmaznak:

Hogyan szerkeszthetem a VPN-eszközök konfigurációs mintáit?

Lásd: Eszközkonfigurációs minták szerkesztése.

Hol találom az IPsec/IKE-paramétereket?

Lásd : Alapértelmezett IPsec/IKE-paraméterek.

Miért áll le a házirend-alapú VPN-alagutam, amikor nincs adatforgalom?

Ez a viselkedés szabályzatalapú ( más néven statikus útválasztási) VPN-átjárók esetében várható. Ha az alagúton keresztüli forgalom több mint öt percig tétlen, az alagút le lesz bontva. Amikor a forgalom mindkét irányban elindul, az alagút azonnal újra létre lesz hozva.

Csatlakozhatok az Azure-hoz szoftveres VPN-nel?

Támogatjuk a Windows Server 2012 útválasztási és távelérési kiszolgálóit a telephelyek közötti konfigurációhoz.

Más szoftveres VPN-megoldásoknak az átjáróval kell működniük, amennyiben megfelelnek az iparági szabványnak megfelelő IPsec-implementációknak. A konfigurációs és támogatási utasításokért forduljon a szoftver gyártójához.

Csatlakozhatok EGY VPN-átjáróhoz pont–hely kapcsolaton keresztül, ha aktív hely–hely kapcsolattal rendelkező helyen található?

Igen, de a pont–hely ügyfél nyilvános IP-címeinek különbözniük kell a helyek közötti VPN-eszköz által használt nyilvános IP-címektől, különben a pont–hely kapcsolat nem fog működni. Az IKEv2-vel nem kezdeményezhetők pont–hely kapcsolatok ugyanazon nyilvános IP-címekről, ahol a helyek közötti VPN-kapcsolat ugyanazon a VPN-átjárón van konfigurálva.

Hogyan kezeli az Azure VPN Gateway a forgalmat Active-Active módban, és mit érdemes figyelembe venni, ha a helyszíni beállításom szimmetrikus útválasztást igényel?

Az Azure VPN Gateway Active-Active módban minden átjárópéldány saját nyilvános IP-címével és alagútjával rendelkezik, és az Azure bármelyik alagúton keresztül küldhet forgalmat. Egy adott TCP/UDP-folyamat esetében az Azure ugyanazt az alagutat próbálja meg használni egy irányban, de nincs garancia arra, hogy a visszaadott forgalom ugyanazt az útvonalat követi. Ez azt jelenti, hogy a folyamatok lehetnek aszimmetrikusak, amelyeket az Azure natív módon kezel, de ha a helyszíni tűzfal vagy VPN-eszköz szigorú szimmetriát igényel, módosítania kell az útválasztási szabályzatokat (például BGP-attribútumokkal vagy forgalomválasztókkal), vagy inkább Active-Standby módot kell figyelembe vennie.

Az Azure garantálja az adott folyamat szimmetrikus útválasztását Active-Active VPN módban?

Nem, az Azure nem garantálja az adott folyamat szimmetrikus útválasztását Active-Active VPN módban.

  • A Active-Active VPN Gateway két átjárópéldánysal (Gateway0 és Gateway1) rendelkezik, mindegyik saját nyilvános IP-címmel.
  • A helyszíni VPN-eszközök általában két alagutat hoznak létre (átjárópéldányonként egyet).
  • Az Azure BGP-hirdetései mindkét alagutat elérhetővé teszik útválasztáshoz.
  • A helyszíni útválasztási szabályzattól és az Azure útvonalválasztásától függően a csomagok az egyik alagútból ki- és a másikba léphetnek.

Pont-hely típusú kapcsolatok

Hány VPN-ügyfélvégponttal rendelkezhetek a pont–hely konfigurációban?

Ez a hálózati átjáró termékváltozatától függ. A támogatott kapcsolatok számával kapcsolatos további információkért lásd az átjáró termékváltozatait.

Milyen ügyfél operációs rendszereket használhatok pont–hely kapcsolattal?

A következő ügyféloldali operációs rendszerek támogatottak:

  • Windows 11
  • macOS 13.0 vagy újabb verzió
  • Linux (strongSwan)
  • iOS

Át tudok haladni a proxykon és tűzfalakon pont–hely képesség használatával?

Azure-támogatás háromféle pont–hely VPN-lehetőséget kínál:

  • Secure Socket Tunneling Protocol (SSTP): A Microsoft által védett SSL-alapú megoldás, amely képes áthatolni a tűzfalakon, mert a legtöbb tűzfal megnyitja a 443 SSL által használt kimenő TCP-portot.

  • OpenVPN: SSL-alapú megoldás, amely képes behatolni a tűzfalakba, mert a legtöbb tűzfal megnyitja a 443 SSL által használt kimenő TCP-portot.

  • IKEv2 VPN: Szabványalapú IPsec VPN-megoldás, amely az 500-es és a 4500-es kimenő UDP-portot használja az 50-es IP-protokollszámmal együtt. A tűzfalak nem mindig nyitják meg ezeket a portokat, így előfordulhat, hogy az IKEv2 VPN nem tud proxykat és tűzfalakat átszűnni.

Ha újraindítok egy pont–hely típusú ügyfélszámítógépet, a VPN automatikusan újracsatlakozik?

Az automatikus újracsatlakozás a használt ügyfél függvénye. A Windows az Always On VPN-ügyfélfunkcióval támogatja az automatikus újracsatlakozást.

Támogatja a pont–hely közötti DDNS-t a VPN-ügyfeleken?

A dinamikus DNS (DDNS) jelenleg nem támogatott pont–hely VPN-ekben.

Létezhetnek helyek közötti és pont–hely konfigurációk ugyanazon a virtuális hálózaton?

Igen. A Resource Manager-alapú telepítési modellhez szüksége van egy útvonalalapú VPN-típusra az átjárójához. A klasszikus telepítési modellhez dinamikus átjáróra van szükség. Nem támogatjuk a pont–hely beállítást statikus útválasztású VPN-átjárókhoz vagy szabályzatalapú VPN-átjárókhoz.

Konfigurálhatok egy pont–hely típusú ügyfelet úgy, hogy egyszerre több virtuális hálózati átjáróhoz csatlakozzanak?

A használt VPN-ügyfélszoftvertől függően előfordulhat, hogy több virtuális hálózati átjáróhoz is csatlakozhat. Ez azonban csak akkor van így, ha a virtuális hálózatok, amelyekhez csatlakozik, nem ütköznek egymásnak a címterek között, vagy azzal a hálózattal, amelyből az ügyfél csatlakozik. Bár az Azure VPN-ügyfél számos VPN-kapcsolatot támogat, bármikor csak egy kapcsolattal rendelkezhet.

Konfigurálhatok pont–hely típusú ügyfelet úgy, hogy egyszerre több virtuális hálózathoz csatlakozzanak?

Igen. A más virtuális hálózatokkal társviszonyban lévő virtuális hálózaton üzembe helyezett VPN-átjáró pont–hely típusú ügyfélkapcsolatai hozzáférhetnek a többi társhálózathoz, feltéve, hogy megfelelnek bizonyos konfigurációs feltételeknek. Ahhoz, hogy egy pont–hely ügyfél hozzáférhessen egy társhálózathoz, a társhálózatot (az átjáró nélküli virtuális hálózatot) a Távoli átjárók használata attribútummal kell konfigurálni. A VPN-átjáróval rendelkező virtuális hálózatot az átjáró átvitelének engedélyezése beállítással kell konfigurálni. További információ: Tudnivalók a pont–hely VPN-útválasztásról.

Mennyi átviteli sebességre számíthatok helyek közötti vagy pont–hely kapcsolatokon keresztül?

Nehéz pontosan fenntartani a VPN-alagutak adatátviteli sebességét. Az IPsec és az SSTP erős titkosítást használó VPN-protokoll. A helyek és az internet közötti késés és sávszélesség is korlátozhatja az átviteli sebességet.

A csak IKEv2 pont–hely VPN-kapcsolatokkal rendelkező VPN-átjárók esetében az elvárható teljes átviteli sebesség az átjáró termékváltozatától függ. Az átviteli sebességről további információt az Átjáró termékváltozatai című témakörben talál.

Használhatok olyan szoftveres VPN-ügyfelet, amely támogatja az SSTP-t vagy az IKEv2-t?

Nem Csak a natív VPN-ügyfelet használhatja a Windows for SSTP-n, a Macen pedig az IKEv2-hez készült natív VPN-ügyfelet. Az OpenVPN-ügyfelet azonban minden platformon használhatja az OpenVPN protokollon keresztüli csatlakozáshoz. Tekintse meg a támogatott ügyfél operációs rendszerek listáját.

Módosíthatom a pont–hely kapcsolat hitelesítési típusát?

Igen. A portálon lépjen a VPN-átjáró>pont–hely konfigurációjához. Hitelesítési típus esetén válassza ki a használni kívánt hitelesítési típust.

A hitelesítési típus módosítása után előfordulhat, hogy az aktuális ügyfelek nem tudnak csatlakozni, amíg új VPN-ügyfélkonfigurációs profilt nem hoz létre, letölti és alkalmazza az egyes VPN-ügyfelekre.

Mikor kell létrehoznom egy új konfigurációs csomagot a VPN-ügyfélprofilhoz?

Amikor módosítja a P2S VPN-átjáró konfigurációs beállításait, például alagúttípust ad hozzá vagy módosít egy hitelesítési típust, létre kell hoznia egy új konfigurációs csomagot a VPN-ügyfélprofilhoz. Az új csomag tartalmazza azokat a frissített beállításokat, amelyekre a VPN-ügyfeleknek szükségük van a P2S-átjáróhoz való csatlakozáshoz. A csomag létrehozása után a fájlok beállításaival frissítse a VPN-ügyfeleket.

Támogatja az Azure az IKEv2 VPN használatát Windows rendszeren?

Az IKEv2 támogatott Windows 10 és Windows Server 2016 rendszeren. Az IKEv2 egyes operációsrendszer-verziókban való használatához azonban telepítenie kell a frissítéseket, és helyileg be kell állítania egy beállításkulcs-értéket. A Windows 10-nél korábbi operációsrendszer-verziók nem támogatottak, és csak az SSTP-t vagy az OpenVPN protokollt használhatják.

Feljegyzés

A Windows operációs rendszer a Windows 10 1709-es és a Windows Server 2016 1607-es verziójánál újabb buildeket készít, ezek a lépések nem szükségesek.

Feljegyzés

A Microsoft azt javasolja, hogy a Windows 11-et Point-to-Site VPN kapcsolatokkal használjuk. A Windows 10 2025 októberében ért véget a támogatásnak. További információért lásd: Támogatott Windows verziók az Azure VPN Klienshez.

A Windows 10 vagy a Windows Server 2016 előkészítése az IKEv2-hez:

  1. Telepítse a frissítést az operációs rendszer verziója alapján:

    Operációs rendszer verziója Dátum Szám/hivatkozás
    Windows Server 2016
    Windows 10, 1607-es verzió    		 2018. január 17. KB4057142
    Windows 10, 1703-as verzió 2018. január 17. KB4057144
    Windows 10, 1709-es verzió 2018. március 22. KB4089848

  2. Adja meg a beállításkulcs értékét. Hozza létre vagy állítsa be a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayloadREG_DWORD kulcsot a beállításjegyzékben 1.

Mi az IKEv2 forgalomválasztó korlátja a pont–hely kapcsolatok esetében?

A Windows 10 2004-es (2021. szeptemberi kiadású) verziója 255-re növelte a forgalomválasztó korlátját. A Windows korábbi verzióiban a forgalomválasztó korlátja 25.

A Windows forgalomválasztó korlátja határozza meg a virtuális hálózat címtereinek maximális számát, valamint a helyi hálózatok, a virtuális hálózatok közötti kapcsolatok és az átjáróhoz csatlakoztatott társhálózatok maximális összegét. A Windows-alapú pont–hely ügyfelek nem tudnak csatlakozni az IKEv2-en keresztül, ha túllépik ezt a korlátot.

Mi az OpenVPN forgalomválasztó korlátja a pont–hely kapcsolatokhoz?

Az OpenVPN forgalomválasztó korlátja 1000 útvonal.

Mi történik, ha az SSTP-t és az IKEv2-t is konfigurálom a P2S VPN-kapcsolatokhoz?

Ha az SSTP-t és az IKEv2-t is windowsos és Mac rendszerű eszközökből álló vegyes környezetben konfigurálja, a Windows VPN-ügyfél mindig először az IKEv2-alagutat próbálja meg. Ha az IKEv2 kapcsolat nem sikerül, az ügyfél visszaesik az SSTP-be. a macOS csak az IKEv2-en keresztül csatlakozik.

Ha az átjárón engedélyezve van az SSTP és az IKEv2 is, a pont–hely címkészlet statikusan fel van osztva a kettő között, így a különböző protokollokat használó ügyfelek mindkét alhálózat IP-címei. Az SSTP-ügyfelek maximális száma mindig 128, még akkor is, ha a címtartomány nagyobb, mint /24. Az eredmény az IKEv2-ügyfelek számára elérhető címek nagyobb száma. Kisebb tartományok esetén a készlet egyenlően felére csökken. Előfordulhat, hogy az átjáró által használt forgalomválasztók nem tartalmazzák a pont–hely címtartomány osztály nélküli tartományközi útválasztási (CIDR) blokkját, hanem a két altartomány CIDR-blokkját.

Az Azure mely platformokat támogatja a P2S VPN-hez?

Azure-támogatás a Windows, Mac és Linux for P2S VPN-hez.

Már üzembe helyeztem egy VPN-átjárót. Engedélyezhetem rajta a RADIUS-t vagy az IKEv2 VPN-t?

Igen. Ha a használt átjáró termékváltozata támogatja a RADIUS-t vagy az IKEv2-t, engedélyezheti ezeket a funkciókat az Azure PowerShell vagy az Azure Portal használatával már üzembe helyezett átjárókon. Az alapszintű termékváltozat nem támogatja a RADIUS-t vagy az IKEv2-t.

Miért kapcsolódik le az Azure VPN kliens? Mit tehetek a leválasztás gyakoriságának csökkentése érdekében?

A következő üzenetek egyikét láthatja:

  • A Windowshoz készült Azure VPN-ügyfél 3.4.0.0-s verziójában: "A Microsoft Entra-hitelesítés lejárt." Új jogkivonat beszerzéséhez újra be kell jelentkeznie az Entra-ba. A hitelesítés időkorlátját a rendszergazda beállíthatja.
  • Az Azure VPN-ügyfél macOS ver. 2.7.101-ben: "A Microsoft Entra-hitelesítése lejárt, ezért újra kell hitelesítenie, hogy új tokent szerezzen. Próbálkozzon újra a csatlakozással. A hitelesítési házirendeket és az időtúllépési beállításokat az Ön rendszergazdája konfigurálja az Entra-bérlőben.

A pont–hely kapcsolat megszakad, mert az Azure VPN-ügyfél aktuális frissítési jogkivonata, amelyet az Entra-azonosítóból szereztek be, lejárt vagy érvénytelenné vált. Ez az azonosító körülbelül minden órában megújul. Az Entra-bérlő rendszergazdái feltételes hozzáférési szabályzatok hozzáadásával bővíthetik a bejelentkezési gyakoriságot. A megújítási token lejárati időközének meghosszabbításához működjön együtt az Entra bérlő rendszergazdáival.

További információ: VPN-ügyfél hibája: A Microsoft Entra-hitelesítés lejárt.

Hogyan távolíthatom el egy pont–hely kapcsolat konfigurációját?

A P2S-konfigurációt az alábbi Azure PowerShell- vagy Azure CLI-parancsokkal távolíthatja el:

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

Pont–hely kapcsolatok tanúsítványhitelesítéssel

Milyen tanúsítványtípusokat támogat az Azure VPN Gateway a Point-to-Site (P2S) tanúsítványhitelesítéshez?

Azure VPN Gateway támogatja RSA alapú X.509 tanúsítványokat a Point-to-Site (P2S) tanúsítványhitelesítéshez. Jelenleg nem támogatja az ECC/ECDSA tanúsítványokat IKEv2-alapú P2S hitelesítéshez.

Mit tegyek, ha pont-helyi tanúsítványhitelesítési kapcsolathoz tanúsítványeltérést kapok?

Törölje a Tanúsítvány érvényesítésével történő kiszolgálóidentitás-ellenőrzés jelölőnégyzet választását. Vagy adja hozzá a kiszolgáló teljes tartománynevét (FQDN) a tanúsítványsal együtt, amikor manuálisan hoz létre profilt. Ehhez futtassa rasphone a parancssorból, és válassza ki a profilt a legördülő listából.

Általában nem javasoljuk a kiszolgálóidentitás ellenőrzésének megkerülését. Az Azure-tanúsítványhitelesítéssel azonban ugyanezt a tanúsítványt használják a vpn-bújtatási protokoll (IKEv2 vagy SSTP) és az Extensible Authentication Protocol (EAP) kiszolgálói érvényesítéséhez. Mivel a VPN-bújtatási protokoll már érvényesíti a kiszolgálótanúsítványt és az FQDN-t, redundáns újra ellenőrizni őket az EAP-ban.

Képernyőkép a pont–hely hitelesítés tulajdonságairól.

Használhatom a saját belső PKI legfelső szintű hitelesítésszolgáltatómat a pont–hely kapcsolat tanúsítványainak létrehozásához?

Igen. Korábban csak önaláírt gyökértanúsítványokat használhatott. Továbbra is 20 gyökértanúsítvány tölthető fel.

Használhatok tanúsítványokat az Azure Key Vaultból?

Nem

Milyen eszközökkel hozhatok létre tanúsítványokat?

Használhatja a vállalati nyilvános kulcsú infrastruktúra (PKI) megoldását (a belső PKI-t), az Azure PowerShellt, a MakeCertet és az OpenSSL-t.

Elérhető útmutató a tanúsítvány beállításaihoz és paramétereihez?

A .cer és a .pfx fájlformátumokért lásd:

A .pem fájlformátumot lásd:

Pont–hely kapcsolatok RADIUS-hitelesítéssel

Minden Azure VPN Gateway termékváltozaton támogatott a RADIUS-hitelesítés?

A RADIUS-hitelesítés az alapszintű termékváltozat kivételével minden termékváltozat esetében támogatott.

A korábbi termékváltozatok esetében a RADIUS-hitelesítés standard és nagy teljesítményű termékváltozatokon támogatott.

A klasszikus üzemi modell támogatja a RADIUS-hitelesítést?

Nem

Mi a RADIUS-kiszolgálónak küldött RADIUS-kérelmek időtúllépési ideje?

A RADIUS-kérelmek időtúllépése 30 másodperc elteltével van beállítva. A felhasználó által megadott időtúllépési értékek jelenleg nem támogatottak.

Támogatottak a külső RADIUS-kiszolgálók?

Igen.

Milyen kapcsolati követelmények szükségesek ahhoz, hogy az Azure Gateway elérhessen egy helyszíni RADIUS-kiszolgálót?

Szüksége van egy helyek közötti VPN-kapcsolatra a helyszíni telephelyhez, ahol a megfelelő útvonalak vannak konfigurálva.

Irányítható a helyszíni RADIUS-kiszolgálóra (a VPN-átjáróról) érkező forgalom expressRoute-kapcsolaton keresztül?

Nem Csak helyek közötti kapcsolaton keresztül irányítható.

Változik a RADIUS-hitelesítéssel támogatott SSTP-kapcsolatok száma? Mi a támogatott SSTP- és IKEv2-kapcsolatok maximális száma?

A RADIUS-hitelesítéssel rendelkező átjárókon nem változik a támogatott SSTP-kapcsolatok maximális száma. Az SSTP esetében továbbra is 128, de az IKEv2 átjáró termékváltozatától függ. A támogatott kapcsolatok számáról további információt az átjáró termékváltozatairól szóló cikkben talál.

Mi a különbség a RADIUS-kiszolgálón keresztüli tanúsítványhitelesítés és az Azure natív tanúsítványhitelesítése között egy megbízható tanúsítvány feltöltésével?

A RADIUS-tanúsítványhitelesítés során a hitelesítési kérés egy RADIUS-kiszolgálóra továbbítja, amely a tanúsítványérvényesítést kezeli. Ez a lehetőség egy olyan tanúsítványhitelesítő infrastruktúrával való integrációkor hasznos, amellyel a RADIUS révén már rendelkezik.

Amikor az Azure-t használja a tanúsítványhitelesítéshez, a VPN-átjáró elvégzi a tanúsítvány érvényesítését. Ehhez fel kell tölteni az átjáróra a tanúsítvány nyilvános kulcsát. Megadhatja azoknak a visszavont tanúsítványoknak a listáját is, amelyeket nem szabad engedélyezni a csatlakozáshoz.

Támogatja a RADIUS-hitelesítés a hálózati házirend-kiszolgáló integrációját a többtényezős hitelesítéshez?

Ha a többtényezős hitelesítés szövegalapú (például SMS vagy mobilalkalmazás-ellenőrző kód), és megköveteli a felhasználótól, hogy írjon be egy kódot vagy szöveget a VPN-ügyfél felhasználói felületén, a hitelesítés nem fog sikerülni, és nem támogatott forgatókönyv. A többtényezős hitelesítéshez tekintse meg az Azure VPN Gateway RADIUS-hitelesítésének integrálását az NPS-kiszolgálóval.

Működik a RADIUS-hitelesítés az IKEv2 és az SSTP VPN-vel is?

Igen, a RADIUS-hitelesítés az IKEv2 és az SSTP VPN esetében is támogatott.

Működik a RADIUS-hitelesítés az OpenVPN-ügyféllel?

Az OpenVPN protokoll támogatja a RADIUS-hitelesítést.

Virtuális hálózatok közötti és többhelyes kapcsolatok

Az ebben a szakaszban szereplő virtuális hálózatok közötti információk a VPN-átjárók kapcsolataira vonatkoznak. A virtuális hálózatok közötti társviszony-létesítéssel kapcsolatos információkért lásd: Virtuális hálózatok közötti társviszony-létesítés.

Számol fel díjat az Azure a virtuális hálózatok közötti forgalomért?

Az azonos régión belüli virtuális hálózatok közötti forgalom mindkét irányban ingyenes, ha VPN-átjárókapcsolatot használ. A régiók közötti virtuális hálózatok kimenő forgalmát a forrás régiók szerinti inter-VNet adatátviteli díjak alapján számítják fel. További információkért tekintse meg az Azure VPN Gateway díjszabását. Ha VPN-átjáró helyett VNet peering használatával csatlakoztatja a virtuális hálózatokat, tekintse meg az Azure Virtual Network díjszabását.

A VNet-ek közötti forgalom az interneten keresztül zajlik?

Nem A virtuális hálózatok közötti forgalom a Microsoft Azure gerinchálózatán halad át, nem az interneten.

Létrehozhatok VNet-VNet kapcsolatot a Microsoft Entra-bérlők között?

Igen. A VPN-átjárókat használó virtuális hálózatok közötti kapcsolatok a Microsoft Entra-bérlők között működnek.

Biztonságos-e a virtuális hálózatok közötti adatforgalom?

Az IPsec- és az IKE-titkosítás segít megvédeni a virtuális hálózatok közötti forgalmat.

Szükségem van VPN-eszközre a virtuális hálózatok egymáshoz kapcsolásához?

Nem Több Azure-beli virtuális hálózat összekapcsolásához nincs szükség VPN-eszközre, hacsak nincs szükség helyszíni kapcsolatokra.

A virtuális hálózataimnak ugyanabban a régióban kell lenniük?

Nem A virtuális hálózatok lehetnek azonos vagy eltérő Azure-régiókban (helyeken).

Ha a virtuális hálózatok nem ugyanabban az előfizetésben találhatók, az előfizetéseket ugyanahhoz a Microsoft Entra-bérlőhöz kell társítani?

Nem

Használhatom a VNet-to-VNet módszert, hogy összekapcsoljon különböző Azure-példányokban található virtuális hálózatokat?

Nem A VNet-to-VNet támogatja a virtuális hálózatok csatlakoztatását azonos Azure-példányon belül. Például nem hozhat létre kapcsolatot a globális Azure és a kínai, német vagy amerikai kormányzati Azure-példányok között. Érdemes lehet helyek közötti VPN-kapcsolatot használni ezekhez a forgatókönyvekhez.

Használhatom a VNet-to-VNet kapcsolatokat többhelyszínes kapcsolatokkal együtt?

Igen. A virtuális hálózati kapcsolatot egyszerre használhatja többhelyes VPN-ekkel.

Hány helyszíni helyhez és virtuális hálózathoz kapcsolódhat egyetlen virtuális hálózat?

Tekintse meg az átjáróra vonatkozó követelmények táblát.

Használhatom a VNet-to-VNet kapcsolatokat olyan virtuális gépekhez vagy felhőszolgáltatásokhoz, amelyek nincsenek virtuális hálózatban?

Nem A VNet-to-VNet támogatja a virtuális hálózatok összekapcsolását. Nem támogatja a virtuális hálózaton nem található virtuális gépek vagy felhőszolgáltatások csatlakoztatását.

A felhőszolgáltatás vagy a terheléselosztási végpont kiterjedhet a virtuális hálózatokra?

Nem A felhőszolgáltatás vagy a terheléselosztási végpontok nem terjedhetnek ki a virtuális hálózatokra, még akkor sem, ha össze vannak kapcsolva.

Használhatok szabályzatalapú VPN-típust virtuális hálózatok közötti vagy többhelyes kapcsolatokhoz?

Nem A VNet-to-VNet és többhelyes kapcsolatokhoz útvonalalapú (korábban dinamikus útválasztású) VPN-átjárók szükségesek.

Csatlakoztathatok egy útvonalalapú VPN-típussal rendelkező virtuális hálózatot egy szabályzatalapú VPN-típussal rendelkező másik virtuális hálózathoz?

Nem Mindkét virtuális hálózatnak útvonalalapú (korábban dinamikus útválasztási) VPN-eket kell használnia.

Megosztják-e a VPN-alagutak a sávszélességet?

Igen. A virtuális hálózat összes VPN-alagútja osztozik a VPN-átjárón elérhető sávszélességen, és ugyanazzal a szolgáltatásiszint-szerződéssel rendelkezik az Azure-beli VPN-átjárók üzemidejéhez.

Támogatottak a redundáns alagutak?

A virtuális hálózatok párjai közötti redundáns alagutak támogatottak, amikor az egyik virtuális hálózati átjáró aktív-aktívként van konfigurálva.

Átfedhetnek egymást a címterek VNet-to-VNet konfigurációkban?

Nem Nem lehetnek átfedő IP-címtartományok.

Lehetnek-e egymással átfedésben lévő címterek a csatlakoztatott virtuális hálózatok és helyszíni helyek között?

Nem Nem lehetnek átfedő IP-címtartományok.

Hogyan konfigurálhatok bérlők közötti forgatókönyvet?

Ha PowerShell-parancsokat használ, ellenőrizze, hogy az Az.Network 7.15.1-et futtatja-e

Hogyan engedélyezhetem az útválasztást a helyek közötti VPN-kapcsolat és az ExpressRoute között?

Ha engedélyezni szeretné az ExpressRoute-hoz csatlakoztatott ág és a helyek közötti VPN-hez csatlakoztatott ág közötti útválasztást, be kell állítania az Azure Route Servert.

Használhatok VPN-átjárót a helyszíni helyek vagy egy másik virtuális hálózat közötti forgalom átviteléhez?

  • Resource Manager-alapú üzemi modell

    Igen. További információért tekintse meg a BGP és az útválasztás szakaszt.

  • Klasszikus telepítési modell

    A vpn-átjárón keresztüli forgalom átvitele a klasszikus üzemi modell használata esetén lehetséges, de a hálózati konfigurációs fájl statikusan definiált címtereire támaszkodik. A Border Gateway Protocol (BGP) jelenleg nem támogatott az Azure-beli virtuális hálózatok és VPN-átjárók esetében a klasszikus üzemi modellen keresztül. BGP nélkül az átviteli címterek manuális definiálása hibalehetőséget jelent, és nem ajánlott.

Az Azure ugyanazt az IPsec/IKE előmegosztott kulcsot hozza létre az összes VPN-kapcsolatomhoz ugyanahhoz a virtuális hálózathoz?

Nem Alapértelmezés szerint az Azure különböző előre megosztott kulcsokat hoz létre a különböző VPN-kapcsolatokhoz. A VPN Gateway key REST API vagy a PowerShell parancsmag használatával azonban beállíthatja a kívánt kulcsértéket. A kulcsnak csak nyomtatható ASCII-karaktereket kell tartalmaznia, a szóköz, a kötőjel (-) és a tilde (~) kivételével.

Több sávszélességet kapok több helyek közötti VPN-sel, mint egyetlen virtuális hálózat esetén?

Nem Minden VPN-alagút, beleértve a pont–hely VPN-eket is, ugyanazt a VPN-átjárót és a rendelkezésre álló sávszélességet használja.

Konfigurálhatok több alagutat a virtuális hálózatom és a helyszíni helyem között többhelyes VPN használatával?

Igen, de mindkét alagúton ugyanarra a helyre kell konfigurálnia a BGP-t.

Az Azure VPN Gateway figyelembe veszi az AS útvonal elővételét, hogy befolyásolja a vállalati telephelyekhez fennálló több kapcsolat közötti útválasztási döntéseket?

Igen, az Azure VPN Gateway tiszteletben tartja az autonóm rendszer (AS) útvonal előkészítését, hogy segítsen az útválasztási döntések meghozatalában, amikor a BGP engedélyezve van. A BGP-útvonal kiválasztásakor a rövidebb AS útvonal előnyben részesül.

Használhatom a RoutingWeight tulajdonságot új VPN VirtualNetworkGateway-kapcsolat létrehozásakor?

Nem Ez a beállítás az ExpressRoute-átjárókapcsolatokhoz van fenntartva. Ha több kapcsolat közötti útválasztási döntéseket szeretne befolyásolni, használnia kell az AS útvonal előtagolását.

Használhatok pont–hely VPN-eket több VPN-alagutat tartalmazó virtuális hálózatommal?

Igen. Pont–hely VPN-eket használhat több helyszíni helyhez és más virtuális hálózatokhoz csatlakozó VPN-átjárókkal.

Csatlakoztathatok IPsec VPN-ekkel rendelkező virtuális hálózatot az ExpressRoute-kapcsolatcsoportomhoz?

Igen, ez támogatott. További információ: ExpressRoute konfigurálása és helyek közötti együttélő kapcsolatok.

IPsec/IKE-házirend

Támogatott egy egyéni IPsec/IKE-szabályzat az összes Azure VPN Gateway-termékváltozaton?

Az egyéni IPsec/IKE-szabályzatok az Alapszintű termékváltozat kivételével minden Azure VPN Gateway-termékváltozatban támogatottak.

Hány házirendeket adhatok meg egy kapcsolathoz?

Egy kapcsolathoz csak egy házirend kombinációt adhat meg.

Megadhatok részleges szabályzatot egy kapcsolaton (például csak IKE-algoritmusok, de nem IPsec)?

Nem, minden algoritmust és paramétert meg kell adnia mind az IKE (Elsődleges mód), mind az IPsec (Gyors mód) esetében. Részleges házirend-specifikáció nem engedélyezett.

Milyen algoritmusokat és kulcserősségeket támogat az egyéni szabályzat?

Az alábbi táblázat a konfigurálható támogatott titkosítási algoritmusokat és kulcserősségeket sorolja fel. Minden mezőhöz választania kell egy lehetőséget.

IPsec/IKEv2 Beállítások
IKEv2 titkosítás GCMAES256, GCMAES128, AES256, AES192, AES128
IKEv2 integritás SHA384, MD5, SHA1, SHA256
DH-csoport DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, Nincs
IPsec-titkosítás GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, Egyik sem
IPsec-integritás GCMAES256, GCMAES192, GCMAES128, SHA-256, SHA1, MD5
PFS-csoport PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, Nincs
Gyors mód SA élettartama (Nem kötelező; alapértelmezett értékek, ha nincs megadva)
Másodperc (egész szám; minimum 300, alapértelmezett 27 000)
Kilobájt (egész szám; minimum 1024, alapértelmezett 102 400 000)
Forgalomválasztó UsePolicyBasedTrafficSelectors ($True vagy $False, de nem kötelező; alapértelmezett $False , ha nincs megadva)
DPD időtúllépés Másodperc (egész szám; minimum 9, maximum 3600, alapértelmezett 45)

  • A helyszíni VPN-eszköz konfigurációjának meg kell egyeznie vagy tartalmaznia kell az Azure IPsec- vagy IKE-szabályzatban megadott alábbi algoritmusokat és paramétereket:

    • IKE titkosítási algoritmus (fő mód, 1. fázis)
    • IKE integritási algoritmus (fő mód, 1. fázis)
    • DH-csoport (fő mód, 1. fázis)
    • IPsec titkosítási algoritmus (gyors mód, 2. fázis)
    • IPsec-integritási algoritmus (gyors mód, 2. fázis)
    • PFS-csoport (gyors mód, 2. fázis)
    • Forgalomválasztó (ha használja UsePolicyBasedTrafficSelectors)
    • SA-élettartamok (olyan helyi specifikációk, amelyeknek nem kell egyeznie)

  • Ha GCMAES-t használ az IPsec titkosítási algoritmushoz, ugyanazt a GCMAES-algoritmust és kulcshosszt kell kiválasztania az IPsec-integritáshoz. Használjon például GCMAES128 mindkettőhöz.

  • Az algoritmusok és kulcsok táblázatában:

    • Az IKE a fő módnak vagy az 1. fázisnak felel meg.
    • Az IPsec a gyors módnak vagy a 2. fázisnak felel meg.
    • A DH-csoport a fő módban vagy az 1. fázisban használt Diffie-Hellman csoportot adja meg.
    • A PFS-csoport a gyors módban vagy a 2. fázisban használt Diffie-Hellman csoportot határozza meg.

  • Az IKE főmódú sa élettartama 28 800 másodpercen van rögzítve az Azure VPN-átjárókon.

  • UsePolicyBasedTrafficSelectors nem kötelező paraméter a kapcsolaton. Ha egy kapcsolatra UsePolicyBasedTrafficSelectors van állítva$True, a VPN-átjárót úgy konfigurálja, hogy egy helyszíni házirendalapú VPN-tűzfalhoz csatlakozzon.

    Ha engedélyezi UsePolicyBasedTrafficSelectors, győződjön meg arról, hogy a VPN-eszköz rendelkezik a helyszíni hálózatok (helyi hálózati átjáró) előtagjainak és az Azure-beli virtuális hálózat előtagjainak minden lehetséges kombinációjával definiált egyező forgalomválasztókkal, nem pedig bármelyikkel. A VPN-átjáró bármilyen forgalomválasztót elfogad, amelyet a távoli VPN-átjáró javasol, függetlenül attól, hogy mi van konfigurálva a VPN-átjárón.

    Például ha a helyszíni hálózati előtagok a 10.1.0.0/16 és a 10.2.0.0/16, a virtuális hálózati előtagok pedig 192.168.0.0/16 és 172.16.0.0/16, az alábbi forgalomválasztókat kell megadnia:

    • 10.1.0.0/16 <===> 192.168.0.0/16
    • 10.1.0.0/16 <===> 172.16.0.0/16
    • 10.2.0.0/16 <===> 192.168.0.0/16
    • 10.2.0.0/16 <===> 172.16.0.0/16

    A szabályzatalapú forgalomválasztókkal kapcsolatos további információkért lásd: VPN-átjáró csatlakoztatása több helyszíni szabályzatalapú VPN-eszközhöz.

  • Az időtúllépés rövidebb időszakokra állítása miatt az IKE gyakrabban végzi el az újrakulcsolást. Előfordulhat, hogy a kapcsolat bizonyos esetekben megszakad. Ez a helyzet nem feltétlenül kívánatos, ha a helyszíni helyek távolabb vannak attól az Azure-régiótól, ahol a VPN-átjáró található, vagy ha a fizikai kapcsolat állapota csomagvesztést okozhat. Általában azt javasoljuk, hogy állítsa be az időkorlátot 30 és 45 másodperc közé.

Hogyan lehet elhárítani a PFS csoportbeli eltérést?

A PFS csoport egy egyedi IPsec/IKE szabályzatban az Diffie-Hellman csoport, amelyet a Gyors Mód (2. fázis) esetében használnak. Az on-premises VPN eszköz konfigurációjának meg kell egyeznie vagy tartalmaznia kell a Azure IPsec/IKE szabályzatban konfigurált PFS csoportot. Ha nem, akkor a kapcsolat nem jön létre. Az ellenőrzési és hibaelhárítási lépésekről a következő témakörökben olvashat: 7. lépés az időszakosan megszakadó Azure Site-to-Site VPN-kapcsolatok hibaelhárításában, Egyéni IPsec-/IKE-szabályzatok konfigurálása az Azure Portalon és Egyéni IPsec-/IKE-szabályzatok konfigurálása az Azure PowerShell használatával.

További információ: VPN-átjáró csatlakoztatása több helyszíni szabályzatalapú VPN-eszközhöz.

Mely Diffie-Hellman-csoportokat támogatja az egyéni szabályzat?

Az alábbi táblázat az egyéni szabályzat által támogatott megfelelő Diffie-Hellman-csoportokat sorolja fel:

Diffie-Hellman csoport DH-csoport PFS-csoport A kulcs hossza
1 DHGroup1 PFS1 768 bites MODP
2 DHGroup2 PFS2 1024 bit MODP
14 DHGroup14
DHGroup2048		 PFS2048 2048 bites MODP
19 ECP256 ECP256 256 bites ECP
20 ECP384 ECP384 384 bites ECP
24 DHGroup24 PFS24 2048 bites MODP

További információ: RFC3526 és RFC5114.

Lecseréli az egyéni szabályzat a VPN-átjárók alapértelmezett IPsec/IKE-szabályzatkészleteit?

Igen. Miután egyéni szabályzatot adott meg egy kapcsolaton, az Azure VPN Gateway csak ezt a szabályzatot használja a kapcsolaton, mind IKE-kezdeményezőként, mind IKE-válaszadóként.

Ha eltávolítok egy egyéni IPsec/IKE-házirendet, azzal a kapcsolat nem védetté válik?

Nem, az IPsec/IKE továbbra is segít megvédeni a kapcsolatot. Miután eltávolította az egyéni szabályzatot egy kapcsolatból, a VPN-átjáró visszaáll az IPsec/IKE-javaslatok alapértelmezett listájára , és újraindítja az IKE-kézfogást a helyszíni VPN-eszközzel.

Az IPsec/IKE-házirend hozzáadása vagy frissítése megszakítja a VPN-kapcsolatot?

Igen. Ez kis fennakadást okozhat (néhány másodperc), mivel a VPN-átjáró megszakítja a meglévő kapcsolatot, és újraindítja az IKE kézfogást az IPsec-alagút újbóli létrehozásához az új titkosítási algoritmusokkal és paraméterekkel. Győződjön meg arról, hogy a helyszíni VPN-eszköz a megfelelő algoritmusokkal és kulcserősségekkel is konfigurálva van a megszakítás minimalizálása érdekében.

Használhatok különböző házirendeket különböző kapcsolatokhoz?

Igen. Az egyéni szabályzatot kapcsolatonként alkalmazzák. A különböző kapcsolatokhoz különböző IPsec/IKE-házirendeket hozhat létre és alkalmazhat.

Emellett a kapcsolatok egy részhalmazára is alkalmazhat egyéni házirendeket. A fennmaradó kapcsolatok az Azure alapértelmezett IPsec/IKE-házirendjét használják.

Használhatok egyéni szabályzatot VNet-to-VNet kapcsolatok esetén?

Igen. Egyéni szabályzatot alkalmazhat mind a helyszíni IPsec-kapcsolatokra, mind a virtuális hálózatok közötti kapcsolatokra.

Meg kell adnom ugyanazt a házirendet mindkét VNet-kapcsolati erőforrásnál?

Igen. A virtuális hálózatok közötti alagút két kapcsolati erőforrásból áll az Azure-ban, amelyek mindkét irányba mutatnak. Győződjön meg arról, hogy mindkét kapcsolati erőforrás ugyanazzal a szabályzattal rendelkezik. Ellenkező esetben a VNet és a VNet közötti kapcsolat nem jön létre.

Mi az alapértelmezett DPD időtúllépési érték? Megadhatok egy másik időkorlátot a DPD-nek?

A DPD alapértelmezett időtúllépése 45 másodperc a VPN-átjárókon. Az egyes IPsec- vagy virtuális hálózatok közötti kapcsolatokon eltérő DPD-időtúllépési értéket adhat meg 9 másodperctől 3600 másodpercig.

Feljegyzés

Az időtúllépés rövidebb időszakokra állítása miatt az IKE gyakrabban végzi el az újrakulcsolást. Előfordulhat, hogy a kapcsolat bizonyos esetekben megszakad. Ez a helyzet nem feltétlenül kívánatos, ha a helyszíni helyek távolabb vannak attól az Azure-régiótól, ahol a VPN-átjáró található, vagy ha a fizikai kapcsolat állapota csomagvesztést okozhat. Általában azt javasoljuk, hogy állítsa be az időkorlátot 30 és 45 másodperc közé.

Működik egy egyéni IPsec/IKE-szabályzat az ExpressRoute-kapcsolatokon?

Nem Az IPsec/IKE-szabályzatok csak S2S VPN- és VNet–VNet-kapcsolatokon működnek a VPN-átjárókon keresztül.

Hogyan kapcsolatot létesíteni az IKEv1 vagy IKEv2 protokolltípussal?

Az IKEv1-kapcsolatokat az összes útvonalalapú VPN-típusú termékváltozaton létrehozhatja, kivéve az alapszintű termékváltozatot, a standard termékváltozatot és más korábbi termékváltozatokat.

A kapcsolatok létrehozásakor megadhatja az IKEv1 vagy IKEv2 kapcsolati protokoll típusát. Ha nem ad meg kapcsolati protokolltípust, az IKEv2 az alapértelmezett beállítás, ahol lehetséges. További információkért tekintse meg az Azure PowerShell-parancsmag dokumentációját.

Az IKEv1 és az IKEv2 termékváltozattípusairól és támogatásáról további információt a VPN-átjáró csatlakoztatása több helyszíni házirendalapú VPN-eszközhöz című témakörben talál.

Engedélyezett az IKEv1 és az IKEv2 kapcsolatok közötti átvitel?

Igen.

Rendelkezhetek IKEv1 helyek közötti kapcsolatokkal az alapszintű termékváltozaton az útvonalalapú VPN-típushoz?

Nem Az alapszintű termékváltozat nem támogatja ezt a konfigurációt.

Módosíthatom a kapcsolat protokolltípusát a kapcsolat létrehozása után (IKEv1 IKEv2 és fordítva)?

Nem A kapcsolat létrehozása után nem módosíthatja az IKEv1 és az IKEv2 protokollt. Törölnie kell és újra létre kell hoznia egy új kapcsolatot a kívánt protokolltípussal.

Miért csatlakozik gyakran újra az IKEv1-kapcsolat?

Ha a statikus útválasztási vagy útvonalalapú IKEv1-kapcsolat rutin időközönként megszakad, valószínűleg azért van, mert a VPN-átjárók nem támogatják a helyszíni újrakulcsokat. A fő mód újrakulcsolásakor az IKEv1 alagutak megszakadnak, és akár 5 másodpercig is eltarthat az újracsatlakozás. A fő tárgyalási mód időtúllépési értéke határozza meg az újrakulcsolások gyakoriságát. Az újracsatlakozások megakadályozása érdekében válthat az IKEv2 használatára, amely támogatja a helyszíni újrakulcsokat.

Ha a kapcsolat véletlenszerű időpontokban újracsatlakozik, kövesse a hibaelhárítási útmutatót.

Hol találhatok további információt és lépéseket a konfigurációhoz?

Tekintse meg az alábbi cikkeket:

BGP és útválasztás

Minden Azure VPN Gateway SKU-n támogatott a BGP?

A BGP az Alapszintű termékváltozat kivételével minden Azure VPN Gateway-termékváltozatban támogatott.

Használhatom a BGP-t Azure Policy VPN-átjárókkal?

Nem, a BGP csak útvonalalapú VPN-átjárókon támogatott.

Milyen ASN-eket használhatok?

Saját nyilvános autonóm rendszerszámokat (ASN-eket) vagy privát ASN-eket használhat a helyszíni hálózatokhoz és az Azure-beli virtuális hálózatokhoz is.

A következő fenntartott ASN-eket nem használhatja:

  • Az Azure fenntartja:

    • Nyilvános ASN-ek: 8074, 8075, 12076
    • Privát ASN-ek: 65515, 65517, 65518, 65519, 65520

  • Fenntartva az IANA által:

    • 23456, 64496-64511, 65535-65551, 429496729

Nem adhatja meg ezeket az ASN-eket a helyszíni VPN-eszközökhöz, amikor VPN-átjárókhoz csatlakozik.

Használhatok 32 bites (4 bájtos) ASN-eket?

Igen, az Azure VPN Gateway mostantól támogatja a 32 bites (4 bájtos) ASN-eket. Az ASN decimális formátumban történő konfigurálásához használja az Azure PowerShellt, az Azure CLI-t vagy az Azure SDK-t.

Milyen privát ASN-eket használhatok?

A privát ASN-k használható tartományai a következők:

  • 64512-65514 és 65521-65534

Sem az IANA, sem az Azure nem foglalja le ezeket az ASN-eket, így hozzárendelheti őket a VPN-átjáróhoz.

Milyen címet használ az Azure VPN Gateway a BGP-társ IP-címéhez?

Az Azure VPN Gateway alapértelmezés szerint egyetlen IP-címet foglal le az GatewaySubnet aktív-készenléti VPN-átjárók tartományából, vagy két IP-címet az aktív-aktív VPN-átjárókhoz. Ezeket a címeket a rendszer automatikusan lefoglalja a VPN-átjáró létrehozásakor.

A lefoglalt BGP IP-címet az Azure PowerShell vagy az Azure Portal használatával találja meg. A PowerShellben használja a Get-AzVirtualNetworkGateway parancsot, és keresse meg a bgpPeeringAddress tulajdonságot. Az Azure Portal Átjárókonfiguráció lapján tekintse meg a BGP ASN konfigurálása tulajdonságot.

Ha a helyszíni VPN-útválasztók az Automatikus magánhálózati IP-címzés (APIPA) IP-címeket (169.254.x.x.x) használják BGP IP-címként, meg kell adnia egy vagy több Azure APIPA BGP IP-címet a VPN-átjárón. Az Azure VPN Gateway kiválasztja a helyi hálózati átjáróban megadott helyszíni APIPA BGP-társhoz használni kívánt APIPA-címeket, vagy egy nem APIPA-alapú, helyszíni BGP-társ magánhálózati IP-címét. További információ: BGP konfigurálása az Azure VPN Gatewayhez.

Milyen követelmények vonatkoznak a VPN-eszközöm BGP-társ IP-címére?

A helyszíni BGP-társcím nem lehet azonos a VPN-eszköz nyilvános IP-címével vagy a VPN-átjáró virtuális hálózat címterével. Használjon másik IP-címet a BGP-társ IP-címeként a VPN-eszközön. Ez lehet az eszköz visszacsatolási felületéhez hozzárendelt cím (normál IP-cím vagy APIPA-cím).

Ha az eszköz EGY APIPA-címet használ a BGP-hez, meg kell adnia egy vagy több APIPA BGP IP-címet a VPN-átjárón, a BGP konfigurálása az Azure VPN Gatewayhez című cikkben leírtak szerint. Adja meg ezeket a címeket a helynek megfelelő helyi hálózati átjáróban.

Mit kell megadnom címelőtagként a helyi hálózati átjáróhoz a BGP használatakor?

Fontos

Ez a korábban dokumentált követelménytől való változás.

Az Azure VPN Gateway belső gazdaútvonalat ad hozzá a helyszíni BGP-társ IP-címéhez az IPsec-alagúton keresztül. Ne adja hozzá a /32 útvonalat a Címtér mezőbe, mert redundáns. Ha APIPA-címet használ a helyszíni VPN-eszköz BGP IP-címeként, nem adhatja hozzá ehhez a mezőhöz.

Ha a Címtér mezőben egyéb előtagokat is hozzáad, azok statikus útvonalakként lesznek hozzáadva az Azure VPN-átjárón, a BGP-n keresztül tanult útvonalakon kívül.

Használhatom ugyanazt az ASN-t helyszíni VPN-hálózatokhoz és Azure-beli virtuális hálózatokhoz is?

Nem Ha a BGP-vel összekapcsolja őket, különböző ASN-eket kell hozzárendelnie a helyszíni hálózatok és az Azure-beli virtuális hálózatok között.

Az Azure VPN-átjárókhoz 65515-ös alapértelmezett ASN van hozzárendelve, függetlenül attól, hogy a BGP engedélyezve van-e a helyszíni kapcsolatokhoz. Ezt az alapértelmezett értéket felülbírálhatja egy másik ASN hozzárendelésével a VPN-átjáró létrehozásakor, vagy módosíthatja az ASN-t az átjáró létrehozása után. A helyszíni ASN-eket a megfelelő Azure helyi hálózati átjárókhoz kell hozzárendelnie.

Milyen címelőtagokat hirdetnek az Azure VPN-átjárók?

Az átjárók a következő útvonalakat hirdetik meg a helyszíni BGP-eszközökre:

  • Az Ön VNet címelőtagjai
  • Címelőtagok a VPN-átjáróhoz csatlakoztatott helyi hálózati átjárókhoz
  • A VPN-átjáróhoz csatlakoztatott egyéb BGP társviszony-létesítési munkamenetekből tanult útvonalak, kivéve az alapértelmezett útvonalat vagy útvonalakat, amelyek átfedésben vannak bármely virtuális hálózati előtaggal

Hány előtagot tudok meghirdetni az Azure VPN Gatewayen?

Az Azure VPN Gateway legfeljebb 4000 előtagot támogat. A BGP-munkamenet megszakad, ha az előtagok száma meghaladja a korlátot.

Meghirdethetem az alapértelmezett útvonalat (0.0.0.0/0) a VPN-átjárók felé?

Igen. Ne feledje, hogy az alapértelmezett útvonal közzététele minden virtuális hálózat kimenő forgalmát a helyszíni telephely felé kényszeríti. Azt is megakadályozza, hogy a virtuális hálózati gépek közvetlenül fogadjanak nyilvános kommunikációt az internetről, például a távoli asztali protokoll (RDP) vagy a Secure Shell (SSH) az internetről a gépekre.

Az, hogy lehet-e pontos előtagokat meghirdetni, attól függ, hogy az átjáró-átvitel engedélyezve van vagy nincs.

  • Ha az átjárótovábbítás engedélyezve van: Nem hirdetheti meg a pontos előtagokat a virtuális hálózat (beleértve a társhálózatokat is) előtagjaként. Az Azure blokkolja vagy szűri azokat az előtagokat, amelyek megegyeznek a virtuális hálózat címelőtagjaival. Azonban meghirdethet egy előtagot, amely a virtuális hálózat címterének szuperhalmaza. Ha például a virtuális hálózat a 10.0.0.0/16 címteret használja, meghirdetheti a 10.0.0.0/8-at, de a 10.0.0.0/16-os vagy a 10.0.0.0/24-et nem.
  • Ha az átjárótovábbítás nincs engedélyezve: Az átjáró nem tanulja meg a társhálózati előtagokat, így pontosan ugyanazokat az előtagokat hirdetheti meg, mint a társhálózata.

Használhatom a BGP-t a virtuális hálózatok közötti kapcsolatokkal?

Igen. A BGP-t használhatja a helyszíni kapcsolatokhoz és a virtuális hálózatok közötti kapcsolatokhoz is.

Kombinálhatom a BGP-t nem BGP-kapcsolatokkal az Azure VPN Gatewayeknél?

Igen, kombinálhatja a BGP- és nem BGP-kapcsolatokat ugyanazon Azure VPN Gatewaynél.

Támogatja az Azure VPN Gateway a BGP-átvitel útválasztását?

Igen. A BGP átviteli útválasztás támogatott, azzal a kivétellel, hogy a VPN-átjárók nem hirdetnek alapértelmezett útvonalakat más BGP-partnereknek. Ha több VPN-átjárón keresztül szeretné engedélyezni az átviteles útválasztást, engedélyeznie kell a BGP-t a virtuális hálózatok közötti összes köztes kapcsolaton. További információ: Tudnivalók a BGP-ről és a VPN Gatewayről.

Több alagút is lehet egy VPN-átjáró és a helyszíni hálózat között?

Igen, több helyek közötti VPN-alagutat is létrehozhat egy VPN-átjáró és a helyszíni hálózat között. Ezeket az alagutakat a rendszer az Azure VPN-átjárók alagútjainak teljes számával számolja, és mindkét alagúton engedélyeznie kell a BGP-t.

Ha például két redundáns alagúttal rendelkezik a VPN-átjáró és az egyik helyszíni hálózat között, akkor a VPN-átjáró teljes kvótáján kívül két alagutat használnak fel.

Rendelkezhetek több alagúttal két Azure-beli virtuális hálózat között a BGP-vel?

Igen, de legalább az egyik virtuális hálózati átjárónak aktív-aktív konfigurációban kell lennie.

Használhatok BGP-t S2S VPN-hez az Azure ExpressRoute és az S2S VPN egyidejű konfigurációjában?

Igen.

Mit kell hozzáadnom a helyszíni VPN-eszközhöz a BGP-kapcsolathoz?

Adja hozzá az Azure BGP társ IP-címének állomásútvonalát a VPN-eszközön. Ez az útvonal az IPsec S2S VPN-alagútra mutat.

Például, ha az Azure VPN társkészülék IP-címe 10.12.255.30, akkor hozzá kell adnia egy útvonalat a 10.12.255.30-hoz, amelynek következő ugrási felülete a VPN-eszköz megfelelő IPsec alagút-interfészéhez tartozik.

Támogatja az Azure VPN Gateway a BFD-t a helyek közötti (S2S) VPN-kapcsolatokhoz a BGP-vel?

Nem Az Azure VPN Gateways nem támogatja a kétirányú továbbítás észlelését (BFD) a helyek közötti (S2S) VPN-kapcsolatokhoz.

Mik a helyek közötti (S2S) VPN-kapcsolatok BGP időzítőbeállításai?

A BGP életben tartási időzítője 60 másodperc, a megőrzési időzítő pedig 180 másodperc. Az Azure VPN Gatewayek rögzített időzítőértékeket használnak, és nem támogatják a konfigurálható megőrzési vagy visszatartási időzítőket. A stabil BGP-munkamenetek fenntartása érdekében a helyszíni eszközöket egyező időzítőértékekkel kell konfigurálni, mivel az eltérő beállítások a BGP instabilitását eredményezhetik.

A VPN-átjárók BGP kapcsolódásokat vagy kapcsolatokat kezdeményeznek?

A VPN-átjárók BGP peering munkameneteket kezdeményeznek a helyi hálózati átjáró erőforrásokban megadott helyszíni BGP társ IP-címeknél a VPN-átjárók magánhálózati IP-címeivel. Ez a folyamat függetlenül attól, hogy a helyszíni BGP IP-címek az APIPA-tartományban vannak-e, vagy normál magánhálózati IP-címek. Ha a helyszíni VPN-eszközök APIPA-címeket használnak BGP IP-címként, konfigurálnia kell a BGP-hangszórót a kapcsolatok indításához.

Konfigurálhatom a kényszerített alagútépítést?

Igen. Lásd: Kényszerített bújtatás konfigurálása.

NAT

A NAT minden Azure VPN Gateway-termékváltozaton támogatott?

A NAT a VpnGw2 és VpnGw5, vpnGw2AZ és VpnGw5AZ között támogatott.

Használhatom a NAT-t virtuális hálózatok közötti vagy P2S-kapcsolatokon?

Nem

Hány NAT-szabályt használhatok EGY VPN-átjárón?

Egy VPN-átjárón legfeljebb 500 NAT-szabályt (bejövő és kimenő szabályokat kombinálva) hozhat létre.

Használhatok perjelet (/) NAT-szabálynévben?

Nem Hibaüzenet jelenik meg.

A NAT a VPN-átjáró összes kapcsolatára vonatkozik?

A NAT a NAT-szabályokkal rendelkező kapcsolatokra lesz alkalmazva. Ha egy kapcsolatnak nincs NAT-szabálya, a NAT nem lép érvénybe erre a kapcsolatra. Ugyanazon a VPN-átjárón lehetnek olyan kapcsolatok, amelyek NAT-tal működnek, és olyanok is, amelyek NAT nélkül működnek együtt.

Milyen típusú NAT-okat támogatnak a VPN-átjárók?

A VPN-átjárók csak statikus 1:1 NAT-ot és dinamikus NAT-t támogatnak. Nem támogatják a NAT64-et.

Működik a NAT aktív-aktív VPN-átjárókon?

Igen. A NAT aktív-aktív és aktív-készenléti VPN-átjárókon is működik. Minden NAT-szabály a VPN-átjáró egyetlen példányára lesz alkalmazva. Az aktív-aktív átjárókban hozzon létre egy külön NAT-szabályt minden átjárópéldányhoz az IP-konfigurációazonosító mezőn keresztül.

A NAT működik BGP-kapcsolatokkal?

Igen, használhatja a BGP-t NAT-tal. Íme néhány fontos szempont:

  • Ha biztosítani szeretné, hogy a tanult útvonalak és a meghirdetett útvonalak nat utáni címelőtagokra (külső leképezésekre) legyenek lefordítva a kapcsolatokhoz társított NAT-szabályok alapján, válassza a BGP-útvonalfordítás engedélyezése lehetőséget a NAT-szabályok konfigurációs lapján. A helyszíni BGP útválasztóknak kell hirdetniük az IngressSNAT-szabályokban meghatározott pontos előtagokat.

  • Ha a helyszíni VPN-útválasztó normál, nem APIPA-címet használ, és ütközik a virtuális hálózat címterével vagy más helyszíni hálózati terekkel, győződjön meg arról, hogy az IngressSNAT szabály a BGP-társ IP-címét egyedi, nem átfedésben lévő címre fordítja le. Helyezze a NAT utáni címet a helyi hálózati átjáró BGP-társ IP-cím mezőjébe.

  • A NAT nem támogatott BGP APIPA-címekkel.

Létre kell hoznom a megfelelő DNST-szabályokat az SNAT-szabályhoz?

Nem Egy egyetlen forrás hálózati címfordítási (SNAT) szabály határozza meg egy adott hálózat mindkét irányának fordítását:

  • Az IngressSNAT-szabály a helyszíni hálózatról a VPN-átjáróba érkező forrás IP-címek fordítását határozza meg. Emellett kezeli a virtuális hálózatról ugyanahhoz a helyszíni hálózathoz távozó cél IP-címek fordítását is.

  • Az EgressSNAT-szabály határozza meg a virtuális hálózat forrás IP-címeinek fordítását, amelyek a VPN gateway-en keresztül elérik a helyszíni hálózatokat. Emellett kezeli a virtuális hálózatba érkező csomagok cél IP-címeinek fordítását az EgressSNAT-szabályt tartalmazó kapcsolatokon keresztül.

Mindkét esetben nincs szükség célhálózati címfordítási (DNAT) szabályokra.

Mit tegyek, ha a virtuális hálózatom vagy a helyi hálózati átjáró címterének két vagy több előtagja van? Alkalmazhatok NAT-t mindegyikre, vagy csak egy részhalmazra?

Minden előtaghoz létre kell hoznia egy NAT-szabályt, mivel minden NAT-szabály csak egy címelőtagot tartalmazhat a NAT-hoz. Ha például a helyi hálózati átjáró címtere 10.0.1.0/24-es és 10.0.2.0/25-ös, akkor két szabályt hozhat létre:

  • IngressSNAT szabály 1: Képzze le a 10.0.1.0/24-et a 192.168.1.0/24-re.
  • IngressSNAT szabály 2: Térkép 10.0.2.0/25-ről 192.168.2.0/25-re.

A két szabálynak meg kell egyeznie a megfelelő címelőtagok előtaghosszával. Ugyanez az útmutató vonatkozik a virtuális hálózat címterére vonatkozó EgressSNAT-szabályokra is.

Fontos

Ha csak egy szabályt csatol az előző kapcsolathoz, a másik címtér nem lesz lefordítva.

Milyen IP-tartományokat használhatok külső leképezéshez?

Bármilyen megfelelő IP-címtartományt használhat a külső leképezéshez, beleértve a nyilvános és a privát IP-címeket is.

Használhatok különböző EgressSNAT-szabályokat a virtuális hálózat címterének lefordításához a helyszíni hálózatok különböző előtagjaira?

Igen. Ugyanahhoz a virtuális hálózat címteréhez több EgressSNAT-szabályt is létrehozhat, majd alkalmazhatja az EgressSNAT-szabályokat a különböző kapcsolatokra.

Használhatom ugyanazt az IngressSNAT-szabályt a különböző kapcsolatokon?

Igen. A redundancia biztosításához általában ugyanazt az IngressSNAT-szabályt használja, ha a kapcsolatok ugyanazon helyszíni hálózathoz tartoznak. Nem használhatja ugyanazt a bejövő szabályt, ha a kapcsolatok különböző helyszíni hálózatokhoz tartoznak.

Szükségem van mind a bejövő, mind a kimenő szabályokra a NAT-kapcsolaton?

Ha a helyszíni hálózati címtér átfedésben van a virtuális hálózat címterével, akkor ugyanazon a kapcsolaton bejövő és kimenő szabályokra is szükség van. Ha a virtuális hálózat címtere egyedi az összes csatlakoztatott hálózat között, nincs szükség az EgressSNAT-szabályra ezeken a kapcsolatokon. A bejövő forgalom szabályaival elkerülheti a cím átfedését a helyszíni hálózatok között.

Mit választok IP-konfigurációazonosítóként?

Az IP-konfiguráció azonosítója egyszerűen annak az IP-konfigurációs objektumnak a neve, amelyet a NAT-szabály használni szeretne. Ezzel a beállítással egyszerűen kiválaszthatja, hogy melyik átjáró nyilvános IP-címe vonatkozik a NAT-szabályra. Ha nem adott meg egyéni nevet az átjáró létrehozásakor, az átjáró elsődleges IP-címe az alapértelmezett IP-konfigurációhoz lesz hozzárendelve, a másodlagos IP-cím pedig az activeActive IP-konfigurációhoz van rendelve.

Létesítmények közötti kapcsolatok és virtuális gépek

Ha a virtuális gépem egy virtuális hálózaton található, és rendelkezem egy létesítmények közötti kapcsolattal, hogyan csatlakozhatok a virtuális géphez?

Ha az RDP engedélyezve van a virtuális gép számára, a magánhálózati IP-címmel csatlakozhat a virtuális géphez. Ebben az esetben meg kell adnia a privát IP-címet és azt a portot, amelyhez csatlakozni szeretne (általában 3389). Konfigurálnia kell a portot a virtuális gépen a forgalom számára.

Egy másik, ugyanazon a virtuális hálózaton található virtuális gépről is csatlakozhat a virtuális géphez magán IP-címmel. Ha a virtuális hálózaton kívüli helyről csatlakozik, nem tud RDP-kapcsolatot létesíteni a virtuális géppel a privát IP-cím használatával. Ha például pont–hely virtuális hálózat van konfigurálva, és nem hoz létre kapcsolatot a számítógépről, nem tud privát IP-címmel csatlakozni a virtuális géphez.

Ha a virtuális gépem létesítmények közötti kapcsolattal rendelkező virtuális hálózaton található, a virtuális gépem teljes adatforgalma ezen a kapcsolaton halad át?

Nem Csak az a forgalom halad át a virtuális hálózati átjárón, amely a virtuális hálózat helyi hálózati IP-címtartományaiban található cél IP-címmel rendelkezik.

A virtuális hálózaton belüli cél IP-címvel rendelkező forgalom a virtuális hálózaton belül marad. A rendszer a terheléselosztón keresztül más forgalmat küld a nyilvános hálózatokra. Vagy ha kényszerített bújtatást használ, a forgalom a VPN-átjárón keresztül lesz elküldve.

Hogyan háríthatom el egy virtuális gép RDP-kapcsolatának hibáit?

Ha nem tud csatlakozni egy virtuális géphez a VPN-kapcsolaton keresztül, ellenőrizze az alábbi elemeket:

  • Ellenőrizze, hogy a VPN-kapcsolat sikeresen létrejött-e.
  • Ellenőrizze, hogy csatlakozik-e a virtuális gép magánhálózati IP-címéhez.
  • Ha a magánhálózati IP-címmel tud csatlakozni a virtuális géphez, de a számítógép nevét nem, ellenőrizze, hogy megfelelően konfigurálta-e a DNS-t. A virtuális gépek névfeloldásáról további információt az Azure-beli virtuális hálózatokban található erőforrások névfeloldása című témakörben talál.

Ha pont–hely kapcsolaton keresztül csatlakozik, ellenőrizze a következő további elemeket:

  • Az ipconfig segítségével ellenőrizze annak a számítógépnek az Ethernet-adapteréhez rendelt IPv4-címet, amelyről csatlakozik. Ha az IP-cím azon virtuális hálózat címtartományán belül van, amelyhez csatlakozik, vagy a VPN kliens címkészletének címtartományán belül van, akkor ezek egymással átfedésben lévő címtartományok. Ha a címtér átfedésben van ily módon, a hálózati forgalom nem éri el az Azure-t. A helyi hálózaton marad.
  • Ellenőrizze, hogy a VPN-ügyfél konfigurációs csomagja a virtuális hálózat DNS-kiszolgálójának IP-címeinek megadása után lett-e létrehozva. Ha frissítette a DNS-kiszolgáló IP-címeit, hozzon létre és telepítsen egy új VPN-ügyfélkonfigurációs csomagot.

Az RDP-kapcsolatok hibaelhárításáról további információt a virtuális gép távoli asztali kapcsolatainak hibaelhárítása című témakörben talál.

Ügyfél által vezérelt átjárók karbantartása

Mely szolgáltatások szerepelnek a hálózati átjárók hatókörének karbantartási konfigurációjában?

A Hálózati átjárók hatóköre a hálózati szolgáltatások átjáróerőforrásait tartalmazza, beleértve az alábbi erőforrástípusokat:

  • Virtuális hálózati átjáró az ExpressRoute szolgáltatásban
  • Virtuális hálózati átjáró a VPN Gateway szolgáltatásban
  • VPN-átjáró (helyek közötti) az Azure Virtual WAN szolgáltatásban
  • VPN-átjáró (felhasználói VPN vagy pont–hely) az Azure Virtual WAN szolgáltatásban
  • ExpressRoute-átjáró a Virtual WAN szolgáltatásban

Milyen karbantartást támogat az ügyfél által ellenőrzött karbantartás?

Az Azure-szolgáltatások rendszeres karbantartási frissítéseken mennek keresztül a funkciók, a megbízhatóság, a teljesítmény és a biztonság javítása érdekében. Miután konfigurált egy karbantartási időszakot az erőforrásokhoz, a vendég operációs rendszer karbantartása és a szolgáltatás karbantartása az adott időszakban történik. Az ügyfél által irányított karbantartás nem terjed ki a gazdagépfrissítésekre (a Power gazdagép frissítésein túl) és a kritikus biztonsági frissítésekre.

Kaphatok speciális értesítést a karbantartásról?

Jelenleg nem kaphat speciális értesítést a Network Gateway-erőforrások karbantartásáról.

Öt óránál rövidebb karbantartási időszakot konfigurálhatok?

Jelenleg legalább ötórás időtartamot kell konfigurálnia az előnyben részesített időzónában.

A napi ütemezéstől eltérő karbantartási időszakot is konfigurálhatok?

Jelenleg napi karbantartási időszakot kell konfigurálnia.

Vannak olyan esetek, amikor nem tudok bizonyos frissítéseket szabályozni?

Az ügyfél által felügyelt karbantartás támogatja a vendég operációs rendszer és a szolgáltatás frissítését. Ezek a frissítések a legtöbb olyan karbantartási elemhez tartoznak, amelyek aggodalomra adnak okot az ügyfelek számára. Néhány más típusú frissítés, beleértve a gazdagépfrissítéseket is, kívül esik az ügyfél által ellenőrzött karbantartás hatókörén.

Ha egy nagy súlyosságú biztonsági probléma veszélyeztetheti az ügyfeleket, előfordulhat, hogy az Azure-nak felül kell bírálnia a karbantartási időszak ügyfél-vezérlését, és le kell küldenie a módosítást. Ezek a változások ritkán fordulnak elő, amelyeket csak szélsőséges esetekben használunk.

A karbantartási konfigurációs erőforrásoknak ugyanabban a régióban kell lenniük, mint az átjáróerőforrásnak?

Igen.

Mely átjáró-termékváltozatok konfigurálhatók ügyfél által vezérelt karbantartás használatára?

Az Azure VPN Gateway összes termékváltozata (az alapszintű termékváltozat kivételével) konfigurálható az ügyfél által vezérelt karbantartás használatára.

Mennyi ideig tart, amíg egy karbantartási konfigurációs szabályzat érvényessé válik az átjáró-erőforráshoz való hozzárendelése után?

Az hálózati átjárók akár 24 órát is igényelhetnek, hogy kövessék a karbantartási ütemtervet, miután a karbantartási szabályzat társítva lett az átjáró-erőforrással.

Van-e korlátozás az ügyfél által ellenőrzött karbantartás használatára az alapszintű termékváltozat nyilvános IP-címe alapján?

Igen. Az ügyfél által vezérelt karbantartás nem működik az alapszintű termékváltozat nyilvános IP-címeit használó erőforrások esetében, kivéve a szolgáltatásfrissítéseket. Ezen átjárók esetében a vendég operációs rendszer karbantartása nem követi az ügyfél által ellenőrzött karbantartási ütemezést az infrastruktúra korlátozásai miatt.

Hogyan tervezzem meg a karbantartási időszakokat a VPN és az ExpressRoute együttes használata esetén?

Ha a VPN-et és az ExpressRoute-t együttélési forgatókönyvben használja, vagy ha olyan erőforrásokkal rendelkezik, amelyek biztonsági mentésként működnek, javasoljuk, hogy külön karbantartási időszakokat állítson be. Ez a megközelítés biztosítja, hogy a karbantartás ne befolyásolja egyszerre a biztonsági mentési erőforrásokat.

Ütemeztem egy karbantartási időszakot egy későbbi időpontra az egyik erőforrásom számára. A karbantartási tevékenységek addig szüneteltetve vannak ezen az erőforráson?

Nem, a karbantartási tevékenységek nem szünetelnek az erőforráson az ütemezett karbantartási időszak előtti időszakban. A karbantartási ütemtervben nem szereplő napok esetében a karbantartás a szokásos módon folytatódik az erőforráson.

Hogyan többet megtudni az ügyfél által felügyelt átjárók karbantartásáról?

További információt a VPN Gateway ügyfél által ellenőrzött átjárókarbantartásának konfigurálása című cikkben talál.

Kapcsolódó tartalom

Az "OpenVPN" az OpenVPN Inc. védjegye.

  • Last updated on