A verificación de fluxo IP de Azure di permitido, pero a VPN segue fallando

Túnel de sitio a sitio conectado, VM saudable, o cliente local non recibe nada. Abres Network Watcher, executas a verificación de fluxo IP e di Access allowed, así que o ticket péchase como un problema de VPN. Ese resultado non significa o que parece, porque a verificación de fluxo IP avalía as regras de seguridade do fluxo que describiches e nunca comproba se Azure ten unha ruta ao teu prefixo local.

A pregunta de filtrado e a pregunta de encamiñamento son distintas, e Network Watcher respóndeas con ferramentas diferentes. Saber cal fixeches é a maior parte do diagnóstico.

Que decide realmente a verificación de fluxo IP

A verificación de fluxo IP toma unha VM, unha interface de rede, unha dirección, valores da quíntupla e un protocolo, e despois informa a decisión da regra NSG e do administrador de seguridade para ese fluxo. Funciona con TCP e UDP, así que non é un probador de regras ICMP e un ping bloqueado non demostra nada sobre o teu servizo. Dállle o fluxo real en lugar dunha suposición. Unha conexión entrante desde o local a un porto de base de datos é unha descrición distinta dunha conexión saínte que inicia a VM.

Se a pasarela traduce enderezos, usa o enderezo de orixe que chega á fronteira que avalías, non o da configuración do cliente. Le o resultado polo que é, tamén. Access allowed significa que a capa de filtrado permitiría o paquete se chegase, e nada máis.

O que non pode dicirche é a ruta que escolleu Azure, se o firewall do convidado permite o porto ou se algo está escoitando. Iso vive noutras capas.

Que engaden o seguinte salto e as rutas efectivas

O seguinte salto responde unha pregunta de reenvío: para este destino, que tipo de seguinte salto escolle Azure, en que enderezo, desde que táboa de rutas. As rutas efectivas listan o que a NIC ten realmente. Executa ambos e obterás o camiño do lado de Azure que unha verificación de fluxo IP verde deixa en branco.

A visión xeral da verificación de fluxo IP de Microsoft indica o alcance do filtrado directamente, mentres que as páxinas de seguinte salto e diagnóstico de rutas cobren o lado do reenvío. Cita a páxina correcta cando escribas o achado.

As ordes son abondo curtas para executalas desde un shell. az network nic show-effective-route-table lista as rutas aplicadas á interface. az network watcher show-next-hop cunha orixe e un destino devolve o salto seleccionado. Compara o prefixo que che importa con esa táboa e despois confirma que entrada gaña.

Percorre o camiño de volta desde a NIC da VM

Faino desde a NIC da VM obxectivo, para o prefixo do cliente local, non para internet. O camiño de volta é onde se esconden as fallas de sitio a sitio, porque unha comprobación de estado do túnel só informa de que as asociacións de seguridade están activas.

Se falta a ruta esperada, revisa os prefixos remotos que proporciona a configuración da pasarela, o deseño de conectividade da VNet e calquera axuste de propagación de rutas. Un obxecto de pasarela de rede local describe o lado local; a súa existencia non demostra que todos os prefixos necesarios estean presentes e se prefiran na NIC. Son feitos distintos, e só un deles aparece nun resumo do portal.

Le o tipo de seguinte salto en lugar de copiar un exemplo

Un camiño de pasarela VPN xestionada normalmente mostra VirtualNetworkGateway como tipo de seguinte salto. VirtualAppliance describe un deseño de reenvío distinto, normalmente un firewall ou un aparello de rede virtual.

Non crees unha ruta de aparello apuntando a un punto de conexión VPN supuesto porque unha resposta antiga dun foro usou ese tipo. Se unha ruta definida polo usuario substitúe o camiño previsto, atopa o seu propietario e o seu propósito antes de cambiala. Unha segunda NIC tamén pode cambiar que interface usa o convidado, e quitala pode romper outro servizo en lugar de arranxar esta ruta.

Pasa á fronteira que aínda falla

Cando o filtrado e o encamiñamento coinciden co deseño, a falla está noutro lugar. Revisa a táboa de rutas do propio convidado, o seu firewall e se o escoitante está ligado ao enderezo esperado. Despois revisa os selectores de tráfico protexido da VPN e o camiño de resposta local. Cada unha delas é unha proba separada cun resultado separado.

Pecha cunha solicitude de aplicación permitida e observacións desde ambos extremos. Un resultado allow e un seguinte salto correcto son dúas pezas de evidencia, non a proba de que a conexión tivese éxito.