VPN de lloc a lloc a Azure amb un par darrere de NAT: llista de comprovació

Feu aquestes comprovacions en ordre i atureu-vos a la primera que falli. La majoria d’informes que asseguren que Azure no admet un dispositiu darrere de NAT resulten ser una adreça de par a què Azure no pot arribar, o un túnel que mai s’inicia des del costat correcte. El transport exterior i l’encaminament interior són dos problemes diferents, i barrejar-los fa perdre una tarda. Cada pas següent produeix una observació que podeu lliurar a una altra persona.

Pas 1: confirmeu que el par és realment darrere de NAT

Compareu l’adreça de la interfície WAN del dispositiu amb l’adreça que Azure veu per a ell. Si són diferents, alguna cosa està traduint, i aquest traductor ja forma part del vostre disseny de VPN. Pregunteu al proveïdor si la mapping és estàtica o compartida, perquè una mapping compartida canvia allò en què podeu confiar. Un dispositiu amb adreça WAN privada i sense reenviament és un cas diferent d’un de darrere d’un NAT de nivell operador amb una mapping pública estable.

Si les dues adreces coincideixen, atureu-vos aquí: NAT no és el vostre problema i la resta d’aquesta llista no us ajudarà.

Anoteu les dues adreces i el model del traductor al tiquet. Aquesta sola línia evita la propera ronda de preguntes sobre per què el par configurat no respon.

Pas 2: poseu-vos d’acord sobre qui inicia

Les preguntes freqüents de la passarel·la VPN d’Azure indiquen el suport de NAT-T i afegeixen que el dispositiu local ha d’iniciar el túnel IPsec quan és darrere de NAT. Això encaixa amb com funciona la traducció amb estat, ja que el traductor manté una mapping perquè el dispositiu interior va enviar el primer paquet. Si s’espera que Azure iniciï i no arriba res que creï aquesta mapping, el túnel no s’inicia mai.

Configureu el par de manera que un error de només responedor sigui evident, i comproveu si el dispositiu reintenta per si sol o necessita un desencadenant. Alguns dispositius només aixequen un túnel quan apareix trànsit interessant, cosa que va bé fins que el trànsit interessant és una sonda de salut que no arriba mai.

Observeu l’intercanvi IKE al dispositiu durant un inici manual; el silenci aquí és una resposta d’encaminament o de tallafoc, no una resposta d’Azure.

Pas 3: encerta l’adreça del par

Azure necessita una adreça pública assolible per al par al seu objecte de passarel·la de xarxa local, normalment l’adreça pública del traductor en lloc de l’adreça interior del dispositiu. La identitat amb què s’autentica el dispositiu és un camp a part i pot diferir legítimament de l’adreça que Azure marca. Mantingueu les dues ben separades, perquè intercanviar-les produeix un error d’autenticació que sembla exactament un problema de NAT.

Si l’adreça pública canvia, aquest objecte ha de canviar amb ella. Un nom que resol a una adreça obsoleta és pitjor que una adreça estàtica que hàgiu d’actualitzar a mà.

Anoteu els tres valors: adreça local del dispositiu, adreça pública traduïda i identitat del par configurada.

Pas 4: obriu només els ports que NAT-T necessita

NAT-T transporta ESP dins d’UDP, i l’RFC 3948 descriu aquest encapsulament amb el port 4500 usat després de la negociació inicial al port 500. El vostre tallafoc i el traductor han de permetre l’intercanvi i el seu trànsit de retorn. Permetre un port TCP no relacionat no demostra res sobre aquest camí, i una regla que permet la sortida però no la resposta encara fallarà.

Un reenviament de port entrant estàtic no és obligatori automàticament quan el par inicia i el traductor manté estat. Esdevé necessari quan la mapping és inestable o quan alguna cosa al camí fa caducar l’estat agressivament.

Captureu una vegada als dos costats del traductor; la diferència d’encapsulament es veu de seguida.

Pas 5: separeu el transport exterior de l’encaminament interior

Un túnel que s’estableix i no transporta res és un problema d’encaminament, no de NAT-T. Els llocs encara necessiten selectors de trànsit compatibles, espais d’adreces coincidents, regles d’accés i un camí de retorn per a les xarxes d’aplicacions. Res d’això no ho proporciona un intercanvi IKE correcte.

Si els dos llocs fan servir rangs privats superposats, la traducció dins del túnel és un disseny a part amb les seves pròpies regles. No renombreu una subxarxa només perquè la passarel·la exterior estigui darrere d’un encaminador domèstic.

Classifiqueu la fallada per etapa abans de canviar res, i manteniu aquesta classificació al tiquet perquè la propera persona comenci on vosaltres us heu aturat.