VPN S2S de Azure conectada pero sen tráfico: lea o rexistro IKE

O portal di Connected, o túnel ten un contador de tempo de actividade e un trace desde a súa máquina virtual morre no segundo salto. O estado da conexión describe a negociación de IKE e IPsec, non se un só paquete sobrevive á capa de políticas en calquera dos dous lados. Dous fallos explican a maioría destes tickets, e ningún se repara cambiando unha ruta de Azure. Ambos xa están escritos no rexistro que xerou a pasarela, e por iso comezo alí e non na táboa de rutas.

Que certifica realmente Connected

Unha conexión de sitio a sitio conectada significa que a fase 1 e a fase 2 se completaron e que as asociacións de seguridade están activas. É unha afirmación sobre a negociación: ambas as partes acordaron unha proposta, intercambiaron claves e instalaron o par de SA. Non di nada sobre se os selectores de tráfico coinciden coas subredes que vostede cre protexidas, nin sobre se o lado remoto encamiñará o paquete a algún sitio despois de descifralo. Un túnel pode manterse activo durante semanas mentres descarta cada fluxo interesante, e ese é exactamente o patrón que fai que a xente reconstrua unha pasarela sa.

Os dous fallos que convén revisar primeiro son un par que propón AH en lugar de ESP, e unha rede virtual numerada nun espazo que a pasarela non tratará como interno.

Abra o rexistro exportado antes de tocar rutas

No portal, abra a pasarela de rede virtual e execute a operación VPN troubleshoot sobre a conexión, logo descargue o paquete que xera e descomprímao. Dentro hai un rexistro IKE cos intercambios de fase 1 e fase 2, con marcas de tempo e lexible como texto plano. Búscao pola liña transform en lugar de lelo de arriba abaixo, porque a entrada interesante adoita estar uns centos de liñas máis adiante. Se non ten acceso ao portal, os mesmos diagnósticos aparecen no destino de rexistros da pasarela cando os axustes de diagnóstico están habilitados.

Dúas entradas achegan a maior parte do valor. A primeira di aproximadamente expected ESP with combined authentication and cipher, received AH. A segunda é un erro de payload non válido durante o intercambio IKE, que normalmente significa un campo de proposta mal formado ou non admitido.

Ambas describen o que ofreceu o dispositivo local, así que ambas son axustes do lado do par. Rexenerar o lado de Azure da conexión non cambia a proposta que envía o seu cortafogos, e facelo de todos os xeitos é a hora máis desperdiciada neste fluxo de traballo. No par, poña a fase 2 en ESP con autenticación e cifrado combinados e déixea negociar o algoritmo, logo comprobe se unha caixa do fabricante cun nome como combined mode está seleccionando en silencio unha proposta AH por debaixo.

Confirme o espazo de enderezos da rede virtual

A pasarela espera que a rede virtual estea en rangos privados. Unha rede numerada nun bloque público, por exemplo unha que comeza por 111.x, pode levantar o túnel mentres Azure se nega a tratar ese espazo como interno, así que a conexión parece sa e non se acepta ningún fluxo. Confirme o espazo de enderezos antes de pasar unha tarde cos selectores. Se a numeración é un requisito estrito dunha asignación antiga, a solución é un cambio do plan de enderezos e non outra pasarela.

Anote o solapamento cos rangos locais mentres está na folla de espazo de enderezos, porque os prefixos solapados producen un fallo distinto que desde o cliente parece similar.

Verifique os prefixos en ambas as direccións

O recurso de pasarela de rede local contén os prefixos locais, e deben coincidir coas subredes que o dispositivo remoto protexe realmente. Un resumo que inclúa enderezos que o dispositivo descarta deixará pasar algúns fluxos e fallará noutros, o que se le como un fallo de encamiñamento intermitente e non como un desaxuste de configuración. Revise tamén o lado remoto: un extremo que lista unha /16 mentres o outro lista tres /24 dentro dela é o fallo parcial clásico. Ningunha lista é autoritativa por si soa, así que compáreas unha ao lado da outra en lugar de confiar na que pode ver.

Un cambio de prefixo non sempre se recolle só, así que planifique volver gardar ou recrear o obxecto de conexión e logo confirme que os novos prefixos aparecen en ambos os lados.

Probe unha ruta, non un ping

O trace que separa un túnel que funciona dunha ruta que funciona é así: o primeiro salto é a pasarela local, logo uns cantos saltos que non responden e logo responde o host remoto. Se o trace nunca chega ao host, probe o porto TCP que a aplicación usa realmente, porque o ICMP se filtra con frecuencia suficiente como para que un ping fallido demostre moi pouco. Execute o mesmo trace desde un host remoto cara a unha máquina virtual en Azure. A asimetría entre os dous resultados é a forma máis rápida de atopar unha ruta de retorno que falta ou unha regra que só permite unha dirección.

Escriba a proposta do par, ambos os espazos de enderezos e a hora de creación da conexión no ticket, para que o seguinte enxeñeiro saiba que valores se reconstruíron e cales nunca se tocaron.

Se o rexistro volve baleiro, pode que a pasarela non estea terminando a súa conexión en absoluto. Confirme que o enderezo do par na pasarela de rede local coincide co dispositivo desde o que le o rexistro, porque dúas pasarelas nunha subscrición confúndense con facilidade durante unha reconstrución. Ese erro custa un día e non deixa rastro en ningún rexistro.