Azure’s IP-flow-verificatie zegt toegestaan, maar de VPN faalt nog steeds

Site-to-site-tunnel verbonden, VM gezond, de on-premises client krijgt niets. Je opent Network Watcher, draait IP-flow-verificatie en die zegt Access allowed, dus het ticket wordt gesloten als VPN-probleem. Dat resultaat betekent niet wat het lijkt, want IP-flow-verificatie beoordeelt de beveiligingsregels voor de flow die je beschreef en test nooit of Azure een route naar je on-premises prefix heeft.

De filtervraag en de routeringsvraag staan los van elkaar, en Network Watcher beantwoordt ze met verschillende hulpmiddelen. Weten welke je stelde is het grootste deel van de diagnose.

Wat IP-flow-verificatie werkelijk beslist

IP-flow-verificatie neemt een VM, een netwerkinterface, een richting, vijf-tupelwaarden en een protocol, en rapporteert dan de beslissing van de NSG- en beveiligingsbeheerderregel voor die flow. Het werkt op TCP en UDP, dus het is geen ICMP-regeltester en een geblokkeerde ping bewijst niets over je dienst. Geef het de echte flow in plaats van een gok. Een inkomende verbinding van on-premises naar een databasepoort is een andere beschrijving dan een uitgaande verbinding die de VM start.

Als de gateway adressen vertaalt, gebruik dan het bronadres dat de grens bereikt die je beoordeelt, niet dat uit de clientconfiguratie. Lees het resultaat ook voor wat het is. Access allowed betekent dat de filterlaag het pakket zou doorlaten als het aankwam, en niets meer.

Wat het je niet kan vertellen, is de route die Azure koos, of de gastfirewall de poort toestaat, of er iets luistert. Dat leeft op andere lagen.

Wat de volgende hop en effectieve routes toevoegen

De volgende hop beantwoordt een doorstuurvraag: voor deze bestemming welk type volgende hop Azure kiest, op welk adres, uit welke routetabel. Effectieve routes tonen wat de NIC werkelijk heeft. Draai beide en je krijgt het pad aan de Azure-kant dat een groene IP-flow-verificatie leeg laat.

Microsofts overzicht van IP-flow-verificatie noemt de filteromvang direct, terwijl de pagina’s over de volgende hop en routediagnose de doorstuurzijde behandelen. Citeer de juiste pagina wanneer je de bevinding opschrijft.

De opdrachten zijn kort genoeg om ze vanuit een shell te draaien. az network nic show-effective-route-table toont de routes die op de interface zijn toegepast. az network watcher show-next-hop geeft met een bron en bestemming de gekozen hop terug. Vergelijk het prefix dat je aangaat met die tabel en bevestig dan welke vermelding wint.

Loop het retourpad vanaf de NIC van de VM

Doe dit vanaf de NIC van de doel-VM, voor het on-premises clientprefix, niet voor internet. Het retourpad is waar site-to-site-fouten zich verschuilen, want een tunnelstatuscontrole meldt alleen dat de beveiligingskoppelingen actief zijn.

Als de verwachte route ontbreekt, controleer de externe prefixen die de gatewayconfiguratie levert, het VNet-connectiviteitsontwerp en elke routepropagatie-instelling. Een local network gateway-object beschrijft de on-premises kant; het bestaan ervan bewijst niet dat elk vereist prefix op de NIC aanwezig en voorkeur heeft. Dat zijn verschillende feiten, en slechts één ervan verschijnt in een portalsamenvatting.

Lees het type volgende hop in plaats van een voorbeeld te kopiëren

Een pad via een beheerde VPN-gateway toont meestal VirtualNetworkGateway als type volgende hop. VirtualAppliance beschrijft een ander doorstuurontwerp, meestal een firewall of een virtueel netwerkapparaat.

Maak geen apparaatroute naar een geraden VPN-eindpunt omdat een oud forumantwoord dat type gebruikte. Als een door de gebruiker gedefinieerde route het bedoelde pad overschrijft, zoek dan de eigenaar en het doel ervan voordat je die wijzigt. Een tweede NIC kan ook veranderen welke interface de gast gebruikt, en het verwijderen ervan kan een andere dienst breken in plaats van deze route te repareren.

Ga naar de grens die nog steeds faalt

Wanneer filtering en routering beide kloppen met het ontwerp, zit de fout elders. Controleer de eigen routetabel van de gast, de firewall en of de listener aan het verwachte adres is gebonden. Controleer daarna de beschermde verkeersselectoren van de VPN en het on-premises antwoordpad. Elk daarvan is een aparte test met een apart resultaat.

Sluit af met een toegestane applicatieaanvraag en waarnemingen van beide uiteinden. Een allow-resultaat en een juiste volgende hop zijn twee stukken bewijs, niet het bewijs dat de verbinding is geslaagd.