Azure site-til-site VPN med peer bak NAT: sjekkliste

Gå gjennom disse sjekkene i rekkefølge og stopp ved den første som feiler. De fleste rapportene om at Azure ikke støtter en enhet bak NAT viser seg å være en peer-adresse Azure ikke når, eller en tunnel som aldri initieres fra riktig side. Den ytre transporten og den indre rutingen er to forskjellige problemer, og å blande dem koster en ettermiddag. Hvert trinn nedenfor gir en observasjon du kan overlate til noen andre.

Trinn 1: bekreft at peeren i det hele tatt er bak NAT

Sammenlign adressen på enhetens WAN-grensesnitt med adressen Azure ser for den. Hvis de er forskjellige, oversetter noe, og den oversetteren er nå en del av VPN-designet ditt. Spør leverandøren om mappingen er statisk eller delt, fordi en delt mapping endrer hva du kan regne med. En enhet med privat WAN-adresse og uten videresending er et annet tilfelle enn en bak en carrier-grade NAT med en stabil offentlig mapping.

Hvis de to adressene stemmer, stopp her: NAT er ikke problemet ditt, og resten av listen hjelper ikke.

Skriv begge adressene og modellen til oversetteren i saken. Den ene linjen forhindrer neste runde med spørsmål om hvorfor den konfigurerte peeren ikke svarer.

Trinn 2: bli enige om hvem som initierer

Azure VPN Gateway FAQ oppgir støtte for NAT-T og legger til at den lokale enheten bør initiere IPsec-tunnelen når den står bak NAT. Det stemmer med hvordan tilstandsbasert oversettelse virker, siden oversetteren holder en mapping fordi den indre enheten sendte den første pakken. Hvis Azure forventes å initiere og ingenting kommer for å lage den mappingen, starter tunnelen aldri.

Konfigurer peeren slik at en kun-svarer-feil er tydelig, og sjekk om enheten prøver igjen av seg selv eller trenger en utløser. Noen enheter reiser først en tunnel når interessant trafikk dukker opp, noe som er greit helt til den interessante trafikken er en helseprobe som aldri kommer.

Følg med på IKE-utvekslingen på enheten under en manuell initiering; stillhet der er et ruting- eller brannmursvar, ikke et Azure-svar.

Trinn 3: få peer-adressen riktig

Azure trenger en tilgjengelig offentlig adresse for peeren i objektet for det lokale nettverksgatewayet, vanligvis oversetterens offentlige adresse framfor enhetens indre adresse. Identiteten enheten autentiserer seg med er et eget felt og kan med rette avvike fra adressen Azure ringer. Hold de to fra hverandre, fordi å bytte dem gir en autentiseringsfeil som ser nøyaktig ut som et NAT-problem.

Hvis den offentlige adressen endres, må det objektet endres med den. Et navn som løses til en utdatert adresse er verre enn en statisk adresse du må oppdatere manuelt.

Skriv ned alle tre verdiene: enhetens lokale adresse, den oversatte offentlige adressen og den konfigurerte peer-identiteten.

Trinn 4: åpne bare portene NAT-T trenger

NAT-T bærer ESP inne i UDP, og RFC 3948 beskriver den innkapslingen med port 4500 brukt etter den innledende forhandlingen på port 500. Brannmuren din og oversetteren må begge tillate utvekslingen og returtrafikken. Å tillate en uvedkommende TCP-port beviser ingenting om denne veien, og en regel som tillater utgående men ikke svaret vil fortsatt feile.

Statisk videresending av inngående port er ikke automatisk nødvendig når peeren initierer og oversetteren holder tilstand. Det blir nødvendig når mappingen er ustabil eller når noe på veien utløper tilstanden aggressivt.

Ta opp på begge sider av oversetteren én gang; forskjellen i innkapsling er umiddelbart synlig.

Trinn 5: skill ytre transport fra indre ruting

En tunnel som etableres og ikke bærer noe, er et rutingproblem, ikke et NAT-T-problem. Nettstedene trenger fortsatt kompatible trafikkvelgere, samsvarende adresseområder, tilgangsregler og en returvei for applikasjonsnettene. Ingenting av dette leveres av en vellykket IKE-utveksling.

Hvis de to nettstedene bruker overlappende private områder, er oversettelse inne i tunnelen et eget design med egne regler. Ikke omnummerer et subnett bare fordi den ytre gatewayen tilfeldigvis står bak en hjemmeruter.

Klassifiser feilen etter trinn før du endrer noe, og behold klassifiseringen i saken slik at neste person starter der du stoppet.