VPN Gateway – gyakori kérdések

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. A virtuális hálózatok összekapcsolhatók az azonos régióban vagy más Azure-régiókban található virtuális hálózatokkal is.

Ö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 adott meg a virtuális hálózat létrehozásakor, a VPN Gateway a megadott DNS-kiszolgálókat használja. Ha megad egy DNS-kiszolgálót, ellenőrizze, hogy a DNS-kiszolgáló meg tudja-e oldani 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 gyakori kérdések Többhelyes és virtuális hálózatok közötti kapcsolatok című szakaszát.

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

Szám A további nyilvános IP-címek költségeit azonban ennek megfelelően számítjuk fel. Lásd az IP-cím díjszabását.

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

A következő helyek közötti virtuális hálózati átjárókapcsolatok támogatottak:

  • Helyek közötti: VPN-kapcsolat IPsec-en keresztül (IKE v1 és IKE v2). Ehhez a kapcsolattípushoz VPN-eszköz vagy RRAS szükséges. További információ: Helyek közötti.
  • Pont–hely: VPN-kapcsolat SSTP-n (Secure Socket Tunneling Protocol) vagy IKE v2-n keresztül. Ehhez a kapcsolathoz nincs szükség VPN-eszközre. További információ: Pont–hely.
  • Virtuális hálózatok közötti kapcsolat: Ez a kapcsolattípus megegyezik a helyek közötti konfigurációval. A virtuális hálózatok közötti kapcsolat egy IPsec-et (IKE v1 és IKE v2) használó VPN-kapcsolat, Nem igényel VPN-eszközt. További információ: Virtuális hálózatok közötti kapcsolat.
  • ExpressRoute: Az ExpressRoute egy privát kapcsolat az Azure-hoz a WAN-ból, nem vpn-kapcsolat a nyilvános interneten keresztül. További információk: ExpressRoute Technical Overview (Az ExpressRoute műszaki áttekintése) és ExpressRoute FAQ (ExpressRoute – gyakori kérdések).

A VPN Gateway-kapcsolatokról további információt a VPN Gatewayről szóló cikkben talál.

Mi a különbség a helyek közötti kapcsolat és a pont–hely kapcsolat 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. Ez azt jelenti, hogy a helyszínen található számítógépek bármelyikéről csatlakozhat a virtuális hálózaton belüli virtuális gépek vagy szerepkörpéldányok bármelyikéhez az útválasztás és az engedélyek konfigurációjától függően. 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 IPsec VPN-készüléket használ (hardvereszközt vagy szoftverkészüléket), amelyet 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. Ez a típus a Windows beépített VPN-ügyfelét használja. A pont–hely konfiguráció részeként telepít egy tanúsítványt és egy VPN-ügyfélkonfigurációs csomagot, amely 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 ideális megoldás, ha csatlakozni szeretne egy virtuális hálózathoz, de nem a helyszínen tartózkodik, 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ípussal hozza létre az átjáróhoz. Az útvonalalapú VPN-típusok korábbi megnevezése dinamikus átjáró volt a klasszikus üzemi modellben.

Adatvédelem

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

Szám

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 Gateway létrehozásakor a „Vpn” -GatewayType értéket használja. További információ: Információ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 Házirendalapú átjárók a PowerShell/CLI használatával hozhatók létre.

Korábban a régebbi átjáró-termékváltozatok 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ékváltozata Támogatott IKE-verziók
Szabályzatalapú átjáró Alap IKEv1
Útvonalalapú átjáró Alap 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?

Szám 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 az átjárót törölni kell és újra létre kell hozni. 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 forgalomválasztók a New-AzIpsecTrafficSelectorPolicy PowerShell parancson keresztül definiálhatók egy kapcsolat trafficSelectorPolicies attribútumával. A megadott forgalomválasztó érvénybe lépéséhez győződjön meg arról, hogy a Szabályzatalapú forgalomválasztók használata beállítás engedélyezve van.

Az egyéni konfigurált forgalomválasztók csak akkor lesznek javasolva, ha egy Azure 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 konzisztens az összes kapcsolati mód (Alapértelmezett, InitiatorOnly és ResponderOnly) között.

Szükségem van GatewaySubnetre?

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 az összes átjáró-alhálózatnak a „GatewaySubnet” névvel kell rendelkeznie. Ne nevezze el másként az átjáróalhálózatát, és ne helyezzen üzembe rajta virtuális gépeket vagy más eszközt.

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 elég IP-címet tartalmaz a későbbi növekedéshez és az esetleges új kapcsolatkonfigurációk kialakításához. Tehát, míg egyes konfigurációkhoz létrehozhat kicsi, akár /29-es méretű átjáróalhálózatot is, ajánlott /27-est vagy nagyobbat létrehozni (/27, /26, /25 stb.). Vizsgálja meg a létrehozni kívánt konfiguráció követelményeit és ellenőrizze, hogy az átjáró-alhálózat megfelel-e ezeknek a követelményeknek.

Telepíthetek virtuális gépeket vagy szerepkörpéldányokat az átjáróalhálózatomra?

Szám

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. Ezért a VPN-átjáró nyilvános IP-címével fog rendelkezni, amint létrehozza a standard termékváltozat nyilvános IP-erőforrását, amelyet használni kíván.

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 az alapszintű termékváltozat kivételével az összes átjáró termékváltozatára vonatkozik. Az Alapszintű átjáró termékváltozata jelenleg csak az alapszintű termékváltozat nyilvános IP-címeit támogatja. Hamarosan hozzá fogjuk adni a standard termékváltozat nyilvános IP-címeinek támogatását az alapszintű átjáró termékváltozataihoz.

