Azures IP-flowkontrol siger tilladt, men VPN’en fejler stadig

Site-to-site-tunnelen er forbundet, VM’en er sund, men den lokale klient får intet. Du åbner Network Watcher, kører IP-flowkontrol, og den siger Access allowed, så sagen lukkes som et VPN-problem. Det resultat betyder ikke det, det ser ud som, fordi IP-flowkontrol vurderer sikkerhedsreglerne for den flow, du beskrev, og aldrig tester, om Azure har en rute til dit lokale præfiks.

Filtreringsspørgsmålet og routing-spørgsmålet er adskilte, og Network Watcher besvarer dem med forskellige værktøjer. At vide, hvilket af dem du stillede, er det meste af diagnosen.

Hvad IP-flowkontrol faktisk afgør

IP-flowkontrol tager en VM, en netværksgrænseflade, en retning, femtupel-værdier og en protokol og rapporterer derefter NSG- og sikkerhedsadministratorreglens afgørelse for den flow. Den virker på TCP og UDP, så den er ikke en ICMP-regeltester, og en blokeret ping beviser intet om din tjeneste. Giv den den rigtige flow i stedet for et gæt. En indgående forbindelse fra det lokale netværk til en databaseport er en anden beskrivelse end en udgående forbindelse, som VM’en starter.

Hvis gatewayen oversætter adresser, skal du bruge kildeadressen, der når den grænse, du vurderer, ikke den i klientkonfigurationen. Læs også resultatet for det, det er. Access allowed betyder, at filtreringslaget ville tillade pakken, hvis den ankom, og intet mere.

Det, den ikke kan fortælle dig, er den rute, Azure valgte, om gæstens firewall tillader porten, eller om noget lytter. Det lever i andre lag.

Hvad næste hop og effektive ruter tilføjer

Næste hop besvarer et videresendelsesspørgsmål: for denne destination, hvilken næste-hop-type Azure vælger, på hvilken adresse, fra hvilken rutetabel. Effektive ruter viser, hvad NIC’en faktisk har. Kør begge, og du får den Azure-side sti, som en grøn IP-flowkontrol lader stå tom.

Microsofts oversigt over IP-flowkontrol angiver filtreringsomfanget direkte, mens siderne om næste hop og rutediagnose dækker videresendelsessiden. Citér den rigtige side, når du skriver fundet.

Kommandoerne er korte nok til at køre fra en shell. az network nic show-effective-route-table viser de ruter, der er anvendt på grænsefladen. az network watcher show-next-hop med en kilde og destination returnerer det valgte hop. Sammenlign det præfiks, du bekymrer dig om, med den tabel, og bekræft derefter, hvilken post der vinder.

Gå returvejen fra VM’ens NIC

Gør det fra den målrettede VM’s NIC, for det lokale klientpræfiks, ikke for internettet. Returvejen er der, hvor site-to-site-fejl skjuler sig, fordi en tunneltilstandskontrol kun rapporterer, at sikkerhedsassociationerne er oppe.

Hvis den forventede rute mangler, skal du kontrollere de fjernpræfikser, gatewaykonfigurationen leverer, VNet-forbindelsesdesignet og enhver ruteudbredelsesindstilling. Et lokalt netværksgateway-objekt beskriver den lokale side; dets eksistens beviser ikke, at hvert påkrævet præfiks er til stede og foretrukket på NIC’en. Det er forskellige fakta, og kun ét af dem vises i et portalsammendrag.

Læs næste-hop-typen i stedet for at kopiere et eksempel

En administreret VPN-gateway-sti viser normalt VirtualNetworkGateway som næste-hop-type. VirtualAppliance beskriver et andet videresendelsesdesign, normalt en firewall eller et virtuelt netværksapparat.

Opret ikke en apparatrute, der peger på et gættet VPN-endepunkt, fordi et gammelt forumsvar brugte den type. Hvis en brugerdefineret rute tilsidesætter den tilsigtede sti, skal du finde dens ejer og formål, før du ændrer den. En anden NIC kan også ændre, hvilken grænseflade gæsten bruger, og at fjerne den kan ødelægge en anden tjeneste i stedet for at rette denne rute.

Flyt dig til den grænse, der stadig fejler

Når filtrering og routing begge passer til designet, er fejlen et andet sted. Kontroller gæstens egen rutetabel, dens firewall og om lytteren er bundet til den forventede adresse. Kontroller derefter VPN’ens beskyttede trafikvælgere og den lokale svarvej. Hver af dem er en separat test med et separat resultat.

Afslut med en tilladt applikationsanmodning og observationer fra begge ender. Et allow-resultat og et korrekt næste hop er to stykker bevis, ikke bevis for, at forbindelsen lykkedes.