Kial aldono de Azure VPN-prefikso rompas la konekton

Prefikso aldonita al la malĝusta Azure-objekto produktas konekton, kiu raportas Connected kaj plusendas nenion, kaj tio estas la plej multekosta speco de eraro en ĉi tiu stako. Tri rimedoj estas implikitaj kaj nur unu el ili posedas la foran adresaron: la pordego de la virtuala reto, la loka retpordego, kiu priskribas la foran flankon, kaj la konekto, kiu ilin kunigas. La prefikso apartenas al la loka retpordego, la konekto devas esti rekonstruita por ke la ŝanĝo efiku, kaj la pordego mem kutime restas netuŝita. La ordo ne estas diskutebla, kaj la portalo montras nur parton de ĝi.

Tri objektoj, el kiuj unu tenas la prefikson

La adresaro de la virtuala reto respondas al alia demando: kio loĝas ene de Azure. Aldoni foran prefikson tie ne enkursigas trafikon al ĝi, ĝi nur vastigas la spacon, kiun la platformo kredas posedi, kio povas kolizii kun la reala fora gamo. La loka retpordego estas la objekto, kiu tenas la forajn prefiksojn, kaj la konekto referencas ambaŭ pordegojn plus antaŭe kunhavatan ŝlosilon.

Estas tria rezervado, kiun oni devas memori. GatewaySubnet gastigas la administratajn pordegajn instancojn, devas porti ĝuste tiun nomon, kaj por ne-Basic SKU-oj oni atendas, ke ĝi estu almenaŭ /27.

Nenio alia apartenas al tiu subreto, kaj prefiksa ŝanĝo havas neniun kialon tuŝi ĝin. Prefikso mankanta en la loka retpordego estas atingebla per nenio, kion ajn diras la konekta stato, ĉar la pordego proponas nur la prefiksojn, pri kiuj ĝi estis informita kiam ĝi intertraktas la tunelon. Tial la simptomo estas nesimetria: la tunelo estas supren, la sekureca asocio estas en ordo, kaj unu subreto neniam aperas en la trafikaj selektiloj. Se unu fora gamo mankas dum ĝiaj najbaroj funkcias, ĉesu rigardi la tunelon kaj legu la lokan retpordegon.

Kial ĝuste la konekto estas forigata

La konekta objekto fiksas la intertraktitan agordon por sia tuta vivodaŭro. Pro tio la dokumentita proceduro unue forigas la konekton, ĝisdatigas la lokan retpordegon kaj poste rekreas la konekton kun la sama kunhavata ŝlosilo. La pordegaj instancoj ne estas rekonstruitaj por ŝanĝo nur de prefikso, kio limigas la interrompon al la malkonstruo de la konekto anstataŭ al rea deplojo de la pordego.

Tiu forigo estas la interrompo, do traktu ĝin kiel planitan ŝanĝon kun komenco kaj atendata fino anstataŭ kiel rapidan redakton. En PowerShell la sinsekvo estas mallonga: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, poste Set-AzLocalNetworkGateway kun la nova -AddressPrefix tabelo, poste New-AzVirtualNetworkGatewayConnection kun la sama -SharedKey kaj la samaj pordegoj. Reuzi la ŝlosilon gravas, ĉar la fora flanko ne estas reagordata kaj nova ŝlosilo signifas kunordigon kun tiu, kiu posedas la foran aparaton. Se alia teamo funkciigas tiun aparaton, interkonsentu la fenestron kun ili antaŭ ol forigi ion ajn.

Kiam la pordego mem devas esti rekonstruita

Dua respondo cirkulanta ĉirkaŭ ĉi tiu problemo diras, ke la pordego devas esti rekrea kaj la ŝlosilo reinterŝanĝita. Tio validas por malsama aro de operacioj: ŝanĝo de la pordega tipo aŭ SKU, transiro inter point-to-site kaj site-to-site, aŭ riparo de pordego, kies propra agordo estas malĝusta. Tiaj ŝanĝoj ja modifas la pordegan rimedon, do rekonstruo estas vere necesa.

Pordego kreita por point-to-site ne povas simple ricevi site-to-site-konekton. La point-to-site-agordo devas esti forigita kaj la pordego rekrea, kio ankaŭ produktas novan kunhavatan ŝlosilon kaj novan klientan pakaĵon.

La point-to-site-pakaĵo meritas propran noton, ĉar ĝi eksvalidiĝas. La portalo generas dosieron kun mallonga vivodaŭro, do la praktika aliro estas elŝuti ĝin unufoje kaj disdoni ĝin kune kun la klienta atestilo anstataŭ sendi al uzantoj portalan ligilon, kiu estos morta ĝis ili klakos ĝin. Por la prefiksa demando, nenio el tio validas. Teni la du procedurojn apartaj estas la tuta disciplino: prefiksoj estas ŝanĝo je konekta nivelo, kaj pordegaj ecoj estas ŝanĝo je pordega nivelo.

Legu la staton, ne la portalon insignon

Legu la staton el la rimedo anstataŭ el la insigno en la portalo. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 redonas ConnectionStatus kune kun eniraj kaj eliraj bajtaj nombriloj, kaj la nombriloj estas tio, kio apartigas tunelon, kiu estas konektita kaj portas nenion, de unu, kiu neniam establiĝis.

Nombriloj, kiuj ĉesas kreski meze de transdono, montras la vojon anstataŭ la aŭtentikigon. Nombriloj, kiuj tute ne moviĝas, montras la prefiksan aron aŭ la kunhavatan ŝlosilon.

Tempigiloj klarigas klason de malkonektoj, kiuj estas erare atribuataj al la VPN. La ŝarĝbalancilo de Azure fermas neaktivajn fluojn post sia agordita tempolimo, kvar minutoj defaŭlte kiam ĉi tiuj notoj estis skribitaj kaj agordebla supren, do OpenVPN-servilo sur VM sen keepalive povas faligi ĉiujn kelkajn minutojn dum ĉio alia aspektas sana. Pordego, kiun la platformo cikle restartigas, ankaŭ povas interrompi VNet-konekton al Web App, kaj tiu fiasko situas sur la platforma flanko anstataŭ en klienta agordo. La indiko estas, ĉu la malkonekto sekvas fiksan intervalon aŭ ŝanĝon, kiun vi faris.

Tenu la tri objektojn kaj iliajn valorojn en unu rikordo: la adresaro de la virtuala reto, la prefiksa listo de la loka retpordego kaj la referenco al la kunhavata ŝlosilo de la konekto. PowerShell-artikolo pri site-to-site dokumentas la komandojn de la loka retpordego kaj la ordon, al kiu ili apartenas. Kompari prefiksan ŝanĝon kun la memoro estas kiel funkcianta tunelo estas rekonstruata dufoje.

Poste kontrolu laŭ la ordo, en kiu vi ŝanĝis: la loka retpordego montras la novan prefiksan liston, la konekto estas denove Connected, kaj la nombriloj moviĝas kiam vi sendas trafikon al gastiganto en la nova gamo. Se la tria paŝo malsukcesas dum la unuaj du pasas, la fora flanko ne akceptis la novan trafikan selektilon kaj la fora aparato bezonas la respondan enskribon de fazo 2. Tio estas konversacio kun la alia fino de la tunelo, ne plia ŝanĝo en Azure.