A korábban létrehozott nem zónaredundáns és nem zonális átjárók esetében (az átjáró termékváltozatai, 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 VPN-átjáró nyilvános IP-címe nem változik, amikor átméretezi, alaphelyzetbe állítja vagy elvégzi a VPN-átjáró egyéb belső karbantartását és frissítését.

Hogyan befolyásolja a nyilvános IP-cím alapszintű termékváltozatának 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. Ha már rendelkezik nyilvános nyilvános SKU-címmel rendelkező VPN-átjárókkal, nincs szükség semmilyen műveletre.

Fontos azonban megjegyezni, hogy az alapszintű termékváltozat nyilvános IP-címeinek kivonása folyamatban van. Az új 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 további részletek itt találhatók.

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

Az Azure VPN PSK (előmegosztott kulcsos) hitelesítést használ. A VPN-alagút létrehozásakor létrehozunk egy előmegosztott kulcsot (PSK) is. Az automatikusan létrehozott PSK-t az előre megosztott kulcs beállítása PowerShell-parancsmaggal vagy REST API-val módosíthatja a sajátjára.

Használhatom-e az Előmegosztott kulcs beállítása API-t a házirendalapú (statikus útválasztású) átjárói VPN konfigurálásához?

Igen, az Előmegosztott kulcs beállítása API és PowerShell-parancsmag használható az Azure házirendalapú (statikus) VPN-ek és útvonalalapú (dinamikus) VPN-ek konfigurálásához is.

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

A hitelesítéshez csak előre megosztott kulcsokat (PSK) használhatunk.

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

Resource Manager-alapú üzemi modell

  • PowerShell esetén: Használja az „AddressPrefix” parancsot a helyi hálózati átjáró forgalmának meghatározásához.
  • Azure Portal: lépjen a Helyi hálózati átjáró > konfigurációs > címteréhez.

Klasszikus üzemi modell

  • Azure Portal: keresse meg a klasszikus virtuális hálózati > VPN-kapcsolatokat > helyek közötti VPN-kapcsolatok > Helyi hely neve > Helyi hely > Ügyfél címterét.

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

Igen, a NAT bejárás (NAT-T) támogatott. Az Azure VPN Gateway NEM hajt végre NAT-szerű funkciókat az IPsec-alagutakba vagy onnan é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, az Azure-ban üzembe helyezheti saját VPN-átjáróit vagy -kiszolgálóit az Azure Piactérről, 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. Azure-tanúsítványok védik őket (zárolva). Megfelelő tanúsítványok nélkül a külső entitások, beleértve az átjárók ügyfeleit, nem lesznek képesek semmilyen hatással ezekre a végpontokra.

A virtuális hálózati átjáró alapvetően egy több-otthonos eszköz, amelynek egyetlen hálózati adaptere koppint az ügyfél magánhálózatára, és egy hálózati adapter, amely a nyilvános hálózat felé 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. A nyilvános végpontokat az Azure biztonsági naplózás rendszeresen ellenőrzi.

Létrehozhatok VPN-átjárót a portál alapszintű átjáró termékváltozatával?

Szám Az alapszintű termékváltozat nem érhető el a portálon. Alapszintű termékváltozatú VPN-átjárót az Azure CLI vagy a PowerShell használatával 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:

Termékváltozat elavulása régi termékváltozatokhoz

A standard és nagy teljesítményű termékváltozatok 2025. szeptember 30-án megszűnnek. A bejelentést itt 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. Jelenleg nincs szükség olyan műveletre, amelyet meg kell tennie.

Létrehozhatok egy új standard/nagy teljesítményű termékváltozatot a 2023. november 30-i elavulás bejelentése után?

Szám 2023. december 1-jétől nem hozhat létre új átjárókat standard vagy nagy teljesítményű termékváltozatokkal. Új átjárókat a VpnGw1 és a VpnGw2 használatával hozhat létre a standard és a nagy teljesítményű termékváltozatokkal megegyező áron, amely a díjszabási oldalon található.

Mennyi ideig támogatják a meglévő átjárókat a Standard/Nagy teljesítményű termékváltozatok?

2025. szeptember 30-ig minden standard vagy nagy teljesítményű termékváltozatot használó átjáró támogatott.

Most kell migrálnom a Standard/Nagy teljesítményű átjáró termékváltozatokat?

Nem, jelenleg nincs szükség műveletre. 2024 decemberétől áttelepítheti termékváltozatait. A migrálás lépéseiről részletes dokumentációt küldünk.

Melyik termékváltozatba migrálhatom az átjárót?

Amikor elérhetővé válik az átjáró termékváltozata, az SKU-k az alábbiak szerint migrálhatók:

  • Standard –> VpnGw1
  • Nagy teljesítmény –> VpnGw2

Mi a teendő, ha egy AZ termékváltozatra szeretnék migrálni?

Az örökölt termékváltozatot nem migrálhatja az AZ termékváltozatba. Vegye figyelembe azonban, hogy a 2025. szeptember 30. után még standard vagy nagy teljesítményű termékváltozatokat használó összes átjárót áttelepítjük és automatikusan frissítjük a következő termékváltozatokra:

  • Standard –> VpnGw1AZ
  • Nagy teljesítmény –> VpnGw2AZ

Ezzel a stratégiával automatikusan migrálhatja és frissítheti termékváltozatait az AZ termékváltozatra. Ezután szükség esetén átméretezheti a termékváltozatot az adott termékváltozatcsaládon belül. Tekintse meg az AZ termékváltozat díjszabását ismertető díjszabási oldalunkat . A termékváltozatok átviteli sebességével kapcsolatos információkért tekintse meg az átjáró termékváltozatairól szóló témakört.

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

Ha 2025. szeptember 30-ig migrálja az SKU-kat, nem lesz díjszabási különbség. A VpnGw1 és a VpnGw2 termékváltozatok a Standard és a Nagy teljesítményű termékváltozatokkal megegyező áron érhetők el. Ha ezen a napon nem migrál, a termékváltozatok automatikusan át lesznek migrálva és frissítve az AZ termékváltozatokká. Ebben az esetben árkülönbség van.

Hatással lesz-e a teljesítmény az átjárókra ezzel a migrálással?

Igen, jobb teljesítményt érhet el a VpnGw1 és a VpnGw2 használatával. Jelenleg a VpnGw1 650 Mbps-os verziója 6,5-szeres, a VpnGw2 pedig 1 Gb/s-os teljesítménybeli javulást biztosít az örökölt Standard és Nagy teljesítményű átjárókkal azonos áron. Az SKU átviteli sebességével kapcsolatos további információkért tekintse meg az átjáró termékváltozatairól szóló témakört.

Mi történik, ha 2025. szeptember 30-ig nem migrálom a termékváltozatokat?

A standard vagy nagy teljesítményű termékváltozatokat továbbra is használó összes átjáró automatikusan migrálva lesz, és a következő AZ termékváltozatokra frissül:

  • Standard –> VpnGw1AZ
  • Nagy teljesítmény –> VpnGw2AZ

A végleges kommunikációt a rendszer a migrálás bármely átjárón történő kezdeményezése előtt elküldi.

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

Nem, a VPN Gateway alapszintű termékváltozata itt marad. A VPN-átjárót az egyszerű átjáró termékváltozatával hozhatja létre a PowerShell vagy a parancssori felület használatával. A VPN Gateway Alapszintű átjáró termékváltozatai jelenleg csak az alapszintű termékváltozat nyilvános IP-címerőforrását támogatják (amely a kivonáshoz vezető úton van). Dolgozunk azon, hogy támogatást adjunk a VPN Gateway basic átjáró termékváltozatához a standard termékváltozat nyilvános IP-címerőforrásához.

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. A kompatibilis VPN-eszközök, a hozzájuk tartozó konfigurációs útmutatók vagy minták, valamint az eszközökre vonatkozó műszaki adatok listája a Tudnivalók a VPN-eszközökről című cikkben található. A listán kompatibilisként szereplő eszközcsaládokba tartozó összes eszköz működik a virtuális hálózatokkal. A VPN-eszköz konfigurálásához tekintse meg az eszközkonfigurációs mintát, vagy kövesse a megfelelő eszközcsaládhoz tartozó hivatkozást.

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

VPN-eszközök konfigurációs szkriptjeinek letöltése:

A meglévő VPN-eszköztől függően lehet, hogy letölthet egy VPN-eszközhöz kapcsolódó konfigurációs szkriptet. További információ: VPN-eszközök konfigurációs szkriptjeinek letöltése.

További konfigurációs információért lásd az alábbi hivatkozásokat:

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

Az eszközök konfigurációs mintáinak szerkesztésével kapcsolatos információkért tekintse meg a minták szerkesztésével kapcsolatos részt.

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

Az IPsec/IKE-paraméterekkel kapcsolatos információkért tekintse meg a paraméterekkel kapcsolatos részt.

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

Ez normális működés házirendalapú (más néven statikus útválasztású) VPN-átjárók esetében. Ha az alagúton keresztüli forgalom több mint 5 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 (RRAS) kiszolgálókat a helyek közötti helyek közötti konfigurációhoz.

Az egyéb szoftveres VPN-megoldások szintén működhetnek, ha megfelelnek az iparági szabványos IPsec-megvalósításoknak. A konfigurációs és támogatási útmutatáshoz vegye fel a kapcsolatot a szoftver szállítójával.

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ímének(ek)nek meg kell különböznie a helyek közötti VPN-eszköz által használt nyilvános IP-cím(ek)étől, különben a pont–hely kapcsolat nem működik. Az IKEv2-vel nem indíthatók pont–hely kapcsolatok ugyanazon nyilvános IP-cím(ek)ből, ahol a helyek közötti VPN-kapcsolat ugyanazon az Azure VPN-átjárón van konfigurálva.

Pont–hely – Tanúsítványhitelesítés

Ez a szakasz a Resource Manager-alapú üzemi modellre vonatkozik.

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

Ez az átjáró termékváltozatától függ. További információ a támogatott kapcsolatok számáról: Az átjárók termékváltozatai.

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 a tűzfalakon pont–hely képesség használatával?

Az Azure háromféle pont–hely típusú VPN-lehetőséget támogat:

  • Secure Socket Tunneling Protocol (SSTP). Az SSTP a Microsoft jogvédett, SSL-alapú megoldása, amely képes átjutni a tűzfalakon, mivel a legtöbb tűzfal nyitva hagyja az SSL által használt 443-as kimenő TCP-portot.

  • OpenVPN. Az OpenVPN egy SSL-alapú megoldás, amely képes átjutni a tűzfalakon, mivel a legtöbb tűzfal nyitva hagyja az SSL által használt 443-as kimenő TCP-portot.

  • IKEv2 VPN. Az IKEv2 VPN egy szabványalapú IPsec VPN-megoldás, amely az 500-ban és 4500-ban kimenő UDP-portot és az 50-ös IP-protokollt használja. A tűzfalak nem mindig nyitják meg ezeket a portokat, így előfordulhat, hogy az IKEv2 VPN nem képes a proxyk és tűzfalak közötti forgalomra.

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él funkció konfigurálásával támogatja az automatikus újracsatlakozást.

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

A pont–hely VPN-ek jelenleg nem támogatják a DDNS-t.

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

Igen. A Resource Manager-alapú üzemi modell esetén az átjáróhoz RouteBased (útvonalalapú) VPN-típust kell használni. A klasszikus üzemi 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 PolicyBased 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, feltéve, hogy a csatlakoztatott virtuális hálózatok nem rendelkeznek egymásnak ütköző címterekkel, vagy a hálózat az ügyféllel csatlakozik. Bár az Azure VPN-ügyfél számos VPN-kapcsolatot támogat, egy adott időpontban csak egy kapcsolat lehet aktív.

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ózatokon üzembe helyezett virtuális hálózati átjárók pont–hely típusú ügyfélkapcsolatai más társhálózatokhoz is hozzáférhetnek. A pont–hely ügyfelek csatlakozhatnak a társhálózatokhoz mindaddig, amíg a társhálózatok a UseRemoteGateway/AllowGatewayTransit funkciókat használják. További információ: Tudnivalók a pont–hely útválasztásról.

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

Az átviteli sebesség fenntartása nehéz a VPN-alagutakban. Az IPsec és az SSTP erős titkosítást használó VPN-protokoll. Az átviteli sebességet emellett a késés, valamint a helyszín és az internet közötti sávszélesség is korlátozza. A csak IKEv2 pont–hely VPN-kapcsolatokkal rendelkező VPN-átjárók esetében a várható teljes átviteli sebesség az átjáró termékváltozatától függ. Az átviteli sebességekkel kapcsolatos további információkért lásd: Az átjárók termékváltozatai.

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

Szám Az SSTP esetében csak a Windows natív VPN-ügyfele, az IKEv2 esetében pedig csak a Mac natív VPN-ügyfele használható. Az OpenVPN-ügyféllel azonban az összes platformon csatlakozhat az OpenVPN-protokollon keresztül. 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 Gateway –> Pont–hely konfiguráció lapra . Hitelesítési típus esetén válassza ki a használni kívánt hitelesítési típusokat. Vegye figyelembe, hogy a hitelesítési típus módosítása után előfordulhat, hogy az aktuális ügyfelek nem tudnak csatlakozni, amíg az egyes VPN-ügyfelek új VPN-ügyfélkonfigurációs profilt nem hoznak létre, töltöttek le és alkalmaztak.

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

Az IKEv2 Windows 10 és Server 2016 rendszeren támogatott. Ahhoz azonban, hogy az IKEv2 bizonyos operációsrendszer-verziókban használható legyen, telepítenie kell a frissítéseket, és helyileg be kell állítania egy beállításkulcs-értéket. A Windows 10 előtti operációsrendszer-verziók nem támogatottak, és csak SSTP- vagy OpenVPN-protokollt® használhatnak.

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 Server 2016 előkészítése az IKEv2 használatára:

  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 a „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload” REG_DWORD kulcsot a beállításjegyzékben, vagy állítsa az értékét 1-re.

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. Az ennél korábbi Windows-verziók forgalomválasztó korlátja 25.

A Windows forgalomválasztóinak 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 fognak csatlakozni az IKEv2-en keresztül, ha túllépik ezt a korlátot.

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 vegyes (Windows és Mac rendszerű eszközökből álló) környezetben konfigurálja, a Windows VPN-ügyfél mindig először az IKEv2-alagutat próbálja meg, de az IKEv2-kapcsolat sikertelensége esetén visszaáll az SSTP-re. A MacOSX csak IKEv2-n keresztül fog csatlakozni.

Ha az átjárón engedélyezve van az SSTP és az IKEv2 is, a pont–hely címkészlet statikusan fel lesz osztva a kettő között, így a különböző protokollokat használó ügyfelek ip-címeket kapnak mindkét altartományból. Vegye figyelembe, hogy az SSTP-ügyfelek maximális száma mindig 128, még akkor is, ha a címtartomány nagyobb, mint /24, ami nagyobb mennyiségű címet eredményez az IKEv2-ügyfelek számára. Kisebb tartományok esetén a készlet egyenlően felére csökken. Az átjáró által használt forgalomválasztók nem tartalmazhatják a CIDR pont–hely címtartományt, hanem a két altartománybeli CIDR-t.

A Windows- és Mac-eszközökön kívül mely platformokhoz támogatja még az Azure a P2S VPN-t?

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

Már rendelkezem üzembe helyezett Azure VPN-átjáróval. Engedélyezhetem rajta a RADIUS-t és/vagy az IKEv2 VPN-t?

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

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

Egy pont–hely konfiguráció eltávolítható az Azure CLI és a PowerShell használatával, a következő parancsok segítségével:

Azure PowerShell

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

Azure CLI

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

Mit tegyek, ha a tanúsítványhitelesítés használatával történő csatlakozáskor a tanúsítványeltérés nem egyezik?

Törölje a jelet a "Kiszolgáló identitásának ellenőrzése a tanúsítvány hitelesítésével" jelölőnégyzetből, vagy adja hozzá a kiszolgáló teljes tartománynevét a tanúsítványsal együtt a profil manuális létrehozásakor. Ehhez futtassa a rasphone parancsot egy parancssorból, és válassza ki a profilt a legördülő listából.

A kiszolgálóidentitás-ellenőrzés megkerülése általában nem ajánlott, de az Azure-tanúsítványhitelesítés esetén ugyanazt a tanúsítványt használják a kiszolgálóérvényesítéshez a VPN-bújtatási protokollban (IKEv2/SSTP) és az EAP protokollban. Mivel a kiszolgálótanúsítványt és az FQDN-t a VPN-bújtatási protokoll már érvényesíti, redundáns, hogy ugyanezt ismét érvényesítse az EAP-ban.

pont–hely hitelesítés

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 főtanúsítványt lehetett használni. Továbbra is 20 főtanúsítvány tölthető fel.

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

Szám

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

Használhatja a Vállalati nyilvános kulcsú infrastruktúra megoldást (belső nyilvános kulcsú infrastruktúrát), az Azure PowerShellt, a MakeCertet vagy az OpenSSL-t.

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

  • Belső/vállalati nyilvános kulcsú infrastruktúra: a lépéseket a Tanúsítványok előállítása pontban találja.

  • Azure PowerShell: a lépéseket az Azure PowerShell cikkében találja.

  • MakeCert: a lépéseket a MakeCert cikkében találja.

  • OpenSSL:

    • A tanúsítványok exportálása során ügyeljen arra, hogy a főtanúsítványt Base64 formátumba konvertálja.

    • Ügyféltanúsítvány esetén:

      • Amikor létrehozza a titkos kulcsot, 4096 bites hosszt adjon meg.
      • Amikor létrehozza a tanúsítványt, az -extensions paraméter értéke usr_cert legyen.

Pont–hely – RADIUS-hitelesítés

Ez a szakasz a Resource Manager-alapú üzemi modellre vonatkozik.

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

Ez az átjáró termékváltozatától függ. További információ a támogatott kapcsolatok számáról: Az átjárók termékváltozatai.

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 a tűzfalakon pont–hely képesség használatával?

Az Azure háromféle pont–hely típusú VPN-lehetőséget támogat:

  • Secure Socket Tunneling Protocol (SSTP). Az SSTP a Microsoft jogvédett, SSL-alapú megoldása, amely képes átjutni a tűzfalakon, mivel a legtöbb tűzfal nyitva hagyja az SSL által használt 443-as kimenő TCP-portot.

  • OpenVPN. Az OpenVPN egy SSL-alapú megoldás, amely képes átjutni a tűzfalakon, mivel a legtöbb tűzfal nyitva hagyja az SSL által használt 443-as kimenő TCP-portot.

  • IKEv2 VPN. Az IKEv2 VPN egy szabványalapú IPsec VPN-megoldás, amely az 500-ban és 4500-ban kimenő UDP-portot és az 50-ös IP-protokollt használja. A tűzfalak nem mindig nyitják meg ezeket a portokat, így előfordulhat, hogy az IKEv2 VPN nem képes a proxyk és tűzfalak közötti forgalomra.

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él funkció konfigurálásával támogatja az automatikus újracsatlakozást.

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

A pont–hely VPN-ek jelenleg nem támogatják a DDNS-t.

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

Igen. A Resource Manager-alapú üzemi modell esetén az átjáróhoz RouteBased (útvonalalapú) VPN-típust kell használni. A klasszikus üzemi 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 PolicyBased 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, feltéve, hogy a csatlakoztatott virtuális hálózatok nem rendelkeznek egymásnak ütköző címterekkel, vagy a hálózat az ügyféllel csatlakozik. Bár az Azure VPN-ügyfél számos VPN-kapcsolatot támogat, egy adott időpontban csak egy kapcsolat lehet aktív.

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ózatokon üzembe helyezett virtuális hálózati átjárók pont–hely típusú ügyfélkapcsolatai más társhálózatokhoz is hozzáférhetnek. A pont–hely ügyfelek csatlakozhatnak a társhálózatokhoz mindaddig, amíg a társhálózatok a UseRemoteGateway/AllowGatewayTransit funkciókat használják. További információ: Tudnivalók a pont–hely útválasztásról.

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

Az átviteli sebesség fenntartása nehéz a VPN-alagutakban. Az IPsec és az SSTP erős titkosítást használó VPN-protokoll. Az átviteli sebességet emellett a késés, valamint a helyszín és az internet közötti sávszélesség is korlátozza. A csak IKEv2 pont–hely VPN-kapcsolatokkal rendelkező VPN-átjárók esetében a várható teljes átviteli sebesség az átjáró termékváltozatától függ. Az átviteli sebességekkel kapcsolatos további információkért lásd: Az átjárók termékváltozatai.

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

Szám Az SSTP esetében csak a Windows natív VPN-ügyfele, az IKEv2 esetében pedig csak a Mac natív VPN-ügyfele használható. Az OpenVPN-ügyféllel azonban az összes platformon csatlakozhat az OpenVPN-protokollon keresztül. 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 Gateway –> Pont–hely konfiguráció lapra . Hitelesítési típus esetén válassza ki a használni kívánt hitelesítési típusokat. Vegye figyelembe, hogy a hitelesítési típus módosítása után előfordulhat, hogy az aktuális ügyfelek nem tudnak csatlakozni, amíg az egyes VPN-ügyfelek új VPN-ügyfélkonfigurációs profilt nem hoznak létre, töltöttek le és alkalmaztak.

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

Az IKEv2 Windows 10 és Server 2016 rendszeren támogatott. Ahhoz azonban, hogy az IKEv2 bizonyos operációsrendszer-verziókban használható legyen, telepítenie kell a frissítéseket, és helyileg be kell állítania egy beállításkulcs-értéket. A Windows 10 előtti operációsrendszer-verziók nem támogatottak, és csak SSTP- vagy OpenVPN-protokollt® használhatnak.

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 Server 2016 előkészítése az IKEv2 használatára:

  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 a „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload” REG_DWORD kulcsot a beállításjegyzékben, vagy állítsa az értékét 1-re.

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. Az ennél korábbi Windows-verziók forgalomválasztó korlátja 25.

A Windows forgalomválasztóinak 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 fognak csatlakozni az IKEv2-en keresztül, ha túllépik ezt a korlátot.

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 vegyes (Windows és Mac rendszerű eszközökből álló) környezetben konfigurálja, a Windows VPN-ügyfél mindig először az IKEv2-alagutat próbálja meg, de az IKEv2-kapcsolat sikertelensége esetén visszaáll az SSTP-re. A MacOSX csak IKEv2-n keresztül fog csatlakozni.

Ha az átjárón engedélyezve van az SSTP és az IKEv2 is, a pont–hely címkészlet statikusan fel lesz osztva a kettő között, így a különböző protokollokat használó ügyfelek ip-címeket kapnak mindkét altartományból. Vegye figyelembe, hogy az SSTP-ügyfelek maximális száma mindig 128, még akkor is, ha a címtartomány nagyobb, mint /24, ami nagyobb mennyiségű címet eredményez az IKEv2-ügyfelek számára. Kisebb tartományok esetén a készlet egyenlően felére csökken. Az átjáró által használt forgalomválasztók nem tartalmazhatják a CIDR pont–hely címtartományt, hanem a két altartománybeli CIDR-t.

A Windows- és Mac-eszközökön kívül mely platformokhoz támogatja még az Azure a P2S VPN-t?

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

Már rendelkezem üzembe helyezett Azure VPN-átjáróval. Engedélyezhetem rajta a RADIUS-t és/vagy az IKEv2 VPN-t?

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

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

Egy pont–hely konfiguráció eltávolítható az Azure CLI és a PowerShell használatával, a következő parancsok segítségével:

Azure PowerShell

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

Azure CLI

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

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.

Régebbi termékváltozatok esetén a RADIUS-hitelesítés a standard és a nagy teljesítményű termékváltozatokon támogatott. Az alapszintű átjáró termékváltozata nem támogatja.

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

Szám A RADIUS-hitelesítés a klasszikus üzemi modell esetében nem támogatott.

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

A RADIUS-kérelmek 30 másodperc után időtúllépésre vannak beállítva. A felhasználó által megadott időtúllépési értékek ma nem támogatottak.

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

Igen, a külső RADIUS-kiszolgálók támogatottak.

Milyen kapcsolati követelményei vannak annak, hogy az Azure-átjáró biztosan elérjen egy helyszíni RADIUS-kiszolgálót?

Helyek közötti VPN-kapcsolatra van szükség a helyszíni helyhez, a megfelelő útvonalakkal.

Lehetséges-e a helyszíni RADIUS-kiszolgáló felé (az Azure VPN-átjáróról) irányuló adatforgalmat egy ExpressRoute-kapcsolaton keresztül irányítani?

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

Változik a RADIUS-hitelesítés használatakor a támogatott SSTP-kapcsolatok száma? Legfeljebb hány SSTP- vagy IKEv2-kapcsolat támogatott?

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

Mi a különbség a tanúsítványhitelesítés RADIUS-kiszolgálóval történő használata és az Azure natív tanúsítványhitelesítés használata (megbízható tanúsítvány Azure-ba való feltöltésével)?

A RADIUS tanúsítványalapú hitelesítése esetén a hitelesítési kérelem egy RADIUS-kiszolgálóra lesz továbbítva, amely a tényleges tanúsítványhitelesítést végzi. 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.

Ha az Azure használatával hitelesíti a tanúsítványokat, akkor az Azure VPN-átjáró végzi a tanúsítványok ellenőrzését. Ehhez fel kell tölteni az átjáróra a tanúsítvány nyilvános kulcsát. Megadhat egy listát a visszavont tanúsítványokról is, amelyek számára nem engedélyezett a kapcsolódás.

A RADIUS-hitelesítés az IKEv2 és az SSTP VPN esetében is működik?

Igen, a RADIUS-hitelesítés az IKEv2-höz és az SSTP VPN-hez 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 kapcsolat és többhelyes kapcsolatok

A virtuális hálózatok közötti gyakori kérdések 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.

Felszámol az Azure díjat a virtuális hálózatok közötti adatforgalomé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 közötti kimenő forgalom a kimenő virtuális hálózatok közötti adatátviteli díjakat számítja fel a forrásrégiók alapján. További információt a VPN Gateway díjszabási oldalán talál. Ha VPN-átjáró helyett virtuális hálózatok közötti társviszony-létesítéssel csatlakoztatja a virtuális hálózatokat, tekintse meg a virtuális hálózatok díjszabását.

A virtuális hálózatok közötti forgalom az interneten keresztül halad?

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

Létrehozhatok virtuális hálózatok közötti kapcsolatot a Microsoft Entra-bérlők között?

Igen, az Azure 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?

Igen, IPsec/IKE-titkosítás védi.

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

Szám Az Azure Virtual Networkök összekapcsolása nem igényel VPN-eszközöket, hacsak nem szükséges a létesítmények közötti kapcsolat.

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

Szám 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 az Active Directory-bérlőhöz kell társítani?

Szám

Összekapcsolhatok egymással különböző Azure-példányokban található virtuális hálózatokat?

Szám A virtuális hálózatok közötti kapcsolat az azonos Azure-példányon belüli virtuális hálózatok csatlakoztatását támogatja. Nem hozható létre például kapcsolat a globális Azure és a kínai/német/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.

A virtuális hálózatok közötti kapcsolatot használhatom többhelyes kapcsolatokhoz?

Igen. A virtuális hálózati kapcsolat használható többhelyes virtuális VPN-ekkel együtt.

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

Tekintse meg az Átjáró követelményei táblát.

A virtuális hálózatok közötti kapcsolattal csatlakoztathatok a virtuális hálózaton kívüli virtuális gépeket vagy felhőszolgáltatásokat?

Szám A virtuális hálózatok közötti kapcsolat támogatja a virtuális hálózatok csatlakoztatá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?

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

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

Szám A virtuális hálózatok közötti és a többhelyes kapcsolatokhoz RouteBased (korábban dinamikus útválasztás) VPN-típusok használatával rendelkező Azure VPN-átjárók szükségesek.

Összekapcsolhatok egy RouteBased (útvonalapú) VPN-típussal rendelkező virtuális hálózatot egy házirendalapú VPN-típussal rendelkezővel?

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

A VPN-alagutak osztoznak a sávszélességen?

Igen. A virtuális hálózat minden VPN-alagútja az Azure VPN Gateway átjárón elérhető sávszélességet használja, és azonos VPN-átjáró üzemidőre vonatkozó SLA-t az Azure-ban.

Támogatottak a redundáns alagutak?

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

Lehetnek átfedő címterek a virtuális hálózatok közötti konfigurációkhoz?

Szám 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?

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

Hogyan engedélyezi 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-kapcsolathoz csatlakoztatott ág közötti útválasztást, be kell állítania az Azure Route Servert.

Használhatok Azure VPN Gateway átjárót az adatforgalomhoz a helyszíni helyeim között vagy egy másik virtuális hálózatba?

Resource Manager-alapú üzemi modell
Igen. További információért lásd a BGP szakaszt.

Klasszikus üzemi modell
Az Azure VPN Gateway-átjárókon keresztüli adatátvitel a klasszikus üzemi modellel lehetséges, de ez a hálózati konfigurációs fájlban statikusan meghatározott címterekre hagyatkozik. A BGP még nem támogatott az Azure Virtual Networks és a VPN-átjárók esetében a klasszikus üzemi modell használatával. BGP nélkül az átviteli címterek manuális meghatározása sok hibalehetőséggel jár, ezért nem ajánlott.

Egy adott virtuális hálózaton az Azure ugyanazt az IPsec/IKE előmegosztott kulcsot hozza létre az összes VPN-kapcsolathoz?

Nem, az Azure alapértelmezés szerint különböző előmegosztott kulcsokat hoz létre a különböző VPN-kapcsolatokhoz. A REST API-val vagy a Set VPN Gateway Key PowerShell-parancsmaggal 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 az Azure 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 tiszteli az AS Path előtagot, hogy befolyásolja a helyszíni helyekhez való több kapcsolat közötti útválasztási döntéseket?

Igen, az Azure VPN Gateway tiszteli az AS Path előtagolá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 elérési út van előnyben.

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

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

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

Igen, a pont–hely (P2S) VPN-ek több helyszíni helyhez és más virtuális hálózatokhoz csatlakozó VPN-átjárókkal is használhatók.

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 VPN-kapcsolatok együttes használata.

IPsec/Internetes kulcscsere házirendje

Minden Azure VPN-átjáróhoz tartozó termékváltozat támogatja az egyéni IPsec/IKE-házirendet?

Az egyéni IPsec/IKE-szabályzat az alapszintű termékváltozat kivételével minden Azure-termékváltozatban támogatott.

Hány házirendeket adhatok meg egy kapcsolathoz?

Egy adott kapcsolathoz csak egy házirendet adhat meg.

Megadhatok részleges házirendet egy kapcsolathoz? (például csak IKE-algoritmusokat, IPsec nélkül)

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 milyen erősségű kulcsokat támogat az egyéni házirend?

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, None
IPsec-titkosítás GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, Nincs
IPsec-integritás GCMAES256, GCMAES192, GCMAES128, SHA-256, SHA1, MD5
PFS-csoport PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, Nincs
Gyorsmódú biztonsági társítás élettartama (Nem kötelező: az alapértelmezett értékeket használja a rendszer, ha nincs megadva)
Másodperc (egész szám; min. 300/alapértelmezett érték: 27000 másodperc)
KB (egész szám; min. 1024/alapértelmezett érték: 102400000 KB)
Forgalomválasztó UsePolicyBasedTrafficSelectors** ($True/$False; Nem kötelező, alapértelmezett $False, ha nincs megadva)
DPD időtúllépés Másodperc (egész szám: min. 9/max. 3600; alapértelmezett 45 másodperc)
  • A helyszíni VPN-eszköz konfigurációjának meg kell egyezniük velük, vagy tartalmazniuk kell az alábbi, az Azure IPsec/IKE-házirendben megadott 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 a UsePolicyBasedTrafficSelectorst használja)
    • Az sa élettartamok csak helyi specifikációk, és nem kell egyeznie.
  • Ha a GCMAES-t az IPsec-titkosítási algoritmushoz használja, ugyanazt a GCMAES-algoritmust és kulcshosszt kell kiválasztania az IPsec-integritáshoz; például GCMAES128 mindkettőhöz.

  • Az Algoritmusok és kulcsok táblá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 adta meg.
  • Az IKE főmódú sa élettartama 28 800 másodpercen van rögzítve az Azure VPN-átjárókon.

  • A "UsePolicyBasedTrafficSelectors" a kapcsolat opcionális paramétere. Ha a UsePolicyBasedTrafficSelectorst úgy állítja be, hogy $True egy kapcsolaton, az az Azure VPN-átjárót úgy konfigurálja, hogy a helyszíni házirendalapú VPN-tűzfalhoz csatlakozzon. Ha engedélyezi a PolicyBasedTrafficSelectors szolgáltatást, győződjön meg arról, hogy a VPN-eszköz rendelkezik a helyszíni hálózat (helyi hálózati átjáró) előtagjainak az Azure-beli virtuális hálózati előtagok közötti és az azokból származó összes kombinációjával definiált egyező forgalomválasztókkal, ahelyett, hogy bármelyikhez. Az Azure VPN Gateway bármilyen forgalomválasztót elfogad, amelyet a távoli VPN-átjáró javasol, függetlenül attól, hogy mi van konfigurálva az Azure 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 tekintse meg Csatlakozás több helyszíni szabályzatalapú VPN-eszközt.

  • DPD időtúllépés – Az alapértelmezett érték 45 másodperc az Azure VPN-átjárókon. Ha rövidebb időszakokra állítja az időtúllépést, az IKE agresszívabb újrakulcsolását eredményezi, ami azt eredményezi, hogy egyes esetekben a kapcsolat megszakad. Ez 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 a fizikai kapcsolat állapota csomagvesztést okozhat. Az általános javaslat az időtúllépés beállítása 30–45 másodperc között.

