Zašto dodavanje Azure VPN prefiksa prekida vezu

Prefiks dodan pogrešnom Azure objektu stvara vezu koja prijavljuje Connected i ne prosljeđuje ništa, a to je najskuplja vrsta greške u ovom stacku. Uključena su tri resursa i samo jedan od njih posjeduje udaljeni adresni prostor: gateway virtualne mreže, lokalni mrežni gateway koji opisuje drugu stranu i veza koja ih spaja. Prefiks pripada lokalnom mrežnom gatewayu, veza se mora ponovno izgraditi da bi promjena stupila na snagu, a sam gateway obično ostaje netaknut. Redoslijed nije predmet pregovora, a portal prikazuje samo dio toga.

Tri objekta, od kojih jedan drži prefiks

Adresni prostor virtualne mreže odgovara na drugo pitanje: šta živi unutar Azurea. Dodavanje udaljenog prefiksa tamo ne usmjerava saobraćaj prema njemu, samo širi prostor za koji platforma vjeruje da ga posjeduje, što se može sudariti sa stvarnim udaljenim rasponom. Lokalni mrežni gateway je objekt koji drži udaljene prefikse, a veza referencira oba gatewaya plus unaprijed dijeljeni ključ.

Postoji i treća rezervacija koju treba imati na umu. GatewaySubnet hostuje upravljane instance gatewaya, mora nositi tačno to ime, a za ne-Basic SKU se očekuje da bude najmanje /27.

Ništa drugo ne pripada u tu podmrežu, a promjena prefiksa nema razloga da ga dira. Prefiks koji nedostaje u lokalnom mrežnom gatewayu nedostupan je bez obzira šta kaže status veze, jer gateway nudi samo prefikse o kojima je obaviješten kada pregovara tunel. Zato je simptom asimetričan: tunel je podignut, sigurnosna asocijacija je u redu, a jedna podmreža se nikada ne pojavljuje u selektorima saobraćaja. Ako jedan udaljeni raspon nedostaje dok njegovi susjedi rade, prestanite gledati u tunel i pročitajte lokalni mrežni gateway.

Zašto se uklanja upravo veza

Objekt veze fiksira pregovaranu konfiguraciju za cijeli svoj životni vijek. Zato dokumentovana procedura prvo uklanja vezu, ažurira lokalni mrežni gateway, a zatim ponovo stvara vezu s istim dijeljenim ključem. Instance gatewaya se ne obnavljaju za promjenu samo prefiksa, što ograničava prekid na rastavljanje veze umjesto na ponovno postavljanje gatewaya.

To brisanje je prekid, pa ga tretirajte kao planiranu promjenu s početkom i očekivanim krajem, a ne kao brzu izmjenu. U PowerShellu je slijed kratak: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, zatim Set-AzLocalNetworkGateway s novim -AddressPrefix nizom, zatim New-AzVirtualNetworkGatewayConnection s istim -SharedKey i istim gatewayima. Ponovno korištenje ključa je važno, jer druga strana nije rekonfigurisana i novi ključ znači koordinaciju s onim ko posjeduje udaljeni uređaj. Ako tim uređajem upravlja drugi tim, dogovorite prozor s njima prije nego što bilo šta uklonite.

Kada se sam gateway mora ponovo izgraditi

Drugi odgovor koji kruži oko ovog problema kaže da gateway mora biti ponovo stvoren i ključ ponovo razmijenjen. To je tačno za drugačiji skup operacija: promjenu tipa gatewaya ili SKU-a, prelazak između point-to-site i site-to-site ili popravku gatewaya čija je vlastita konfiguracija pogrešna. Takve promjene zaista mijenjaju resurs gatewaya, pa je ponovna izgradnja zaista potrebna.

Gateway stvoren za point-to-site ne može jednostavno dobiti site-to-site vezu. Point-to-site konfiguracija mora se ukloniti i gateway ponovo stvoriti, što također daje novi dijeljeni ključ i novi klijentski paket.

Point-to-site paket zaslužuje vlastitu napomenu jer istječe. Portal generiše datoteku kratkog vijeka, pa je praktičan pristup preuzeti je jednom i distribuirati uz klijentski certifikat, umjesto slanja korisnicima portala linka koji će biti mrtav dok kliknu. Za pitanje prefiksa ništa od ovoga ne vrijedi. Držati dvije procedure odvojenima jeste cijela disciplina: prefiksi su promjena na nivou veze, a svojstva gatewaya promjena na nivou gatewaya.

Čitajte stanje, a ne značku portala

Čitajte stanje iz resursa, a ne sa značke u portalu. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 vraća ConnectionStatus zajedno s brojačima ulaznih i izlaznih bajtova, i upravo brojači razlikuju tunel koji je povezan i ne nosi ništa od onog koji se nikada nije uspostavio.

Brojači koji prestanu rasti na sredini prijenosa upućuju na putanju, a ne na autentifikaciju. Brojači koji se uopće ne pomjeraju upućuju na skup prefiksa ili dijeljeni ključ.

Tajmeri objašnjavaju klasu prekida koji se pogrešno pripisuju VPN-u. Azureov balanser opterećenja zatvara neaktivne tokove nakon konfiguriranog tajmauta, četiri minute po defaultu kada su ove bilješke pisane i može se povećavati, pa OpenVPN server na VM-u bez keepalive može padati svakih nekoliko minuta dok sve ostalo izgleda zdravo. Gateway koji platforma ciklično restartuje također može prekinuti VNet vezu s Web Appom, a taj kvar je na strani platforme, a ne u klijentskoj konfiguraciji. Znak je da li prekid slijedi fiksni interval ili promjenu koju ste napravili.

Držite tri objekta i njihove vrijednosti u jednom zapisu: adresni prostor virtualne mreže, listu prefiksa lokalnog mrežnog gatewaya i referencu na dijeljeni ključ veze. site-to-site PowerShell članak dokumentuje komande lokalnog mrežnog gatewaya i redoslijed kojem pripadaju. Poređenje promjene prefiksa s pamćenjem je način na koji se radni tunel ponovo gradi dvaput.

Zatim provjerite redoslijedom kojim ste mijenjali: lokalni mrežni gateway prikazuje novu listu prefiksa, veza je ponovo Connected i brojači se pomjeraju kada pošaljete saobraćaj na host u novom rasponu. Ako treći korak ne uspije dok prva dva prolaze, druga strana nije prihvatila novi selektor saobraćaja i udaljeni uređaj treba odgovarajući unos faze 2. To je razgovor s drugim krajem tunela, a ne još jedna promjena u Azureu.