Problemen met virtuele netwerkconnectiviteit in Microsoft Azure oplossen
Bepalen of verkeer tussen peers is toegestaan
Met peering kunt u twee of meer virtuele netwerken in Azure verbinden. Het verkeer tussen de virtuele netwerken wordt gerouteerd via de backbone-infrastructuur van Microsoft, niet via een gateway of via het openbare internet. Er zijn twee soorten peering in Azure:
Peering van virtuele netwerken: virtuele netwerken verbinden binnen dezelfde Azure-regio.
Wereldwijde peering van virtuele netwerken: virtuele netwerken verbinden in verschillende Azure-regio's.
Wereldwijde peering van virtuele netwerken heeft de volgende beperkingen:
Resources in één virtueel netwerk kunnen niet communiceren met het front-end-IP-adres van een Basic Internal Load Balancer (ILB) in een wereldwijd gekoppeld virtueel netwerk.
Sommige services die gebruikmaken van een Basic Load Balancer werken niet via wereldwijde peering van virtuele netwerken.
U kunt niet peeren tussen clouds.
De virtuele netwerken die u peert, moeten niet-overlappende IP-adresruimten hebben.
Wanneer twee virtuele netwerken zijn gekoppeld, kunt u geen adresbereiken toevoegen of verwijderen uit de adresruimte van een virtueel netwerk. Als u adresbereiken wilt toevoegen of verwijderen, verwijdert u de peering, voegt u de adresbereiken toe of verwijdert u deze en maakt u de peering opnieuw.
U kunt geen twee virtuele netwerken koppelen die zijn gemaakt via het klassieke implementatiemodel.
In Azure ingebouwde naamomzetting worden namen in gekoppelde virtuele netwerken niet omgezet. Als u namen in andere virtuele netwerken wilt omzetten, moet u privézones van Azure of een aangepaste DNS-server gebruiken.
Een virtueel netwerk kan worden gekoppeld aan een ander virtueel netwerk en kan ook worden verbonden met een virtuele Azure-netwerkgateway. Wanneer virtuele netwerken zijn verbonden via peering en een gateway, stroomt verkeer tussen de virtuele netwerken via de peeringconfiguratie in plaats van de gateway.
Punt-naar-site-VPN-clients moeten opnieuw worden gedownload nadat peering van virtuele netwerken is geconfigureerd, om ervoor te zorgen dat de nieuwe routes naar de client worden gedownload.
Ga als volgt te werk om verbinding tussen peers op te lossen:
Controleer de status van de peeringverbinding:
Gestart geeft aan dat u geen bidirectionele koppeling hebt. Als u bijvoorbeeld VNetA wilt koppelen aan VNetB, moeten er twee koppelingen worden gemaakt, één van VNetA naar VNetB en een andere van VNetB naar VNetA. Als u beide koppelingen maakt, wordt de status gewijzigd in Verbinding maken ed.
Verbroken geeft aan dat een van de koppelingen is verwijderd. Als u een peeringverbinding opnieuw tot stand wilt brengen, moet u beide koppelingen verwijderen en opnieuw maken.
Controleer of twee VNets geen overeenkomende of overlappende adresbereiken hebben.
Problemen met vpn-gatewayoverdracht oplossen
Gatewayoverdracht is een peering-eigenschap waarmee een virtueel netwerk de VPN-gateway in het gekoppelde virtuele netwerk kan gebruiken voor VNet-naar-VNet-connectiviteit. In het volgende diagram ziet u hoe gatewayoverdracht werkt met peering van virtuele netwerken:
De volgende beperkingen zijn van toepassing wanneer virtuele netwerken wereldwijd zijn gekoppeld:
Resources in één virtueel netwerk kunnen niet communiceren met het front-end-IP-adres van een Basic ILB in een wereldwijd gekoppeld virtueel netwerk.
Sommige services die gebruikmaken van een Basic Load Balancer werken niet via wereldwijde peering van virtuele netwerken. Zie Wat zijn de beperkingen met betrekking tot Globale VNet-peering en Load Balancers voor meer informatie?
Probeer het volgende om problemen met vpn-gatewayoverdracht op te lossen:
Als het virtuele spoke-netwerk al een VPN-gateway heeft, wordt de optie Externe gateway gebruiken niet ondersteund in het virtuele spoke-netwerk vanwege een peeringbeperking.
Voor een probleem met de hub-spoke-netwerkverbinding tussen virtuele spoke-netwerken in dezelfde regio moet het hubnetwerk een NVA bevatten. Configureer UDR's in spokes met een NVA-set als de volgende hop en schakel doorgestuurd verkeer toestaan in het virtuele hubnetwerk in.
Problemen met transitiviteit tussen peers oplossen
Transitieve peering is wanneer u:
Peer VNetA naar VNetB.
Peer VNetB naar VNetC.
VNetA is standaard niet gekoppeld aan VNetC.
Als u peering tussen VNetA en VNetC wilt bereiken, moet u deze peering aan elkaar koppelen. U kunt ook een hub-and-spoke-configuratie gebruiken en een NVA in de hub doorlopen.
Problemen met hub-and-spoke-VNet-configuraties oplossen
Met een hub-and-spoke-configuratie fungeert het virtuele hubnetwerk als een centraal punt van connectiviteit met veel virtuele spoke-netwerken. De hub kan ook worden gebruikt als het connectiviteitspunt naar uw on-premises netwerken. De virtuele spoke-netwerken peeren met de hub en kunnen worden gebruikt om workloads te isoleren.
U kunt als volgt problemen met connectiviteit tussen een virtueel hub-spoke-netwerk en een on-premises resource oplossen.
Als uw netwerk gebruikmaakt van een NVA van derden, controleert u op het volgende:
Software-updates.
Serviceaccount instellen en functionaliteit.
Door de gebruiker gedefinieerde routes (UDR's) op subnetten van virtuele netwerken die verkeer naar NVA leiden.
UDR's op subnetten van virtuele netwerken die verkeer van NVA omleiden.
Routeringstabellen en -regels binnen de NVA (bijvoorbeeld van NIC1 naar NIC2).
Tracering op NVA-NIC's om het ontvangen en verzenden van netwerkverkeer te verifiëren.
Wanneer u een standard-SKU en openbare IP-adressen gebruikt, moet er een NSG zijn gemaakt en moet er een expliciete regel zijn om toe te staan dat het verkeer naar de NVA wordt gerouteerd.
De minimale configuratie voor NVA's in Azure.
Als uw netwerk gebruikmaakt van een VPN-gateway, controleert u op het volgende:
- De gateway moet zich in het virtuele netwerk in het Resource Manager-model bevinden.
Als uw netwerk geen NVA of VPN-gateway van derden gebruikt, hebben het virtuele hubnetwerk en het virtuele spoke-netwerk een VPN-gateway? Als het virtuele spoke-netwerk al een VPN-gateway heeft, wordt de optie Externe gateway gebruiken niet ondersteund in het virtuele spoke-netwerk. Dit komt door een beperking voor peering van virtuele netwerken.
Voor site-naar-site- of Azure ExpressRoute-verbindingen controleert u de volgende oorzaken van verbindingsproblemen met het externe virtuele netwerk van on-premises:
Als het virtuele netwerk een gateway heeft, controleert u of het selectievakje Doorgestuurd verkeer toestaan is ingeschakeld.
Als het virtuele netwerk geen gateway heeft, controleert u of het selectievakje Externe gateway gebruiken is ingeschakeld.
Vraag uw netwerkbeheerder om uw on-premises apparaten te controleren om te controleren of er allemaal de adresruimte voor het externe virtuele netwerk is toegevoegd.
Voor punt-naar-site-verbindingen:
Controleer in het virtuele netwerk met een gateway of het selectievakje Doorgestuurd verkeer toestaan is ingeschakeld.
Controleer in het virtuele netwerk dat geen gateway heeft of het selectievakje Externe gateway gebruiken is ingeschakeld.
Download het punt-naar-site-clientpakket en installeer het opnieuw. Virtuele netwerkroutes die nieuw zijn gekoppeld, voegen niet automatisch routes toe aan punt-naar-site-clients.
Problemen met wereldwijde peeringconnectiviteit oplossen
Een verbindingsprobleem tussen gekoppelde virtuele netwerken oplossen:
Meld u aan bij Azure Portal met een account met de benodigde rollen en machtigingen.
Selecteer het virtuele netwerk, selecteer Peering en selecteer vervolgens het veld Status .
Als de status Verbroken is, verwijdert u de peering uit beide virtuele netwerken en maakt u deze opnieuw.
Als de status is Verbinding maken, controleert u de netwerkverkeersstromen.
Gebruik Verbinding maken ion Troubleshoot and IP flow verify from the source VM to the destination VM to the destination VM om te bepalen of er een NSG of UDR is die interferentie in verkeersstromen veroorzaakt.
Als u een firewall of NVA gebruikt:
Documenteer de UDR-parameters zodat u deze kunt herstellen nadat deze stap is voltooid.
Verwijder de UDR uit het bron-VM-subnet of de NIC die verwijst naar de NVA als de volgende hop. Controleer de connectiviteit van de bron-VM rechtstreeks naar de bestemming die de NVA omzeilt.
Neem een netwerktracering:
- Start een netwerktracering op de doel-VM. Voor Windows kunt u Netsh gebruiken. Gebruik TCPDump voor Linux. - Voer TcpPing of PsPing uit van de bron naar het doel-IP-adres. Dit is een voorbeeld van een TcpPing-opdracht :
tcping64.exe -t <destination VM address> 3389
Nadat tcpPing is voltooid, stopt u de netwerktracering op de bestemming. Als pakketten afkomstig zijn van de bron, is er geen netwerkprobleem. Controleer zowel de VM-firewall als de toepassing die op die poort luistert om het configuratieprobleem te vinden.
Notitie
U kunt geen verbinding maken met de volgende resourcetypen via wereldwijde peering van virtuele netwerken (virtuele netwerken in verschillende regio's):
VM's achter Basic ILB SKU
Redis-cache (maakt gebruik van Basic ILB SKU)
Application Gateway (maakt gebruik van Basic ILB SKU)
Schaalsets (maakt gebruik van Basic ILB SKU)
Service Fabric-clusters (maakt gebruik van Basic ILB SKU)
SQL Server Always On (maakt gebruik van Basic ILB SKU)
App Service Environment (maakt gebruik van Basic ILB SKU)
API Management (maakt gebruik van Basic ILB SKU)
Microsoft Entra Domain Services (maakt gebruik van Basic ILB SKU)
Zie de vereisten en beperkingen van wereldwijde peering voor meer informatie.
Problemen met VNet-naar-VNet-verbindingen oplossen
Ga als volgt te werk:
Controleer of de gateways zijn geconfigureerd met dynamische routering en niet met statische routering. Statische routering wordt niet ondersteund.
Controleer het aantal VPN-verbindingen. Voor eenvoudige en standaard dynamische routeringsgateways is het maximum aantal VPN-verbindingen en VNets waarmee een bepaald VNet verbinding kan maken momenteel 10. Het is 30 voor gateways met hoge prestaties.
Controleer de adresvoorvoegsels op beide VNets om ervoor te zorgen dat er geen overlappende adresruimten tussen de twee VNets zijn.
Problemen met servicechaining oplossen
Servicechaining is de mogelijkheid om verkeer van één virtueel netwerk naar een NVA te verzenden in een gekoppeld netwerk via door de gebruiker gedefinieerde routes. In gekoppelde virtuele netwerken configureert u door de gebruiker gedefinieerde routes die verwijzen naar virtuele machines als het IP-adres van de volgende hop. U moet een routetabel instellen en deze koppelen aan een subnet. Zie Zelfstudie: Netwerkverkeer routeren met een routetabel met behulp van Azure Portal voor stapsgewijze instructies voor het routeren van netwerkverkeer.
Met Behulp van PowerShell kunt u de routering van netwerkverkeer testen met behulp van tracert:
tracert myvmprivate
Hiermee wordt de traceringsroute weergegeven en ziet u of het verkeer de route neemt die u verwacht. Tracert heeft een antwoord dat vergelijkbaar is met:
Tracing route to myvmprivate.q04q2hv50taerlrtdyjz5nza1f.bx.internal.cloudapp.net [10.0.1.4] over a maximum of 30 hops:
1 1 ms * 2 ms myvmnva.internal.cloudapp.net [10.0.2.4]
2 2 ms 1 ms 1 ms myvmprivate.internal.cloudapp.net [10.0.1.4]
Trace complete.