További információ: Több helyszíni házirendalapú VPN-eszköz csatlakoztatása.

Mely Diffie-Hellman csoportok támogatottak?

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
0 DHGroup1 PFS1 768 bites MODP
2 DHGroup2 PFS2 1024 bites 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 részletekért lásd: RFC3526 és RFC5114.

Az egyéni házrend helyettesíti az alapértelmezett IPsec/IKE-házirendet az Azure VPN-átjárókon?

Igen. Miután megadott egy egyéni házirendet egy kapcsolathoz, az Azure VPN-átjáró csak a kapcsolat házirendjét használja, 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, a kapcsolatot továbbra is védi az IPsec/IKE. Miután eltávolítja a kapcsolat egyéni házirendjét, az Azure 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 okozhat rövid (néhány másodperces) megszakítást, mivel az Azure VPN-átjáró bontja a meglévő kapcsolatot, és újraindítja az IKE-kézfogást, így újra létrehozza az IPsec-alagutat az új titkosítási algoritmusokkal és paraméterekkel. Győződjön meg róla, hogy a helyszíni VPN-eszközt is konfigurálta ugyanazokkal az algoritmusokkal és kulcserősségekkel, így minimálisra csökkentheti a megszakítások időtartamát.

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

Igen. Az egyéni házirendeket kapcsolatonként hozza létre. 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 házirendet a virtuális hálózatok közötti kapcsolatokhoz is?

