Megosztás:

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.

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ó VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5 IKEv1 és 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. Ez a követelmény az összes átjáró termékváltozatára vonatkozik, kivéve az alapszintű termékváltozatot. Az alapszintű termékváltozat jelenleg csak az alapszintű termékváltozat nyilvános IP-címeit támogatja. Dolgozunk azon, hogy támogatást adjunk a standard termékváltozat nyilvános IP-címeinek az alapszintű termékváltozathoz.

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?

Műveletet hajtunk végre az alapszintű termékváltozat nyilvános IP-címeit használó üzembe helyezett VPN-átjárók folyamatos működésének biztosítása érdekében az alapszintű IP-cím 2025. szeptemberi kivonásáig. A kivonás előtt biztosítjuk az ügyfeleknek az alapszintű ip-címről a standard IP-címre való migrálási útvonalat.

Az Alap termékváltozat nyilvános IP-címei azonban kivezetésre kerülnek. A jövőben, amikor VPN-átjárót hoz létre, 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 IP-t használó VPN Gateway idővonalára gyakori frissítések vonatkoznak. A legújabb migrálási ütemtervért tekintse meg ezt a 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ó: Az IPv6 konfigurálása VPN Gatewayhez.

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.

Létrehozhatok VPN-átjárót a portálon a Basic SKU használatával?

Nem Az alapszintű termékváltozat nem érhető el a portálon. Alapszintű termékváltozatú VPN-átjárót az Azure CLI vagy az Azure PowerShell lépéseivel hozhat létre.

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.

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

A standard és nagy teljesítményű termékváltozatok 2025. szeptember 30-án megszűnnek. A bejelentést az Azure Updates webhelyén tekintheti meg. A termékcsapat 2024. november 30-ig elérhetővé teszi a migrációs útvonalat ezekhez a SKU-khoz. További információkért tekintse meg a VPN Gateway örökölt termékváltozatainak cikkét.

A legújabb migrálási ütemtervet a közelgő várható változások című témakörben talál.

Létrehozhatok egy új átjárót, amely standard vagy nagy teljesítményű SKU-t használ a 2023. november 30-i elavulási bejelentés után?

Nem 2023. december 1-től nem hozhat létre standard vagy nagy teljesítményű termékváltozatokat használó átjárókat. A VpnGw1 és VpnGw2 termékváltozatokat használó átjárókat a standard és a nagy teljesítményű termékváltozatokkal megegyező áron hozhatja létre, amelyek a díjszabási oldalon találhatók.

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

A standard vagy nagy teljesítményű termékváltozatot használó összes meglévő átjáró 2026. február 28-ig támogatott lesz (2025. szeptember 30-tól meghosszabbítva).

Megváltozik az IP-címem, ha az örökölt VPN-átjáró termékváltozata (Standard vagy HighPerformance) az Azure Portalon kezdeményezett alapszintű IP-címmigrálás részeként lesz migrálva?

Nem, az IP-cím nem változik, ha alapszintű IP-címet migrál az Azure Portal használatával. Az alapszintű termékváltozat IP-címét áttelepítheti a Standard termékváltozat IP-címére egy ügyfél által vezérelt portálon keresztül. Az alapszintű termékváltozat IP-migrálásáról további információt az Alapszintű termékváltozat nyilvános IP-címének migrálása a VPN Gateway standard termékváltozatára című cikkben talál.

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

Nem, ha meg szeretné őrizni az IP-címet, át kell migrálnia a Basic IP-címet az átjáróval a portál felületén keresztül. A migrálás részeként az átjárók automatikusan át lesznek migrálva az AZ termékváltozatokra.

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

Az Ön SKU-jai automatikusan átkerülnek és frissítésre kerülnek AZ SKU-kká az alapszintű IP-migrálás részeként. 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. A VpnGw1AZ és a VpnGw2AZ jobb teljesítményt nyújt. 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 2026. február 28-ig nem migrálok?

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. A március után is a Standard vagy a Nagy teljesítményű termékváltozatot továbbra is használó összes átjáró automatikusan és az áttelepítés után is megkísérli a migrálást:

  • A Standard termékváltozat átjárói automatikusan VpnGw1AZ-re frissülnek
  • A nagy teljesítményű termékváltozat átjárói automatikusan VpnGw2AZ-re frissülnek

**Megjegyzés: Ha korlátozásokat tapasztalunk – például nem elegendő az alhálózat mérete, nem tudjuk automatikusan végrehajtani az átjáró migrálását, és ügyfélműveletre lesz szükség.

A késések elkerülése érdekében előre migrálja saját átjáróit az alapszintű IP migrálási eszköz segítségével. Ez segít biztosítani, hogy a környezet készen álljon az AZ termékváltozat frissítésére, és megakadályozza az utolsó pillanatban felmerülő problémákat.

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ím erőforrását támogatja (amely a kivonási útvonalon található). Dolgozunk azon, hogy támogatást adjunk a standard termékváltozat nyilvános IP-címerőforrásához a VPN Gateway alapszintű termékváltozatához.

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

