Waarom het toevoegen van een Azure VPN-prefix de verbinding verbreekt

Een prefix die aan het verkeerde Azure-object wordt toegevoegd, levert een verbinding op die Connected meldt en niets doorstuurt, en dat is de duurste foutsoort in deze stack. Er zijn drie resources bij betrokken en slechts één ervan bezit de externe adresruimte: de gateway van het virtuele netwerk, de lokale netwerkgateway die de andere kant beschrijft, en de verbinding die ze verbindt. Het prefix hoort bij de lokale netwerkgateway, de verbinding moet opnieuw worden opgebouwd wil de wijziging ingaan, en de gateway zelf blijft meestal ongemoeid. De volgorde is niet onderhandelbaar, en de portal toont er maar een deel van.

Drie objecten, waarvan er één het prefix bevat

De adresruimte van het virtuele netwerk beantwoordt een andere vraag: wat er binnen Azure leeft. Een extern prefix daar toevoegen leidt geen verkeer ernaartoe, het verbreedt alleen de ruimte waarvan het platform denkt dat het die bezit, wat kan botsen met het echte externe bereik. De lokale netwerkgateway is het object dat de externe prefixen bevat, en de verbinding verwijst naar beide gateways plus een vooraf gedeelde sleutel.

Er is nog een derde voorbehoud om in gedachten te houden. GatewaySubnet host de beheerde gateway-exemplaren, moet precies die naam dragen, en voor niet-Basic-SKU's wordt verwacht dat het minstens een /27 is.

Niets anders hoort in dat subnet, en een prefixwijziging heeft geen reden om het aan te raken. Een prefix dat in de lokale netwerkgateway ontbreekt, is onbereikbaar wat de verbindingsstatus ook zegt, omdat de gateway alleen de prefixen aanbiedt waarover hij is geïnformeerd bij het onderhandelen over de tunnel. Daarom is het symptoom asymmetrisch: de tunnel staat, de beveiligingskoppeling is in orde, en één subnet verschijnt nooit in de verkeersselectors. Als één extern bereik ontbreekt terwijl de buren werken, stop dan met naar de tunnel te kijken en lees de lokale netwerkgateway.

Waarom juist de verbinding wordt verwijderd

Het verbindingsobject legt de onderhandelde configuratie voor zijn hele levensduur vast. Daarom verwijdert de gedocumenteerde procedure eerst de verbinding, werkt de lokale netwerkgateway bij en maakt daarna de verbinding opnieuw met dezelfde gedeelde sleutel. De gateway-exemplaren worden niet opnieuw opgebouwd voor een wijziging die alleen het prefix betreft, wat de storing beperkt tot het afbreken van de verbinding in plaats van een nieuwe uitrol van de gateway.

Die verwijdering is de storing, dus behandel het als een geplande wijziging met een begin en een verwacht einde in plaats van een snelle bewerking. In PowerShell is de volgorde kort: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, daarna Set-AzLocalNetworkGateway met het nieuwe -AddressPrefix array, daarna New-AzVirtualNetworkGatewayConnection met dezelfde -SharedKey en dezelfde gateways. De sleutel hergebruiken is belangrijk, omdat de externe kant niet opnieuw wordt geconfigureerd en een nieuwe sleutel overleg vereist met wie het externe apparaat bezit. Als een ander team dat apparaat beheert, stem het venster met hen af voordat je iets verwijdert.

Wanneer de gateway zelf opnieuw moet worden opgebouwd

Een tweede antwoord dat rond dit probleem circuleert, zegt dat de gateway opnieuw moet worden gemaakt en de sleutel opnieuw uitgewisseld. Dat klopt voor een andere reeks bewerkingen: het wijzigen van het gatewaytype of de SKU, wisselen tussen punt-naar-site en site-naar-site, of het repareren van een gateway waarvan de eigen configuratie onjuist is. Zulke wijzigingen veranderen inderdaad de gatewayresource, dus een herbouw is echt nodig.

Een gateway die voor punt-naar-site is gemaakt, kan niet zomaar een site-naar-site-verbinding krijgen. De punt-naar-site-configuratie moet worden verwijderd en de gateway opnieuw worden gemaakt, wat ook een nieuwe gedeelde sleutel en een nieuw clientpakket oplevert.

Het punt-naar-site-pakket verdient een eigen opmerking omdat het verloopt. De portal genereert een bestand met een korte levensduur, dus de praktische aanpak is het één keer te downloaden en samen met het clientcertificaat te verspreiden in plaats van gebruikers een portallink te sturen die dood is tegen de tijd dat ze erop klikken. Voor de prefixvraag geldt niets hiervan. De twee procedures gescheiden houden is de hele discipline: prefixen zijn een wijziging op verbindingsniveau, en gateway-eigenschappen zijn een wijziging op gatewayniveau.

Lees de status, niet de portalbadge

Lees de status uit de resource in plaats van uit de badge in de portal. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 retourneert ConnectionStatus samen met tellers voor inkomende en uitgaande bytes, en de tellers zijn wat een tunnel die verbonden is en niets draagt onderscheidt van een die nooit tot stand kwam.

Tellers die midden in een overdracht stoppen met stijgen, wijzen op het pad en niet op de authenticatie. Tellers die helemaal niet bewegen, wijzen op de prefixset of de gedeelde sleutel.

Timers verklaren een klasse van verbrekingen die ten onrechte aan de VPN worden toegeschreven. De load balancer van Azure sluit inactieve stromen na de geconfigureerde time-out, standaard vier minuten toen deze notities werden geschreven en naar boven configureerbaar, dus een OpenVPN-server op een VM zonder keepalive kan elke paar minuten wegvallen terwijl al het andere gezond lijkt. Een gateway die het platform cyclisch herstart, kan ook een VNet-verbinding naar een Web App onderbreken, en die storing zit aan de platformkant en niet in een clientconfiguratie. Het signaal is of de verbreking een vast interval volgt of een wijziging die u hebt aangebracht.

Houd de drie objecten en hun waarden in één registratie: de adresruimte van het virtuele netwerk, de prefixlijst van de lokale netwerkgateway en de verwijzing naar de gedeelde sleutel van de verbinding. PowerShell-artikel voor site-naar-site documenteert de opdrachten van de lokale netwerkgateway en de volgorde waarin ze horen. Een prefixwijziging met het geheugen vergelijken is hoe een werkende tunnel twee keer opnieuw wordt opgebouwd.

Controleer daarna in de volgorde waarin u hebt gewijzigd: de lokale netwerkgateway toont de nieuwe prefixlijst, de verbinding staat weer op Connected, en de tellers bewegen wanneer u verkeer naar een host in het nieuwe bereik stuurt. Als de derde stap mislukt terwijl de eerste twee slagen, heeft de externe kant de nieuwe verkeersselector niet geaccepteerd en heeft het externe apparaat de bijbehorende fase-2-vermelding nodig. Dat is een gesprek met de andere kant van de tunnel, niet nog een wijziging in Azure.