Igen, mind az IPsec létesítmények közötti kapcsolataihoz, mind a virtuális hálózatok közötti kapcsolatokhoz alkalmazhat egyéni házirendet.

Ugyanazt a házirendet kell megadnom mindkét, virtuális hálózatok közötti kapcsolat erőforrásaihoz?

Igen. A virtuális hálózatok közötti alagút két kapcsolati erőforrásból áll az Azure-ban, amelyek a két különböző irányba mutatnak. Győződjön meg róla, hogy mindkét kapcsolati erőforrás azonos házirenddel rendelkezik, ellenkező esetben a virtuális hálózatok 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 DPD-időtúllépést?

Az alapértelmezett DPD-időtúllépés 45 másodperc. Minden IPsec- vagy VNet–VNet-kapcsolaton megadhat egy másik DPD-időtúllépési értéket 9 másodperctől 3600 másodpercig.

Feljegyzés

Az alapértelmezett érték 45 másodperc az Azure VPN-átjárókon. Ha rövidebb időszakokra állítja az időtúllépést, az IKE agresszívabb újrakulcsolását eredményezi, ami azt eredményezi, hogy egyes esetekben a kapcsolat megszakad. Ez 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. Az általános javaslat az időtúllépés beállítása 30 és 45 másodperc között.