Ez a szakasz fontos kérdéseket és szempontokat ismertet az Alapszintű SKU nyilvános IP-címről a Standard SKU nyilvános IP-címre való migrálással kapcsolatban VPN Gateway-kiszolgálók esetén, amelyek jelenleg Alapszintű SKU nyilvános IP-címet használnak. Ez nem vonatkozik azokra a telepítésekre, amelyek már standard SKU nyilvános IP-címet használnak. További információ: Alapszintű SKU IP elavulásának bejelentése.

Mi a várt ügyfélhatás?

A várt ügyfélhatás magában foglalja az új árazási változásokat és az akár 10 perces állásidőt az ügyfél által ellenőrzött migrálás során. Az ügyfeleknek három hónapjuk lesz a migrálásra az áttelepítési eszköz kiadása után. A sikeres migráláshoz győződjön meg arról, hogy a megfelelő IP-címtérrel és alhálózati mérettel rendelkezik.

Mi a migrálás várható ütemterve?

Itt látható a migrálási eszköz rendelkezésre állásának várható ütemterve és a Basic SKU Public IP címek megszüntetése.

Dátum Esemény
2025. augusztus 4. Az alapszintű SKU-nyilvános IP-címről a Standard SKU-ra való migrációs eszköz elérhetővé válik (nyilvános előzetes verzió) nyilvános felhőbeli Active-Passive VPN-átjárókhoz.
2025. szeptember (feltételes GA) Ideiglenes GA idővonal a Nyilvános és Szuverén Felhő támogatásához.
2025. szeptember vége (feltételes ga) Migrálási eszközök általános elérhetősége Active-Active VPN-átjárókhoz (alap → standard SKU közösségi IP-cím).
2025. október (tervezett) Az automatizált képesség elérhetővé válik az alapszintű nyilvános IP-cím alapvető termékváltozat-átjárókból való eltávolításához. A meglévő IP-címek változatlanok maradnak, és a kapcsolat nem szakad meg.
2025. augusztus 4. – 2026. január vége Az ügyfél által vezérelt migrálások az eszköz rendelkezésre állása után kezdeményezhetők (kb. 6 hónapos időszak).
2026. január vége Az összes alapszintű IP-címmel rendelkező VPN Gateway teljes migrációs ütemtervét meghosszabbítják ezen a napon.
2026. február Az alap SKU nyilvános IP-címei teljes mértékben megszűntek.

Mik a szükséges ügyfélműveletek?

Győződjön meg arról, hogy a migrálás támogatásához megfelelő IP-címtérrel és alhálózati mérettel rendelkezik. Ha az átjáró alapszintű IP-címet használ, át kell telepítenie egy standard IP-címre a szolgáltatás megszakadásának elkerülése érdekében. Erre az áttelepítésre azért van szükség, mert az alapszintű IP-címek 2025 szeptemberére elavultak lesznek. Ha az átjáró már standard IP-címet használ, nincs szükség műveletre.

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 Server 2008 R2 (csak 64 bites)
  • Windows 8.1 (32 bites és 64 bites)
  • Windows Server 2012 (csak 64 bites)
  • Windows Server 2012 R2 (csak 64 bites)
  • Windows Server 2016 (csak 64 bites)
  • Windows Server 2019 (csak 64 bites)
  • Windows Server 2022 (csak 64 bites)
  • Windows 10
  • Windows 11
  • macOS 10.11-es 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.

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

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 10 2400 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é.

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 a virtuális hálózati átjáró a BFD-t a BGP-vel létesített S2S-kapcsolatokhoz?

Nem A kétirányú továbbításészlelő (BFD) egy protokoll, amellyel a BGP-vel gyorsabban észlelheti a szomszédos kapcsolat kiesését, mint a szokásos BGP-keepalive időközökkel. A BFD a lan-környezetekben való munkavégzésre tervezett alszekundumos időzítőket használ, a nyilvános internetkapcsolaton vagy WAN-kapcsolatokon azonban nem.

A nyilvános interneten keresztüli kapcsolatok esetében bizonyos csomagok késleltetése vagy elvetése nem szokatlan, ezért ezeknek az agresszív időzítőknek a bevezetése instabilitást okozhat. Ez az instabilitás miatt a BGP visszafoghatja az útvonalakat.

Másik lehetőségként úgy konfigurálhatja a helyszíni eszközt, hogy az időzítők az alapértelmezett 60 másodperces megőrzési időköznél vagy a 180 másodperces visszatartási időnél alacsonyabbak legyenek. Ez a konfiguráció gyorsabb konvergenciát eredményez. Az alapértelmezett 60 másodperces megőrzési időköz vagy az alapértelmezett 180 másodperces visszatartási idő alatti időzítők azonban nem megbízhatóak. Javasoljuk, hogy tartsa meg az időzítőket az alapértelmezett értékeknél vagy annál magasabb értéken.

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 VpnGw25, 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 100 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