Azure nettstad-til-nettstad-VPN med peer bak NAT: sjekkliste
NAT-T handterer dei ytre pakka, ikkje peer-adressa eller dei indre rutene. Fem ordna sjekkar skil eit omsetjingsproblem frå eit konfigurasjonsproblem.
Gå gjennom desse sjekkane i rekkjefølgje og stopp ved den første som feilar. Dei fleste rapportane om at Azure ikkje støttar ei eining bak NAT viser seg å vere ei peer-adresse Azure ikkje når, eller ein tunnel som aldri vert initiert frå rett side. Den ytre transporten og den indre rutinga er to ulike problem, og å blande dei kostar ein ettermiddag. Kvart steg nedanfor gir ei observasjon du kan overlate til nokon andre.
Steg 1: stadfest at peeren i det heile er bak NAT
Samanlikn adressa på WAN-grensesnittet til eininga med adressa Azure ser for henne. Viss dei er ulike, omset noko, og den omsetjaren er no ein del av VPN-designet ditt. Spør leverandøren om mappinga er statisk eller delt, fordi ei delt mapping endrar kva du kan rekne med. Ei eining med privat WAN-adresse og utan vidaresending er eit anna tilfelle enn ei bak ein carrier-grade NAT med ei stabil offentleg mapping.
Viss dei to adressene stemmer, stopp her: NAT er ikkje problemet ditt, og resten av lista hjelper ikkje.
Skriv begge adressene og modellen til omsetjaren i saka. Den eine linja hindrar neste runde med spørsmål om kvifor den konfigurerte peeren ikkje svarar.
Steg 2: bli samde om kven som initierer
Azure VPN Gateway FAQ oppgir støtte for NAT-T og legg til at den lokale eininga bør initiere IPsec-tunnelen når ho står bak NAT. Det stemmer med korleis tilstandsbasert omsetjing verkar, sidan omsetjaren held ei mapping fordi den indre eininga sende den første pakka. Viss Azure er venta å initiere og ingenting kjem for å lage den mappinga, startar tunnelen aldri.
Konfigurer peeren slik at ein berre-svarar-feil er tydeleg, og sjekk om eininga prøver igjen av seg sjølv eller treng ein utløysar. Nokre einingar reiser først ein tunnel når interessant trafikk dukkar opp, noko som er greitt heilt til den interessante trafikken er ein helseprobe som aldri kjem.
Fylg med på IKE-utvekslinga på eininga under ein manuell initiering; stille der er eit ruting- eller brannmursvar, ikkje eit Azure-svar.
Steg 3: få peer-adressa rett
Azure treng ei tilgjengeleg offentleg adresse for peeren i objektet for den lokale nettverksporten, vanlegvis den offentlege adressa til omsetjaren framfor den indre adressa til eininga. Identiteten eininga autentiserer seg med er eit eige felt og kan med rette avvike frå adressa Azure ringjer. Hald dei to frå kvarandre, fordi å bytte dei gir ein autentiseringsfeil som ser nøyaktig ut som eit NAT-problem.
Viss den offentlege adressa endrar seg, må det objektet endre seg med henne. Eit namn som løyser til ei utdatert adresse er verre enn ei statisk adresse du må oppdatere manuelt.
Skriv ned alle tre verdiane: lokal adresse til eininga, den omsette offentlege adressa og den konfigurerte peer-identiteten.
Steg 4: opne berre dei portane NAT-T treng
NAT-T ber ESP inne i UDP, og RFC 3948 skildrar den innkapslinga med port 4500 brukt etter den innleiande forhandlinga på port 500. Brannmuren din og omsetjaren må båe tillate utvekslinga og returtrafikken. Å tillate ein uvedkomande TCP-port provar ingenting om denne vegen, og ei regel som tillèt utgåande men ikkje svaret vil framleis feile.
Statisk vidaresending av inngåande port er ikkje automatisk naudsynt når peeren initierer og omsetjaren held tilstand. Det vert naudsynt når mappinga er ustabil eller når noko på vegen lèt tilstanden gå ut aggressivt.
Tak opp på båe sider av omsetjaren éin gong; skilnaden i innkapsling er straks synleg.
Steg 5: skil ytre transport frå indre ruting
Ein tunnel som vert etablert og ikkje ber noko, er eit rutingproblem, ikkje eit NAT-T-problem. Nettstadene treng framleis kompatible trafikkveljarar, samsvarande adresseområde, tilgangsreglar og ein returveg for applikasjonsnetta. Ingenting av dette leverer ei vellukka IKE-utveksling.
Viss dei to nettstadene brukar overlappande private område, er omsetjing inne i tunnelen eit eige design med eigne reglar. Ikkje omnummerer eit subnett berre fordi den ytre porten tilfeldigvis står bak ein heimeruttar.
Klassifiser feilen etter steg før du endrar noko, og hald klassifiseringa i saka slik at neste person startar der du stoppa.