Működik az egyéni IPsec/IKE-házirend az ExpressRoute-kapcsolatokkal?

Szám Az IPsec/IKE-házirend csak az S2S VPN- és a virtuális hálózatok közötti kapcsolatokkal, az Azure VPN-átjárókon keresztül működik.

Hogyan IKEv1 vagy IKEv2 protokolltípussal hoz létre kapcsolatokat?

Az IKEv1-kapcsolatok az összes RouteBased VPN-típusú termékváltozaton létrehozhatók, kivéve az alapszintű termékváltozatot, a standard termékváltozatot és az egyéb örökölt 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 a PowerShell-parancsmag dokumentációját. Az SKU-típusok és az IKEv1/IKEv2 támogatásáról lásd Csatlakozás házirendalapú VPN-eszközök átjáróit.

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

Igen. Az IKEv1 és az IKEv2 kapcsolatok közötti átvitel támogatott.

Rendelkezhetek IKEv1 helyek közötti kapcsolatokkal a RouteBased VPN-típus alapszintű termékváltozataihoz?

Szám Az alapszintű termékváltozat ezt nem támogatja.

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

Szám A kapcsolat létrehozása után az IKEv1/IKEv2 protokollok nem módosíthatók. 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, annak valószínűleg az az oka, hogy 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ő módú egyeztetés időtúllépési értéke határozza meg az újrakulcsok 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álhatók a konfigurációs információk és a lépések?

