Azure saidi-vaheline VPN NAT-i taga oleva partneriga: kontroll-loend
NAT-T käsitleb väliseid pakette, mitte partneri aadressi ega sisemisi marsruute. Viis järjestatud kontrolli eraldavad tõlkimise probleemi seadistamise probleemist.
Tehke need kontrollid järjekorras ja peatuge esimese juures, mis ebaõnnestub. Enamik teatisi, et Azure ei toeta NAT-i taga olevat seadet, osutuvad partneri aadressiks, kuhu Azure ei pääse, või tunneliks, mis ei käivitu kunagi õigelt poolt. Väline transport ja sisemine marsruutimine on kaks eri probleemi ning nende segamine raiskab pärastlõuna. Iga samm allpool annab tähelepaneku, mille saate kellelegi teisele edasi anda.
Samm 1: kinnitage, et partner on üldse NAT-i taga
Võrrelge seadme WAN-liidese aadressi aadressiga, mida Azure selle jaoks näeb. Kui need erinevad, midagi tõlgib, ja see tõlkija on nüüd teie VPN-i disaini osa. Küsige teenusepakkujalt, kas vastendus on staatiline või jagatud, sest jagatud vastendus muudab seda, millele saate loota. Privaatse WAN-aadressi ja edastuseta seade on teine juhtum kui operaatori tasandi NAT-i taga olev seade, millel on stabiilne avalik vastendus.
Kui kaks aadressi kattuvad, peatuge siin: NAT ei ole teie probleem ja ülejäänud loend ei aita.
Kirjutage mõlemad aadressid ja tõlkija mudel piletisse. See üks rida hoiab ära järgmise vooru küsimusi, miks seadistatud partner ei vasta.
Samm 2: leppige kokku, kes algatab
Azure VPN Gateway FAQ toob välja NAT-T toe ja lisab, et kohalik seade peaks IPsec-tunneli algatama, kui see asub NAT-i taga. See sobib sellega, kuidas olekupõhine tõlkimine töötab, sest tõlkija hoiab vastendust seetõttu, et sisemine seade saatis esimese paketi. Kui Azure peaks algatama ja midagi ei saabu selle vastenduse loomiseks, ei käivitu tunnel kunagi.
Seadistage partner nii, et ainult vastaja viga oleks ilmne, ja kontrollige, kas seade proovib ise uuesti või vajab päästikut. Mõned seadmed tõstavad tunneli ainult siis, kui ilmub huvitav liiklus, mis on korras seni, kuni huvitav liiklus on tervisekontroll, mida kunagi ei tule.
Jälgige käsitsi algatamise ajal seadmes IKE-vahetust; vaikus seal on marsruutimise või tulemüüri vastus, mitte Azure vastus.
Samm 3: seadistage partneri aadress õigesti
Azure vajab partneri jaoks kättesaadavat avalikku aadressi oma kohaliku võrgu lüüsi objektis, tavaliselt tõlkija avalikku aadressi, mitte seadme sisemist aadressi. Identiteet, millega seade autendib, on eraldi väli ja võib õiguspäraselt erineda aadressist, millele Azure helistab. Hoidke need kaks lahus, sest nende vahetamine tekitab autentimisvea, mis näeb täpselt välja nagu NAT-i probleem.
Kui avalik aadress muutub, peab see objekt koos sellega muutuma. Nimi, mis lahendub aegunud aadressiks, on halvem kui staatiline aadress, mida peate käsitsi uuendama.
Kirjutage üles kõik kolm väärtust: seadme kohalik aadress, tõlgitud avalik aadress, seadistatud partneri identiteet.
Samm 4: avage ainult pordid, mida NAT-T vajab
NAT-T kannab ESP-d UDP sees ja RFC 3948 kirjeldab seda kapseldust pordiga 4500, mida kasutatakse pärast esialgset läbirääkimist pordil 500. Teie tulemüür ja tõlkija peavad mõlemad lubama vahetust ja selle tagasiliiklust. Sõltumatu TCP-pordi lubamine ei tõesta selle tee kohta midagi ning reegel, mis lubab väljuvat, kuid mitte vastust, ebaõnnestub ikkagi.
Staatiline sissetuleva pordi edastus ei ole automaatselt vajalik, kui partner algatab ja tõlkija hoiab olekut. See muutub vajalikuks, kui vastendus on ebastabiilne või kui miski teel lõpetab oleku agressiivselt.
Salvestage üks kord tõlkija mõlemal küljel; kapselduse erinevus on kohe näha.
Samm 5: eraldage väline transport sisemisest marsruutimisest
Tunnel, mis luuakse ja ei kanna midagi, on marsruutimise probleem, mitte NAT-T probleem. Saitidel on endiselt vaja ühilduvaid liikluse valijaid, kattuvaid aadressiruume, juurdepääsureegleid ja rakendusvõrkude jaoks tagasiteed. Midagi sellest ei anna edukas IKE-vahetus.
Kui kaks saiti kasutavad kattuvaid privaatseid vahemikke, on tunnelisisene tõlkimine eraldi disain oma reeglitega. Ärge numerdage alavõrku ümber ainult seetõttu, et väline lüüs juhtub asuma koduruuteri taga.
Klassifitseerige tõrge enne millegi muutmise etapi järgi ja hoidke see klassifikatsioon piletis, et järgmine inimene alustaks sealt, kus teie lõpetasite.