Per què afegir un prefix d'Azure VPN fa caure la connexió

Un prefix afegit a l'objecte d'Azure equivocat produeix una connexió que informa de Connected i no reenvia res, que és el tipus d'error més car d'aquesta pila. Hi intervenen tres recursos i només un d'ells posseeix l'espai d'adreces remot: la passarel·la de xarxa virtual, la passarel·la de xarxa local que descriu el costat llunyà i la connexió que les uneix. El prefix pertany a la passarel·la de xarxa local, la connexió s'ha de reconstruir perquè el canvi tingui efecte, i la passarel·la mateixa normalment es deixa intacta. L'ordre no és negociable, i el portal només en mostra una part.

Tres objectes, un dels quals conté el prefix

L'espai d'adreces de la xarxa virtual respon una pregunta diferent: què viu dins d'Azure. Afegir-hi un prefix remot no hi encamina el trànsit, només amplia l'espai que la plataforma creu que posseeix, cosa que pot xocar amb el rang remot real. La passarel·la de xarxa local és l'objecte que conté els prefixos remots, i la connexió fa referència a les dues passarel·les més una clau compartida prèviament.

Hi ha una tercera reserva que cal tenir present. GatewaySubnet allotja les instàncies gestionades de la passarel·la, ha de dur exactament aquest nom, i per a SKU que no són Basic s'espera que sigui com a mínim /27.

Cap altra cosa no pertany a aquesta subxarxa, i un canvi de prefix no té cap motiu per tocar-la. Un prefix que falta a la passarel·la de xarxa local és inabastable faci el que faci l'estat de la connexió, perquè la passarel·la només ofereix els prefixos que se li han indicat quan negocia el túnel. Per això el símptoma és asimètric: el túnel està aixecat, l'associació de seguretat és correcta i una subxarxa no apareix mai als selectors de trànsit. Si falta un sol rang remot mentre els veïns funcionen, deixeu de mirar el túnel i llegiu la passarel·la de xarxa local.

Per què el que s'elimina és la connexió

L'objecte de connexió fixa la configuració negociada durant tota la seva vida. Per això el procediment documentat elimina primer la connexió, actualitza la passarel·la de xarxa local i després recrea la connexió amb la mateixa clau compartida. Les instàncies de passarel·la no es reconstrueixen per a un canvi només de prefix, cosa que limita la interrupció a l'enderrocament de la connexió en lloc d'un redesplegament de la passarel·la.

Aquesta eliminació és la interrupció, així que tracteu-la com un canvi planificat amb un inici i un final esperat en lloc d'una edició ràpida. A PowerShell la seqüència és curta: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, després Set-AzLocalNetworkGateway amb el nou -AddressPrefix matriu, després New-AzVirtualNetworkGatewayConnection amb la mateixa -SharedKey i les mateixes passarel·les. Reutilitzar la clau és important, perquè el costat llunyà no es reconfigura i una clau nova vol dir coordinar-se amb qui posseeix el dispositiu remot. Si un altre equip gestiona aquest dispositiu, acordeu la finestra amb ells abans de treure res.

Quan cal reconstruir la passarel·la mateixa

Una segona resposta que circula sobre aquest problema diu que cal recrear la passarel·la i tornar a intercanviar la clau. Això és correcte per a un altre conjunt d'operacions: canviar el tipus de passarel·la o l'SKU, passar entre punt a lloc i lloc a lloc, o reparar una passarel·la la configuració de la qual és incorrecta. Aquests canvis sí que alteren el recurs de passarel·la, així que la reconstrucció és realment necessària.

Una passarel·la creada per a punt a lloc no pot rebre simplement una connexió lloc a lloc. Cal eliminar la configuració de punt a lloc i recrear la passarel·la, cosa que també produeix una clau compartida nova i un paquet de client nou.

El paquet de punt a lloc mereix una nota pròpia perquè caduca. El portal genera un fitxer de vida curta, així que l'enfocament pràctic és baixar-lo un cop i distribuir-lo juntament amb el certificat de client en lloc d'enviar als usuaris un enllaç del portal que serà mort quan el cliquin. Per a la qüestió del prefix, res d'això no s'aplica. Mantenir els dos procediments separats és tota la disciplina: els prefixos són un canvi a nivell de connexió, i les propietats de la passarel·la són un canvi a nivell de passarel·la.

Llegiu l'estat, no la insígnia del portal

Llegiu l'estat del recurs en lloc de la insígnia del portal. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 retorna ConnectionStatus juntament amb comptadors de bytes d'entrada i sortida, i són els comptadors el que separa un túnel connectat que no transporta res d'un que mai no s'ha establert.

Els comptadors que deixen d'augmentar a mitjan transferència apunten al camí i no a l'autenticació. Els comptadors que no es mouen gens apunten al conjunt de prefixos o a la clau compartida.

Els temporitzadors expliquen una classe de desconnexions que s'atribueixen erròniament a la VPN. El balancejador de càrrega d'Azure tanca els fluxos inactius després del seu temps d'espera configurat, quatre minuts per defecte quan es van escriure aquestes notes i configurable a l'alça, així que un servidor OpenVPN en una VM sense keepalive pot caure cada pocs minuts mentre tota la resta sembla sana. Una passarel·la que la plataforma va reiniciant també pot interrompre una connexió VNet amb una Web App, i aquesta fallada és al costat de la plataforma i no en una configuració de client. La pista és si la desconnexió segueix un interval fix o un canvi que heu fet.

Manteniu els tres objectes i els seus valors en un sol registre: l'espai d'adreces de la xarxa virtual, la llista de prefixos de la passarel·la de xarxa local i la referència a la clau compartida de la connexió. article de PowerShell de lloc a lloc documenta les ordres de la passarel·la de xarxa local i l'ordre que els correspon. Comparar un canvi de prefix amb la memòria és com es reconstrueix dues vegades un túnel que funciona.

Després verifiqueu en l'ordre en què heu canviat: la passarel·la de xarxa local mostra la llista nova de prefixos, la connexió torna a estar Connected i els comptadors es mouen quan envieu trànsit a un amfitrió del rang nou. Si el tercer pas falla mentre els dos primers passen, el costat llunyà no ha acceptat el selector de trànsit nou i el dispositiu remot necessita l'entrada de fase 2 corresponent. Això és una conversa amb l'altre extrem del túnel, no un altre canvi a Azure.