További információkért és konfigurációs lépésekért 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 (autonóm rendszerszámokat) használhatok?

Saját nyilvános ASN-eket vagy privát ASN-eket használhat mind a helyhez kötött hálózatokhoz, mind az Azure virtuális hálózatokhoz. Az Azure vagy az IANA által fenntartott tartományok nem használhatók.

A következő ASN-eket az Azure vagy az IANA fenntartja:

  • Az Azure által fenntartott ASN-ek:

    • Nyilvános ASN-ek: 8074, 8075, 12076
    • Privát ASN-ek: 65515, 65517, 65518, 65519, 65520
  • Az IANA által fenntartott ASN-k:

    • 23456, 64496–64511, 65535–65551 és 429496729

Az Azure VPN-átjárókhoz való csatlakozáskor nem adhatja meg ezeket az ASN-eket a helyszíni VPN-eszközökhöz.

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

Igen, a 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 a 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

Ezeket az ASN-eket az IANA vagy az Azure nem használja, ezért az Azure VPN-átjáróhoz rendelhető.

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

A VPN Gateway alapértelmezés szerint egyetlen IP-címet foglal le a GatewaySubnet tartományból az aktív-készenléti VPN-átjárókhoz, 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 tényleges BGP IP-címet lekérheti a PowerShell használatával vagy az Azure Portalon való helymegálításával. 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 APIPA IP-címeket (169.254.x.x) használnak BGP IP-címként, meg kell adnia egy vagy több Azure APIPA BGP IP-címet az Azure 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.

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ózati 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 APIPA-címet használ a BGP-hez, egy vagy több APIPA BGP IP-címet kell megadnia az Azure VPN-átjárón, a BGP konfigurálása című szakaszban 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. Ha BGP-t használ egy kapcsolathoz, hagyja üresen a Címtartomány mezőt a megfelelő helyi hálózati átjáró erőforrásához. 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őben. Redundáns, és ha egy APIPA-címet használ a helyszíni VPN-eszköz BGP IP-címeként, az nem adható 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, 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, ha a BGP-vel összekapcsolja őket. 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 ajánlanak majd az Azure VPN Gatewayek?

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

  • A virtuális hálózati címelőtagok.
  • Címelőtagok az Azure VPN-átjáróhoz csatlakoztatott minden helyi hálózati átjáróhoz.
  • Az Azure 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 a virtuális hálózati előtagokkal.

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

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

