S2S VPN a l’Azure connectat però sense trànsit: llegiu el registre IKE

El portal diu Connected, el túnel té un comptador de temps de funcionament i una traça des de la vostra màquina virtual mor al segon salt. L’estat de la connexió descriu la negociació IKE i IPsec, no si un sol paquet sobreviu a la capa de polítiques de cap de les dues bandes. Dues fallades expliquen la majoria d’aquests tiquets i cap de les dues es repara canviant una ruta de l’Azure. Totes dues ja són escrites al registre que va produir la passarel·la, i per això començo aquí i no a la taula de rutes.

Què certifica realment Connected

Una connexió site-to-site connectada vol dir que les fases 1 i 2 s’han completat i que les associacions de seguretat estan actives. Això és una afirmació sobre la negociació: les dues parts van acordar una proposta, van intercanviar claus i van instal·lar la parella d’SA. No diu res sobre si els selectors de trànsit coincideixen amb les subxarxes que creieu protegides, ni sobre si la banda remota encaminarà el paquet enlloc després de desxifrar-lo. Un túnel pot estar actiu durant setmanes mentre descarta cada flux interessant, i aquest és exactament el patró que fa que la gent refaci una passarel·la sana.

Les dues fallades que val la pena comprovar primer són una part remota que proposa AH en lloc d’ESP, i una xarxa virtual numerada en un espai que la passarel·la no tractarà com a intern.

Obriu el registre exportat abans de tocar rutes

Al portal, obriu la passarel·la de xarxa virtual i executeu l’operació VPN troubleshoot sobre la connexió, després descarregueu el paquet que genera i descomprimiu-lo. A dins hi ha un registre IKE amb els intercanvis de fase 1 i fase 2, amb marca de temps i llegible com a text pla. Cerqueu-hi la línia transform en lloc de llegir de dalt a baix, perquè l’entrada interessant sol ser unes quantes centenes de línies més avall. Si no teniu accés al portal, els mateixos diagnòstics apareixen a la destinació de registres de la passarel·la quan els paràmetres de diagnòstic estan activats.

Dues entrades aporten la major part del valor. La primera diu aproximadament expected ESP with combined authentication and cipher, received AH. La segona és un error de payload no vàlid durant l’intercanvi IKE, que normalment significa un camp de proposta mal format o no suportat.

Totes dues descriuen què va oferir el dispositiu local, així que totes dues són paràmetres de la banda remota. Regenerar la banda Azure de la connexió no canvia la proposta que envia el vostre tallafoc, i fer-ho igualment és l’hora més malgastada habitual en aquest flux. A la part remota, poseu la fase 2 a ESP amb autenticació i xifratge combinats i deixeu que negociï l’algorisme, després comproveu si una casella del fabricant amb un nom com combined mode selecciona en silenci una proposta AH a sota.

Confirmeu l’espai d’adreces de la xarxa virtual

La passarel·la espera que la xarxa virtual estigui en rangs privats. Una xarxa numerada en un bloc públic, per exemple una que comença per 111.x, pot aixecar el túnel mentre l’Azure es nega a tractar aquest espai com a intern, de manera que la connexió sembla sana i no s’accepta cap flux. Confirmeu l’espai d’adreces abans de passar una tarda amb els selectors. Si la numeració és un requisit dur d’una assignació antiga, la solució és un canvi del pla d’adreces i no una passarel·la diferent.

Anoteu el solapament amb els rangs locals mentre sigueu a la fulla d’espai d’adreces, perquè els prefixos solapats produeixen una fallada diferent que des del client sembla similar.

Verifiqueu els prefixos en les dues direccions

El recurs de passarel·la de xarxa local conté els prefixos locals, i han de coincidir amb les subxarxes que el dispositiu remot protegeix realment. Un resum que inclogui adreces que el dispositiu descarta deixarà passar alguns fluxos i en fallarà d’altres, cosa que es llegeix com una fallada d’encaminament intermitent i no com un desajust de configuració. Comproveu també la banda remota: un extrem que llista una /16 mentre l’altre llista tres /24 a dins és la fallada parcial clàssica. Cap de les dues llistes no és autoritativa per si sola, així que compareu-les costat a costat en lloc de confiar en la que podeu veure.

Un canvi de prefix no sempre es recull tot sol, així que planifiqueu tornar a desar o recrear l’objecte de connexió i després confirmeu que els prefixos nous apareixen a les dues bandes.

Proveu un camí, no un ping

La traça que separa un túnel que funciona d’una ruta que funciona és així: el primer salt és la passarel·la local, després uns quants salts que no responen i finalment l’amfitrió remot respon. Si la traça no arriba mai a l’amfitrió, proveu el port TCP que l’aplicació fa servir realment, perquè l’ICMP es filtra prou sovint perquè un ping fallit demostri ben poca cosa. Executeu la mateixa traça des d’un amfitrió remot cap a una màquina virtual de l’Azure. L’asimetria entre els dos resultats és la manera més ràpida de trobar una ruta de retorn que falta o una regla que només permet una direcció.

Escriviu la proposta de la part remota, els dos espais d’adreces i l’hora de creació de la connexió al tiquet, perquè el següent enginyer sàpiga quins valors s’han refet i quins no s’han tocat mai.

Si el registre torna buit, potser la passarel·la no està terminant la vostra connexió. Confirmeu que l’adreça de la part remota a la passarel·la de xarxa local coincideix amb el dispositiu des del qual llegiu el registre, perquè dues passarel·les en una subscripció es confonen fàcilment durant una reconstrucció. Aquest error costa un dia i no deixa rastre en cap registre.