Azure site-til-site VPN med peer bag NAT: tjekliste

Gennemfør disse tjek i rækkefølge og stop ved det første, der fejler. De fleste rapporter om, at Azure ikke understøtter en enhed bag NAT, viser sig at være en peer-adresse, Azure ikke kan nå, eller en tunnel, der aldrig initieres fra den rigtige side. Den ydre transport og den indre routing er to forskellige problemer, og at blande dem spilder en eftermiddag. Hvert trin nedenfor giver en observation, du kan give videre til en anden.

Trin 1: bekræft, at peeren overhovedet er bag NAT

Sammenlign adressen på enhedens WAN-grænseflade med den adresse, Azure ser for den. Hvis de er forskellige, er noget ved at oversætte, og den oversætter er nu en del af dit VPN-design. Spørg udbyderen, om mappingen er statisk eller delt, fordi en delt mapping ændrer, hvad du kan regne med. En enhed med en privat WAN-adresse og uden videresendelse er et andet tilfælde end en bag en carrier-grade NAT med en stabil offentlig mapping.

Hvis de to adresser matcher, så stop her: NAT er ikke dit problem, og resten af listen hjælper ikke.

Skriv begge adresser og oversætterens model i sagen. Den ene linje forhindrer den næste runde spørgsmål om, hvorfor den konfigurerede peer ikke svarer.

Trin 2: bliv enige om, hvem der initierer

Azure VPN Gateway FAQ angiver understøttelse af NAT-T og tilføjer, at den lokale enhed bør initiere IPsec-tunnelen, når den er bag NAT. Det stemmer med, hvordan stateful oversættelse virker, da oversætteren holder en mapping, fordi den indre enhed sendte den første pakke. Hvis Azure forventes at initiere, og der ikke kommer noget, der skaber mappingen, starter tunnelen aldrig.

Konfigurer peeren, så en kun-svarer-fejl er tydelig, og tjek, om enheden prøver igen af sig selv eller har brug for et trigger. Nogle enheder rejser først en tunnel, når der kommer interessant trafik, hvilket er fint, indtil den interessante trafik er en sundhedsprobe, der aldrig kommer.

Hold øje med IKE-udvekslingen på enheden under en manuel initiering; tavshed der er et routing- eller firewall-svar, ikke et Azure-svar.

Trin 3: få peer-adressen rigtig

Azure skal have en tilgængelig offentlig adresse til peeren i sit lokale netværksgateway-objekt, normalt oversætterens offentlige adresse frem for enhedens indre adresse. Den identitet, enheden godkender sig med, er et separat felt og kan med rette afvige fra den adresse, Azure ringer til. Hold de to adskilt, fordi at bytte dem giver en godkendelsesfejl, der ligner et NAT-problem præcis.

Hvis den offentlige adresse ændrer sig, skal objektet ændre sig med den. Et navn, der opløses til en forældet adresse, er værre end en statisk adresse, du selv skal opdatere.

Skriv alle tre værdier ned: enhedens lokale adresse, den oversatte offentlige adresse og den konfigurerede peer-identitet.

Trin 4: åbn kun de porte, NAT-T har brug for

NAT-T bærer ESP inde i UDP, og RFC 3948 beskriver den indkapsling med port 4500 brugt efter den indledende forhandling på port 500. Din firewall og oversætteren skal begge tillade udvekslingen og dens returtrafik. At tillade en uvedkommende TCP-port beviser intet om denne vej, og en regel, der tillader udgående, men ikke svaret, fejler stadig.

Videresendelse af en statisk indgående port er ikke automatisk påkrævet, når peeren initierer, og oversætteren holder tilstand. Den bliver nødvendig, når mappingen er ustabil, eller når noget på vejen udløber tilstand aggressivt.

Optag på begge sider af oversætteren én gang; forskellen i indkapsling er straks synlig.

Trin 5: adskil ydre transport fra indre routing

En tunnel, der etableres og ikke bærer noget, er et routingproblem, ikke et NAT-T-problem. Siderne har stadig brug for kompatible trafikvælgere, matchende adresseområder, adgangsregler og en returvej for applikationsnetværkene. Intet af det leveres af en vellykket IKE-udveksling.

Hvis de to sider bruger overlappende private områder, er oversættelse inde i tunnelen et separat design med sine egne regler. Omdøb ikke et subnet, bare fordi den ydre gateway tilfældigvis står bag en hjemmerouter.

Klassificér fejlen efter trin, før du ændrer noget, og behold den klassificering i sagen, så den næste person starter, hvor du stoppede.