Miért szakítja meg a kapcsolatot egy Azure VPN-előtag hozzáadása

A rossz Azure-objektumhoz hozzáadott előtag olyan kapcsolatot hoz létre, amely Connected állapotot jelent, és semmit nem továbbít, és ez a legdrágább hibatípus ebben a veremben. Három erőforrás érintett, és közülük csak egy birtokolja a távoli címteret: a virtuális hálózati átjáró, a távoli oldalt leíró helyi hálózati átjáró és az őket összekötő kapcsolat. Az előtag a helyi hálózati átjáróhoz tartozik, a kapcsolatot újra kell építeni, hogy a változás érvénybe lépjen, maga az átjáró pedig általában érintetlen marad. A sorrend nem tárgyalható, és a portál csak egy részét mutatja.

Három objektum, amelyek közül egy tartja az előtagot

A virtuális hálózat címtere más kérdésre válaszol: mi él az Azure-on belül. Egy távoli előtag hozzáadása ott nem irányítja oda a forgalmat, csak kiszélesíti azt a teret, amelyet a platform a sajátjának hisz, és ez ütközhet a valódi távoli tartománnyal. A helyi hálózati átjáró az az objektum, amely a távoli előtagokat tartja, a kapcsolat pedig mindkét átjáróra hivatkozik, plusz egy előre megosztott kulcsra.

Van egy harmadik fenntartás is, amit érdemes szem előtt tartani. GatewaySubnet ad otthont a felügyelt átjárópéldányoknak, pontosan ezt a nevet kell viselnie, és a nem Basic SKU-k esetében elvárás, hogy legalább /27 legyen.

Semmi más nem tartozik abba az alhálózatba, és az előtagváltozásnak nincs oka megérinteni. A helyi hálózati átjáróból hiányzó előtag elérhetetlen, bármit is mond a kapcsolat állapota, mert az átjáró csak azokat az előtagokat kínálja, amelyekről az alagút egyeztetésekor tájékoztatták. Ezért a tünet aszimmetrikus: az alagút fent van, a biztonsági társítás rendben van, és egy alhálózat soha nem jelenik meg a forgalomválasztókban. Ha egyetlen távoli tartomány hiányzik, miközben a szomszédai működnek, hagyja abba az alagút nézését, és olvassa el a helyi hálózati átjárót.

Miért éppen a kapcsolatot távolítják el

A kapcsolatobjektum az egyeztetett konfigurációt rögzíti a teljes élettartamára. Ezért a dokumentált eljárás először eltávolítja a kapcsolatot, frissíti a helyi hálózati átjárót, majd újra létrehozza a kapcsolatot ugyanazzal a megosztott kulccsal. Az átjárópéldányok nem épülnek újra egy csak előtagot érintő változás miatt, ami a kiesést a kapcsolat lebontására korlátozza az átjáró újratelepítése helyett.

Ez a törlés maga a kiesés, ezért kezelje tervezett változásként kezdettel és várható véggel, nem gyors szerkesztésként. PowerShellben a sorrend rövid: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, majd Set-AzLocalNetworkGateway az új -AddressPrefix tömbbel, majd New-AzVirtualNetworkGatewayConnection ugyanazzal a -SharedKey és ugyanazokkal az átjárókkal. A kulcs újrafelhasználása fontos, mert a távoli oldalt nem konfigurálják újra, és egy új kulcs egyeztetést jelent a távoli eszköz tulajdonosával. Ha egy másik csapat üzemelteti azt az eszközt, egyeztessen velük az időablakról, mielőtt bármit eltávolít.

Mikor kell magát az átjárót újraépíteni

Egy második válasz, amely e probléma körül kering, azt mondja, hogy az átjárót újra kell létrehozni, és a kulcsot újra ki kell cserélni. Ez más műveletcsoportra igaz: az átjáró típusának vagy SKU-jának módosítása, a pont-pont és hely-hely közötti váltás, vagy egy olyan átjáró javítása, amelynek a saját konfigurációja hibás. Az ilyen változtatások valóban módosítják az átjáró erőforrását, ezért az újraépítés valóban szükséges.

A pont-pont célra létrehozott átjárónak nem adható egyszerűen hely-hely kapcsolat. A pont-pont konfigurációt el kell távolítani, és az átjárót újra kell létrehozni, ami új megosztott kulcsot és új ügyfélcsomagot is eredményez.

A pont-pont csomag saját megjegyzést érdemel, mert lejár. A portál rövid élettartamú fájlt állít elő, ezért a gyakorlati megközelítés az, hogy egyszer letölti, és az ügyféltanúsítvánnyal együtt terjeszti, ahelyett hogy a felhasználóknak egy portállinket küldene, amely halott lesz, mire kattintanak. Az előtag kérdésére ezek egyike sem vonatkozik. A két eljárás szétválasztása az egész fegyelem: az előtagok kapcsolatszintű változás, az átjáró tulajdonságai pedig átjárószintű változás.

Az állapotot olvassa, ne a portál jelvényét

Az állapotot az erőforrásból olvassa, ne a portál jelvényéből. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 ad vissza ConnectionStatus a bejövő és kimenő bájt számlálókkal együtt, és a számlálók azok, amelyek elválasztják a csatlakoztatott, de semmit nem szállító alagutat attól, amely soha nem jött létre.

A számlálók, amelyek egy átvitel közepén abbahagyják a növekedést, az útvonalra mutatnak, nem a hitelesítésre. A számlálók, amelyek egyáltalán nem mozdulnak, az előtagkészletre vagy a megosztott kulcsra mutatnak.

Az időzítők a megszakadások egy osztályát magyarázzák, amelyeket tévesen a VPN-nek tulajdonítanak. Az Azure terheléselosztója a beállított időkorlát után lezárja az inaktív folyamokat, alapértelmezés szerint négy perc, amikor ezeket a jegyzeteket írták, és felfelé konfigurálható, ezért egy keepalive nélküli VM-en futó OpenVPN-kiszolgáló néhány percenként elszakadhat, miközben minden más egészségesnek tűnik. Egy átjáró, amelyet a platform ciklikusan újraindít, szintén megszakíthatja a VNet kapcsolatot egy Web App-pal, és ez a hiba a platform oldalán van, nem egy ügyfélkonfigurációban. Az ismertetőjel az, hogy a megszakadás fix intervallumot követ-e, vagy az Ön által tett változtatást.

Tartsa a három objektumot és értékeiket egy rekordban: a virtuális hálózat címterét, a helyi hálózati átjáró előtaglistáját és a kapcsolat megosztott kulcsára való hivatkozást. hely-hely PowerShell-cikk dokumentálja a helyi hálózati átjáró parancsait és a sorrendet, amelybe tartoznak. Az előtagváltozás emlékezethez való hasonlítása az, ahogy egy működő alagutat kétszer újraépítenek.

Ezután abban a sorrendben ellenőrizze, ahogy módosított: a helyi hálózati átjáró megjeleníti az új előtaglistát, a kapcsolat ismét Connected, és a számlálók mozognak, amikor forgalmat küld az új tartomány egyik gazdagépére. Ha a harmadik lépés sikertelen, miközben az első kettő átmegy, a távoli oldal nem fogadta el az új forgalomválasztót, és a távoli eszköznek szüksége van a megfelelő 2. fázisú bejegyzésre. Ez beszélgetés az alagút másik végével, nem újabb változtatás az Azure-ban.