Meghirdethetem az Azure VPN Gateway átjárókhoz vezető alapértelmezett útvonalat (0.0.0.0/0)?

Igen. Vegye figyelembe, hogy ez az összes virtuális hálózati kimenő forgalmat a helyszíni hely felé kényszeríti. Azt is megakadályozza, hogy a virtuális hálózati virtuális gépek közvetlenül fogadják el a nyilvános kommunikációt az internetről, például az RDP-t vagy az SSH-t az internetről a virtuális gépekre.

Meghirdethetem a pontos előtagokat a virtuális hálózati előtagokként?

Nem, a virtuális hálózati címelőtagok előtagjainak hirdetését az Azure letiltja vagy szűri. Meghirdethet azonban egy olyan előtagot, amely a virtuális hálózaton belül találhatóak szuperhalmaza.

Ha például a virtuális hálózat a 10.0.0.0/16 címteret használta, meghirdetheti a 10.0.0.0/8 címet. A 10.0.0.0/16-os vagy a 10.0.0.0/24-et azonban nem hirdetheti meg.

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-átvitel útválasztása támogatott, azzal a kivétellel, hogy az Azure VPN-átjárók nem hirdetik meg az alapértelmezett útvonalakat más BGP-társokkal. Ha több Azure VPN-átjárón keresztül szeretné engedélyezni az átvitelt, 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.

Rendelkezhetek egynél több alagutat egy Azure VPN-átjáró és a helyszíni hálózatom között?

Igen, több helyek közötti (S2S) VPN-alagutat is létrehozhat egy Azure VPN-átjáró és a helyszíni hálózat között. Vegye figyelembe, hogy ezek az alagutak az Azure VPN-átjárók alagútjainak teljes számával vannak számolva, és mindkét alagúton engedélyeznie kell a BGP-t.

Ha például két redundáns alagúttal rendelkezik az Azure VPN Gateway és az egyik helyszíni hálózat között, az Azure VPN Gateway teljes kvótáján kívül 2 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 a virtuális hálózati átjárók legalább egyikének aktív-aktív konfigurációban kell lennie.

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

Igen.

Mit kell felvennem a helyszíni VPN-eszközön a BGP társviszony-munkamenethez?

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. Ha például az Azure VPN-társ IP-címe 10.12.255.30, akkor a 10.12.255.30-hoz hozzáad egy gazdagépútvonalat a VPN-eszköz megfelelő IPsec-alagútfelületének következő ugrásos felületével.

Támogatja a virtuális hálózati átjáró a BFD-t a BGP-vel létesített S2S-kapcsolatokhoz?

Szám A kétirányú továbbításészlelés (BFD) egy protokoll, amellyel a BGP-vel gyorsabban észlelheti a szomszéd állásidőt, mint a szokásos BGP "keepalives" használatával. A BFD olyan alszekundumos időzítőket használ, amelyeket LAN-környezetekben való munkavégzésre terveztek, de a nyilvános interneten vagy a széles körű hálózati kapcsolatokon 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 az útvonalak BGP általi csillapítását okozhatja. Másik lehetőségként konfigurálhatja a helyszíni eszközt az alapértelmezettnél alacsonyabb időzítőkkel, a 60 másodperces "keepalive" intervallummal és a 180 másodperces visszatartási időzítővel. Ez gyorsabb konvergenciát eredményez. Az alapértelmezett 60 másodperces "keepalive" intervallum vagy az alapértelmezett 180 másodperces visszatartási időzítő alatti időzítők azonban nem megbízhatóak. Javasoljuk, hogy az időzítőket az alapértelmezett értékeknél vagy annál magasabb értéken tartsa.

Az Azure VPN-átjárók kezdeményeznek BGP-társviszony-munkameneteket vagy kapcsolatokat?

Az átjáró A BGP társviszony-létesítési munkameneteket kezdeményez a helyi hálózati átjáró erőforrásaiban megadott helyszíni BGP társ IP-címekhez a VPN-átjárók magánhálózati IP-címeivel. Ez függetlenül attól, hogy a helyszíni BGP IP-címek az APIPA-tartományban vagy a normál magánhálózati IP-címekben találhatók-e. 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 bújtatá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~5 és a VpnGw2AZ~5AZ rendszeren támogatott.

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

Szám

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álhatom a /-t NAT-szabálynévben?

Szám Hibaüzenet jelenik meg.

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

A NAT a NAT-szabályokkal való 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 a NAT-val és más kapcsolatokkal is rendelkezhet, anélkül, hogy a NAT működjön együtt.

Milyen típusú NAT támogatott az Azure VPN-átjárókon?

