Varför ett Azure VPN-prefix som läggs till bryter anslutningen

Ett prefix som läggs till på fel Azure-objekt ger en anslutning som rapporterar Connected och inte vidarebefordrar något, och det är den dyraste typen av fel i den här stacken. Tre resurser är inblandade och bara en av dem äger det fjärran adressutrymmet: gatewayen för det virtuella nätverket, den lokala nätverksgatewayen som beskriver fjärrsidan och anslutningen som förbinder dem. Prefixet tillhör den lokala nätverksgatewayen, anslutningen måste byggas om för att ändringen ska träda i kraft, och själva gatewayen lämnas vanligtvis orörd. Ordningen är inte förhandlingsbar, och portalen visar bara en del av den.

Tre objekt, varav ett håller prefixet

Adressutrymmet för det virtuella nätverket svarar på en annan fråga: vad som bor inuti Azure. Att lägga till ett fjärran prefix där dirigerar inte trafik dit, det vidgar bara det utrymme som plattformen tror sig äga, vilket kan kollidera med det verkliga fjärrområdet. Den lokala nätverksgatewayen är objektet som håller de fjärran prefixen, och anslutningen refererar till båda gatewayerna plus en i förväg delad nyckel.

Det finns en tredje förutsättning att hålla reda på. GatewaySubnet är värd för de hanterade gatewayinstanserna, måste bära exakt det namnet, och för SKU:er som inte är Basic förväntas det vara minst /27.

Inget annat hör hemma i det subnätet, och en prefixändring har ingen anledning att röra det. Ett prefix som saknas i den lokala nätverksgatewayen är onåbart vad anslutningsstatusen än säger, eftersom gatewayen bara erbjuder de prefix som den informerades om när den förhandlade tunneln. Därför är symtomet asymmetriskt: tunneln är uppe, säkerhetsassociationen är i ordning, och ett subnät dyker aldrig upp i trafikväljarna. Om ett enda fjärrområde saknas medan grannarna fungerar, sluta titta på tunneln och läs den lokala nätverksgatewayen.

Varför det är anslutningen som tas bort

Anslutningsobjektet låser den förhandlade konfigurationen under hela sin livstid. Därför tar den dokumenterade proceduren först bort anslutningen, uppdaterar den lokala nätverksgatewayen och återskapar sedan anslutningen med samma delade nyckel. Gatewayinstanserna byggs inte om för en ändring som bara gäller prefixet, vilket begränsar avbrottet till nedmonteringen av anslutningen i stället för en ny driftsättning av gatewayen.

Den borttagningen är avbrottet, så behandla den som en planerad ändring med en början och ett förväntat slut i stället för en snabb redigering. I PowerShell är sekvensen kort: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, sedan Set-AzLocalNetworkGateway med den nya -AddressPrefix arrayen, sedan New-AzVirtualNetworkGatewayConnection med samma -SharedKey och samma gatewayer. Att återanvända nyckeln spelar roll, eftersom fjärrsidan inte konfigureras om och en ny nyckel innebär samordning med den som äger fjärrenheten. Om ett annat team driftar enheten, kom överens om fönstret med dem innan du tar bort något.

När själva gatewayen måste byggas om

Ett andra svar som cirkulerar kring det här problemet säger att gatewayen måste återskapas och nyckeln bytas ut igen. Det stämmer för en annan uppsättning operationer: att ändra gatewaytyp eller SKU, växla mellan punkt-till-plats och plats-till-plats, eller reparera en gateway vars egen konfiguration är fel. Sådana ändringar ändrar verkligen gatewayresursen, så en ombyggnad är verkligen nödvändig.

En gateway som skapats för punkt-till-plats kan inte bara ges en plats-till-plats-anslutning. Konfigurationen för punkt-till-plats måste tas bort och gatewayen återskapas, vilket också ger en ny delad nyckel och ett nytt klientpaket.

Paketet för punkt-till-plats förtjänar en egen notering eftersom det löper ut. Portalen genererar en fil med kort livstid, så det praktiska tillvägagångssättet är att ladda ner den en gång och distribuera den tillsammans med klientcertifikatet i stället för att skicka en portallänk till användarna som är död när de klickar. För prefixfrågan gäller inget av detta. Att hålla de två procedurerna åtskilda är hela disciplinen: prefix är en ändring på anslutningsnivå, och gatewayegenskaper är en ändring på gatewaynivå.

Läs tillståndet, inte portalens märke

Läs tillståndet från resursen i stället för från märket i portalen. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 returnerar ConnectionStatus tillsammans med byträknare för in- och utgående trafik, och det är räknarna som skiljer en tunnel som är ansluten och inte bär något från en som aldrig upprättades.

Räknare som slutar öka mitt i en överföring pekar på vägen och inte på autentiseringen. Räknare som inte rör sig alls pekar på prefixmängden eller den delade nyckeln.

Timers förklarar en klass av avbrott som felaktigt tillskrivs VPN:en. Azures lastbalanserare stänger inaktiva flöden efter sin konfigurerade timeout, fyra minuter som standard när de här anteckningarna skrevs och konfigurerbart uppåt, så en OpenVPN-server på en VM utan keepalive kan falla var några minuter medan allt annat ser friskt ut. En gateway som plattformen startar om cykliskt kan också avbryta en VNet-anslutning till en Web App, och det felet ligger på plattformssidan och inte i en klientkonfiguration. Tecknet är om avbrottet följer ett fast intervall eller en ändring du har gjort.

Håll de tre objekten och deras värden i en enda post: adressutrymmet för det virtuella nätverket, prefixlistan för den lokala nätverksgatewayen och referensen till anslutningens delade nyckel. PowerShell-artikeln för plats-till-plats dokumenterar kommandona för den lokala nätverksgatewayen och den ordning de hör till. Att jämföra en prefixändring med minnet är hur en fungerande tunnel byggs om två gånger.

Verifiera sedan i den ordning du ändrade: den lokala nätverksgatewayen visar den nya prefixlistan, anslutningen är tillbaka på Connected, och räknarna rör sig när du skickar trafik till en värd i det nya området. Om det tredje steget misslyckas medan de två första går igenom, har fjärrsidan inte accepterat den nya trafikväljaren och fjärrenheten behöver motsvarande fas 2-post. Det är ett samtal med andra änden av tunneln, inte en annan ändring i Azure.