IP-flytkontrollen i Azure seier tillate, men VPN-en feilar framleis

Nettstad-til-nettstad-tunnelen er tilkopla, VM-en er frisk, men den lokale klienten får ingenting. Du opnar Network Watcher, køyrer IP-flytkontroll, og han seier Access allowed, så saka vert lukka som eit VPN-problem. Det resultatet tyder ikkje det det ser ut som, fordi IP-flytkontroll vurderer tryggingsreglane for flyten du skildra og testar aldri om Azure har ei rute til det lokale prefikset ditt.

Filtreringsspørsmålet og rutingsspørsmålet er skilde, og Network Watcher svarar på dei med ulike verktøy. Å vite kva du spurde om er det meste av diagnosen.

Kva IP-flytkontroll faktisk avgjer

IP-flytkontroll tek ein VM, eit nettverksgrensesnitt, ei retning, femtuppelverdiar og ein protokoll og rapporterer deretter avgjerda til NSG- og tryggingsadministratorregelen for den flyten. Han verkar på TCP og UDP, så han er ikkje ein ICMP-regeltestar, og ein blokkert ping beviser ingenting om tenesta di. Gi han den ekte flyten i staden for ei gissing. Ei innkomande tilkopling frå det lokale nettet til ein databaseport er ei anna skildring enn ei utgåande tilkopling som VM-en startar.

Viss gatewayen omset adresser, bruk kjeldeadressa som når grensa du vurderer, ikkje den i klientkonfigurasjonen. Les òg resultatet for det det er. Access allowed tyder at filtreringslaget ville sleppe pakken gjennom om han kom, og ikkje noko meir.

Det han ikkje kan fortelje deg, er ruta Azure valde, om gjestebrannmuren tillèt porten, eller om noko lyttar. Det lever i andre lag.

Kva neste hopp og effektive ruter legg til

Neste hopp svarar på eit videresendingsspørsmål: for denne destinasjonen kva neste-hopp-type Azure vel, på kva adresse, frå kva rutetabell. Effektive ruter listar opp kva NIC-en faktisk har. Køyr begge, og du får stien på Azure-sida som ein grøn IP-flytkontroll lèt stå tom.

Microsofts oversikt over IP-flytkontroll oppgir filtreringsomfanget direkte, medan sidene om neste hopp og rutediagnose dekkjer videresendingssida. Siter rett side når du skriv funnet.

Kommandoane er korte nok til å køyre frå eit skal. az network nic show-effective-route-table viser rutene som er brukte på grensesnittet. az network watcher show-next-hop med ei kjelde og ein destinasjon returnerer det valde hoppet. Samanlikn prefikset du bryr deg om med den tabellen, og stadfest deretter kva oppføring som vinn.

Gå returvegen frå NIC-en til VM-en

Gjer dette frå NIC-en til mål-VM-en, for det lokale klientprefikset, ikkje for internett. Returvegen er der nettstad-til-nettstad-feil gøymer seg, fordi ein tunnelstatuskontroll berre rapporterer at tryggingskoplingane er oppe.

Viss den venta ruta manglar, sjekk fjernprefiksa gatewaykonfigurasjonen leverer, VNet-tilkoplingsdesignet og kvar ruteutbreiingsinnstilling. Eit lokalt nettverksgateway-objekt skildrar den lokale sida; at det finst beviser ikkje at kvart kravde prefiks er til stades og føretrekte på NIC-en. Det er ulike fakta, og berre eitt av dei viser seg i eit portalsamandrag.

Les neste-hopp-typen i staden for å kopiere eit døme

Ein sti gjennom ein administrert VPN-gateway viser vanlegvis VirtualNetworkGateway som neste-hopp-type. VirtualAppliance skildrar eit anna videresendingsdesign, vanlegvis ein brannmur eller eit virtuelt nettverksapparat.

Ikkje opprett ei apparatrute mot eit gjett VPN-endepunkt fordi eit gamalt forumssvar brukte den typen. Viss ei brukardefinert rute overstyrer den tiltenkte stien, finn eigaren og føremålet før du endrar ho. Eit andre NIC kan òg endre kva grensesnitt gjesten brukar, og å fjerne det kan øydeleggje ei anna teneste i staden for å reparere denne ruta.

Flytt deg til grensa som framleis feilar

Når filtrering og ruting båe samsvarar med designet, er feilen ein annan stad. Sjekk gjestens eigen rutetabell, brannmuren og om lyttaren er bunden til den venta adressa. Sjekk deretter dei verna trafikkveljarane til VPN-en og den lokale svarvegen. Kvar av dei er ein eigen test med eit eige resultat.

Avslutt med ein tillaten applikasjonsførespurnad og observasjonar frå båe endar. Eit allow-resultat og eit rett neste hopp er to bitar bevis, ikkje bevis for at tilkoplinga lukkast.