Csak a statikus 1:1 NAT és a dinamikus NAT támogatott. A NAT64 nem támogatott.

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ója" mezőben.

A NAT működik BGP-kapcsolatokkal?

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

  • A NAT-szabályok konfigurációs lapján válassza a BGP-útvonalfordítás engedélyezése lehetőséget, hogy a tanult útvonalak és a meghirdetett útvonalak nat utáni címelőtagokra (külső leképezések) legyenek lefordítva a kapcsolatokhoz társított NAT-szabályok alapján. Győződjön meg arról, hogy a helyszíni BGP-útválasztók az IngressSNAT-szabályokban meghatározott pontos előtagokat hirdetik.

  • Ha a helyszíni VPN-útválasztó normál, nem APIPA-címet használ, és ütközik a virtuális hálózati címtérrel 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, és a NAT utáni címet a helyi hálózati átjáró BGP társ IP-cím mezőjébe helyezi.

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

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

Szám Egyetlen 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 az Azure VPN Gatewaybe é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 az Azure VPN-átjárót helyszíni hálózatokra elhagyó virtuális hálózati forrás IP-címek fordítását. Emellett kezeli a virtuális hálózatba érkező csomagok cél IP-címeinek fordítását is az EgressSNAT-szabvánnyal létesített kapcsolatokon keresztül.

  • Mindkét esetben nincs szükség DNST-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? Mindegyikre alkalmazhatok NAT-t? Vagy csak egy részhalmazt?

Minden nat előtaghoz létre kell hoznia egy NAT-szabályt, mert 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, két szabályt hozhat létre az alábbiak szerint:

  • IngressSNAT szabály 1: Térkép 10.0.1.0/24-100.0.1.0/24
  • IngressSNAT szabály 2: Térkép 10.0.2.0/25-100.0.2.0/25

A két szabálynak meg kell egyeznie a megfelelő címelőtagok előtaghosszával. Ugyanez vonatkozik a virtuális hálózati címtér EgressSNAT-szabályaira is.

Fontos

Ha csak egy szabályt csatol a fenti 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ímet 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 különböző előtagokra való fordításához különböző helyszíni hálózatokra?

Igen, több EgressSNAT-szabályt is létrehozhat ugyanahhoz a virtuális hálózat címteréhez, és 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, ezt általában akkor használják, ha a kapcsolatok ugyanazon helyszíni hálózathoz tartoznak a redundancia biztosításához. 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ő forgalomra egy NAT-kapcsolaton?

Bejövő és kimenő szabályokra is szükség van ugyanazon a kapcsolaton, ha a helyszíni hálózati címtér átfedésben van a virtuális hálózati címtérrel. Ha a virtuális hálózati címtér minden csatlakoztatott hálózatban egyedi, akkor 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" IPconfigurationhoz lesz rendelve, a másodlagos IP-cím pedig az "activeActive" IPconfigurationhoz 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?

Több lehetősége van. 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 azt a magánhálózati IP-címet és a portot, amelyhez csatlakozni szeretne (a portszám általában 3389). a virtuális gép portját pedig konfigurálnia kell az adatátvitelhez.

A magánhálózati IP-címmel egy, a virtuális hálózaton található másik virtuális gépről is csatlakoztathat a virtuális géphez. 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 magánhálózati 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?

Szám Csak az az adatforgalom fog áthaladni a virtuális hálózati átjárón, amely a virtuális hálózat Ön által meghatározott 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ímmel rendelkező adatforgalom a virtuális hálózaton belül marad. Az egyéb adatforgalom a terheléselosztón keresztül a nyilvános hálózatok felé lesz irányítva, vagy ha kényszerített bújtatást használ, akkor az Azure VPN Gatewayen megy keresztül.

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 tud csatlakozni a virtuális géphez a magánhálózati IP-címmel, de a számítógép nevével nem, ellenőrizze, hogy a DNS-konfiguráció megfelelő-e. A virtuális gépek névfeloldásának működésével kapcsolatos további információkért lásd a virtuális gépek névfeloldásával foglakozó cikket.

Ha pont–hely kapcsolattal csatlakozik, ellenőrizze az alábbi elemeket is:

  • Az "ipconfig" használatával ellenőrizze az Ethernet-adapterhez rendelt IPv4-címet azon a számítógépen, amelyhez csatlakozik. Ha az IP-cím azon virtuális hálózat címtartományán belül van, amelyhez csatlakozik, vagy a VPNClientAddressPool címtartományán belül van, akkor ezt átfedésben lévő címtérnek nevezzük. Ilyen átfedés esetén a hálózati forgalom nem éri el az Azure-t, és a helyi hálózaton marad.
  • Ellenőrizze, hogy a VPN-ügyfél konfigurációs csomagja a DNS-kiszolgáló IP-címeinek megadása után jött-e létre a virtuális hálózathoz. 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ával kapcsolatos további információkért lásd a virtuális gép távoli asztali kapcsolatainak hibaelhárításával foglalkozó cikket.

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

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

A Hálózati átjárók hatóköre a hálózati szolgáltatások átjáróerőforrásait tartalmazza. A Hálózati átjárók hatókörében négy típusú erőforrás található:

  • 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) a Virtual WAN szolgáltatásban.
  • ExpressRoute-átjáró a Virtual WAN szolgáltatásban.

Melyik karbantartást támogatja vagy nem támogatja 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álta az erőforrások karbantartási időszakát, a vendég operációs rendszer és a szolgáltatás karbantartása az adott időszakban történik. A gazdagépfrissítések a gazdagépfrissítéseken (TOR, Power stb.) és a kritikus biztonsági frissítéseken túl nem tartoznak az ügyfél által ellenőrzött karbantartás hatálya alá.

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

Jelenleg a speciális értesítés nem engedélyezhető a Network Gateway-erőforrások karbantartásához.

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

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

Konfigurálhatok a napi ütemezéstől eltérő karbantartási időszakot?

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 ellenőrzött 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. Egyes más típusú frissítések, például a gazdagépfrissítések, nem tartoznak az ügyfél által ellenőrzött karbantartás hatókörébe.

Emellett, ha egy nagy súlyosságú biztonsági probléma veszélyeztetheti az ügyfeleinket, 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 olyan ritka előfordulások, amelyek csak szélsőséges esetekben használhatók.

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 összes átjáró termékváltozata (kivéve a VPN Gateway alapszintű termékváltozatát) konfigurálható az ügyfél által vezérelt karbantartás használatára.

Mennyi ideig tart, amíg a karbantartási konfigurációs szabályzat érvénybe lép, miután hozzárendelték az átjáró-erőforráshoz?

A hálózati átjárók akár 24 órát is igénybe vehetnek, ha a karbantartási szabályzat az átjáró-erőforráshoz van társítva.

Vannak korlátozások 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 egyszerű termékváltozat nyilvános IP-címét használó átjáróerőforrások csak az ügyfél által ellenőrzött karbantartási ütemezést követve kaphatnak 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 az erőforrások 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 az egyik erőforrásom jövőbeli dátumára. Addig szünetelteti a karbantartási tevékenységeket ezen az erőforráson?

Nem, a karbantartási tevékenységek nem lesznek felfüggesztve 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ókért lásd a VPN Gateway ügyfél által vezérelt átjárók karbantartási cikkét.

Következő lépések

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