Azures IP-flytkontroll sier tillatt, men VPN-en feiler fortsatt

Nettsted-til-nettsted-tunnelen er tilkoblet, VM-en er sunn, men den lokale klienten får ingenting. Du åpner Network Watcher, kjører IP-flytkontroll, og den sier Access allowed, så saken lukkes som et VPN-problem. Det resultatet betyr ikke det det ser ut som, fordi IP-flytkontroll vurderer sikkerhetsreglene for flyten du beskrev og tester aldri om Azure har en rute til det lokale prefikset ditt.

Filtreringsspørsmålet og rutingsspørsmålet er atskilt, og Network Watcher svarer på dem med ulike verktøy. Å vite hvilket du stilte er det meste av diagnosen.

Hva IP-flytkontroll faktisk avgjør

IP-flytkontroll tar en VM, en nettverksgrensesnitt, en retning, femtuppel-verdier og en protokoll og rapporterer deretter NSG- og sikkerhetsadministratorregelens avgjørelse for den flyten. Den virker på TCP og UDP, så den er ikke en ICMP-regeltester, og en blokkert ping beviser ingenting om tjenesten din. Gi den den ekte flyten i stedet for en gjetning. En innkommende tilkobling fra det lokale nettet til en databaseport er en annen beskrivelse enn en utgående tilkobling som VM-en starter.

Hvis gatewayen oversetter adresser, bruk kildeadressen som når grensen du vurderer, ikke den i klientkonfigurasjonen. Les også resultatet for det det er. Access allowed betyr at filtreringslaget ville tillatt pakken hvis den ankom, og ikke noe mer.

Det den ikke kan fortelle deg, er ruten Azure valgte, om gjestefirewallen tillater porten, eller om noe lytter. Det lever i andre lag.

Hva neste hopp og effektive ruter tilfører

Neste hopp svarer på et videresendingsspørsmål: for denne destinasjonen, hvilken neste-hopp-type Azure velger, på hvilken adresse, fra hvilken rutetabell. Effektive ruter lister opp hva NIC-en faktisk har. Kjør begge, og du får Azure-sidens sti som en grønn IP-flytkontroll lar stå tom.

Microsofts oversikt over IP-flytkontroll angir filtreringsomfanget direkte, mens sidene om neste hopp og rutediagnose dekker videresendingssiden. Siter riktig side når du skriver funnet.

Kommandoene er korte nok til å kjøres fra et skall. az network nic show-effective-route-table viser rutene som er brukt på grensesnittet. az network watcher show-next-hop med en kilde og en destinasjon returnerer det valgte hoppet. Sammenlign prefikset du bryr deg om med den tabellen, og bekreft deretter hvilken oppføring som vinner.

Gå returveien fra NIC-en til VM-en

Gjør dette fra NIC-en til mål-VM-en, for det lokale klientprefikset, ikke for internett. Returveien er der nettsted-til-nettsted-feil skjuler seg, fordi en tunnelstatuskontroll bare rapporterer at sikkerhetstilknytningene er oppe.

Hvis den forventede ruten mangler, sjekk fjernprefiksene gatewaykonfigurasjonen leverer, VNet-tilkoblingsdesignet og enhver ruteutbredelsesinnstilling. Et lokalt nettverksgateway-objekt beskriver den lokale siden; at det finnes beviser ikke at hvert påkrevde prefiks er til stede og foretrukket på NIC-en. Det er forskjellige fakta, og bare ett av dem vises i et portalsammendrag.

Les neste-hopp-typen i stedet for å kopiere et eksempel

En sti gjennom en administrert VPN-gateway viser vanligvis VirtualNetworkGateway som neste-hopp-type. VirtualAppliance beskriver et annet videresendingsdesign, vanligvis en brannmur eller et virtuelt nettverksapparat.

Ikke opprett en apparatrute mot et gjettet VPN-endepunkt fordi et gammelt forumssvar brukte den typen. Hvis en brukerdefinert rute overstyrer den tiltenkte stien, finn eieren og formålet før du endrer den. En andre NIC kan også endre hvilket grensesnitt gjesten bruker, og å fjerne den kan ødelegge en annen tjeneste i stedet for å reparere denne ruten.

Flytt deg til grensen som fortsatt feiler

Når filtrering og ruting begge samsvarer med designet, er feilen et annet sted. Sjekk gjestens egen rutetabell, brannmuren og om lytteren er bundet til den forventede adressen. Sjekk deretter VPN-ens beskyttede trafikkvelgere og den lokale svarveien. Hver av dem er en egen test med et eget resultat.

Avslutt med en tillatt applikasjonsforespørsel og observasjoner fra begge ender. Et allow-resultat og et riktig neste hopp er to biter bevis, ikke bevis for at tilkoblingen lyktes.