La verificació de flux IP d’Azure diu permès, però la VPN continua fallant

Túnel lloc a lloc connectat, VM saludable, el client local no rep res. Obres Network Watcher, executes la verificació de flux IP i diu Access allowed, així que el tiquet es tanca com un problema de VPN. Aquest resultat no significa el que sembla, perquè la verificació de flux IP avalua les regles de seguretat del flux que has descrit i mai no comprova si Azure té una ruta cap al teu prefix local.

La pregunta de filtratge i la pregunta d’encaminament són separades, i Network Watcher les respon amb eines diferents. Saber quina has fet és la major part del diagnòstic.

Què decideix realment la verificació de flux IP

La verificació de flux IP pren una VM, una interfície de xarxa, una direcció, valors de la quíntuple i un protocol, i després informa de la decisió de les regles NSG i d’administrador de seguretat per a aquest flux. Funciona amb TCP i UDP, així que no és un provador de regles ICMP i un ping bloquejat no demostra res sobre el teu servei. Dona-li el flux real en lloc d’una suposició. Una connexió entrant des del lloc local cap a un port de base de dades és una descripció diferent d’una connexió sortint que inicia la VM.

Si la passarel·la tradueix adreces, fes servir l’adreça d’origen que arriba a la frontera que avalues, no la que hi ha a la configuració del client. Llegeix el resultat pel que és, també. Access allowed vol dir que la capa de filtratge permetria el paquet si arribés, i res més.

El que no et pot dir és la ruta que ha triat Azure, si el tallafoc del convidat permet el port o si hi ha algú escoltant. Això viu en altres capes.

Què hi afegeixen el següent salt i les rutes efectives

El següent salt respon una pregunta de reenviament: per a aquesta destinació, quin tipus de següent salt tria Azure, a quina adreça, des de quina taula de rutes. Les rutes efectives llisten el que la NIC té realment. Executa tots dos i obtindràs el camí del costat d’Azure que una verificació de flux IP verda deixa en blanc.

La visió general de la verificació de flux IP de Microsoft indica directament l’abast del filtratge, mentre que les pàgines de següent salt i de diagnòstic de rutes cobreixen el costat del reenviament. Cita la pàgina correcta quan escriguis la conclusió.

Les ordres són prou curtes per executar-les des d’un shell. az network nic show-effective-route-table llista les rutes aplicades a la interfície. az network watcher show-next-hop amb un origen i una destinació retorna el salt seleccionat. Compara el prefix que t’interessa amb aquesta taula i després confirma quina entrada guanya.

Recorre el camí de tornada des de la NIC de la VM

Fes-ho des de la NIC de la VM objectiu, per al prefix del client local, no per a internet. El camí de tornada és on s’amaguen les fallades lloc a lloc, perquè una comprovació d’estat del túnel només informa que les associacions de seguretat estan actives.

Si falta la ruta esperada, comprova els prefixos remots que proporciona la configuració de la passarel·la, el disseny de connectivitat de la VNet i qualsevol paràmetre de propagació de rutes. Un objecte de passarel·la de xarxa local descriu el costat local; la seva existència no demostra que tots els prefixos necessaris hi siguin i es prefereixin a la NIC. Són fets diferents, i només un d’ells apareix en un resum del portal.

Llegeix el tipus de següent salt en lloc de copiar un exemple

Un camí de passarel·la VPN gestionada normalment mostra VirtualNetworkGateway com a tipus de següent salt. VirtualAppliance descriu un disseny de reenviament diferent, normalment un tallafoc o un aparell de xarxa virtual.

No creïs una ruta d’aparell apuntant a un punt de connexió VPN suposat perquè una resposta antiga d’un fòrum feia servir aquest tipus. Si una ruta definida per l’usuari substitueix el camí previst, troba’n el propietari i el propòsit abans de canviar-la. Una segona NIC també pot canviar quina interfície fa servir el convidat, i treure-la pot trencar un altre servei en lloc d’arreglar aquesta ruta.

Passa a la frontera que encara falla

Quan el filtratge i l’encaminament coincideixen amb el disseny, la fallada és en un altre lloc. Comprova la taula de rutes del mateix convidat, el seu tallafoc i si l’oient està lligat a l’adreça esperada. Després comprova els selectors de trànsit protegit de la VPN i el camí de resposta local. Cadascuna d’aquestes és una prova separada amb un resultat separat.

Tanca amb una petició d’aplicació permesa i observacions des dels dos extrems. Un resultat d’allow i un següent salt correcte són dues peces d’evidència, no la prova que la connexió s’hagi establert.