Azures IP-flödesverifiering säger tillåtet, men VPN:en misslyckas ändå

Plats-till-plats-tunneln är ansluten, VM:en är frisk, men den lokala klienten får ingenting. Du öppnar Network Watcher, kör IP-flödesverifiering och den säger Access allowed, så ärendet stängs som ett VPN-problem. Det resultatet betyder inte vad det ser ut som, eftersom IP-flödesverifiering utvärderar säkerhetsreglerna för flödet du beskrev och aldrig testar om Azure har en rutt till ditt lokala prefix.

Filtreringsfrågan och routingfrågan är åtskilda, och Network Watcher svarar på dem med olika verktyg. Att veta vilken du ställde är det mesta av diagnosen.

Vad IP-flödesverifiering faktiskt avgör

IP-flödesverifiering tar en VM, ett nätverksgränssnitt, en riktning, femtuplar-värden och ett protokoll och rapporterar sedan NSG- och säkerhetsadministratörsregelns beslut för det flödet. Den fungerar på TCP och UDP, så den är ingen ICMP-regeltestare och en blockerad ping bevisar ingenting om din tjänst. Ge den det verkliga flödet i stället för en gissning. En inkommande anslutning från det lokala nätet till en databasport är en annan beskrivning än en utgående anslutning som VM:en startar.

Om gatewayen översätter adresser, använd källadressen som når gränsen du utvärderar, inte den i klientkonfigurationen. Läs också resultatet för vad det är. Access allowed betyder att filtreringslagret skulle släppa igenom paketet om det anlände, och inget mer.

Vad den inte kan berätta är rutten Azure valde, om gästens brandvägg tillåter porten eller om något lyssnar. Det lever i andra lager.

Vad nästa hopp och effektiva rutter tillför

Nästa hopp svarar på en vidarebefordringsfråga: för den här destinationen vilken nästa-hopp-typ Azure väljer, på vilken adress, från vilken rutttabell. Effektiva rutter listar vad NIC:en faktiskt har. Kör båda och du får sökvägen på Azure-sidan som en grön IP-flödesverifiering lämnar tom.

Microsofts översikt över IP-flödesverifiering anger filtreringsomfånget direkt, medan sidorna om nästa hopp och ruttdiagnostik täcker vidarebefordringssidan. Citera rätt sida när du skriver ner fyndet.

Kommandona är korta nog att köras från ett skal. az network nic show-effective-route-table listar rutterna som tillämpas på gränssnittet. az network watcher show-next-hop med en källa och en destination returnerar det valda hoppet. Jämför prefixet du bryr dig om med den tabellen och bekräfta sedan vilken post som vinner.

Gå returvägen från VM:ens NIC

Gör detta från mål-VM:ens NIC, för det lokala klientprefixet, inte för internet. Returvägen är där plats-till-plats-fel gömmer sig, eftersom en tunnelstatuskontroll bara rapporterar att säkerhetsassociationerna är uppe.

Om den förväntade rutten saknas, kontrollera fjärrprefixen som gatewaykonfigurationen tillhandahåller, VNet-anslutningsdesignen och alla inställningar för ruttutbredning. Ett lokalt nätverksgatewayobjekt beskriver den lokala sidan; att det finns bevisar inte att varje nödvändigt prefix är närvarande och prioriterat på NIC:en. Det är olika fakta, och bara en av dem visas i en portalsammanfattning.

Läs nästa-hopp-typen i stället för att kopiera ett exempel

En sökväg via en hanterad VPN-gateway visar vanligtvis VirtualNetworkGateway som nästa-hopp-typ. VirtualAppliance beskriver en annan vidarebefordringsdesign, vanligtvis en brandvägg eller en virtuell nätverksenhet.

Skapa inte en enhetsrutt mot en gissad VPN-slutpunkt bara för att ett gammalt forumsvar använde den typen. Om en användardefinierad rutt åsidosätter den avsedda sökvägen, hitta ägaren och syftet innan du ändrar den. Ett andra NIC kan också ändra vilket gränssnitt gästen använder, och att ta bort det kan förstöra en annan tjänst i stället för att laga den här rutten.

Flytta till gränsen som fortfarande misslyckas

När filtrering och routing båda stämmer med designen ligger felet någon annanstans. Kontrollera gästens egen rutttabell, dess brandvägg och om lyssnaren är bunden till den förväntade adressen. Kontrollera sedan VPN:ens skyddade trafikväljare och den lokala svarvägen. Var och en av dem är ett separat test med ett separat resultat.

Avsluta med en tillåten applikationsbegäran och observationer från båda ändarna. Ett allow-resultat och ett korrekt nästa hopp är två bevisbitar, inte bevis för att anslutningen lyckades.