VPN sajt-në-sajt në Azure me një partner pas NAT: listë kontrolli

Kryeni këto kontrolle me radhë dhe ndaloni te i pari që dështon. Shumica e raporteve se Azure nuk mbështet një pajisje pas NAT rezultojnë të jenë një adresë partneri që Azure nuk e arrin, ose një tunel që nuk niset kurrë nga ana e duhur. Transporti i jashtëm dhe rrugëtimi i brendshëm janë dy probleme të ndryshme, dhe përzierja e tyre humbet një pasdite. Çdo hap më poshtë prodhon një vëzhgim që mund t’ia jepni dikujt tjetër.

Hapi 1: konfirmoni se partneri është vërtet pas NAT

Krahasoni adresën në ndërfaqen WAN të pajisjes me adresën që Azure sheh për të. Nëse ndryshojnë, diçka po përkthen, dhe ai përkthyes tani është pjesë e projektimit tuaj të VPN. Pyetni ofruesin nëse hartëzimi është statik ose i përbashkët, sepse një hartëzim i përbashkët ndryshon atë në të cilën mund të mbështeteni. Një pajisje me adresë WAN private dhe pa përcjellje është një rast tjetër nga një pajisje pas një NAT të nivelit të operatorit me një hartëzim publik të qëndrueshëm.

Nëse dy adresat përputhen, ndaloni këtu: NAT nuk është problemi juaj dhe pjesa tjetër e kësaj liste nuk do të ndihmojë.

Shkruani të dyja adresat dhe modelin e përkthyesit në tiketë. Ai një rresht parandalon raundin e radhës të pyetjeve se pse partneri i konfiguruar nuk përgjigjet.

Hapi 2: bihuni dakord se kush nis

Pyetjet e shpeshta të Azure VPN Gateway përmendin mbështetjen e NAT-T dhe shtojnë se pajisja lokale duhet të nisë tunelin IPsec kur ndodhet pas NAT. Kjo përputhet me mënyrën se si funksionon përkthimi me gjendje, pasi përkthyesi mban një hartëzim sepse pajisja e brendshme dërgoi paketën e parë. Nëse pritet që Azure të nisë dhe nuk vjen asgjë për të krijuar atë hartëzim, tuneli nuk niset kurrë.

Konfiguroni partnerin në mënyrë që një gabim i vetëm-përgjigjësit të jetë i dukshëm, dhe kontrolloni nëse pajisja riprovon vetë ose ka nevojë për një nxitës. Disa pajisje ngrinin një tunel vetëm kur shfaqet trafik interesant, gjë që është në rregull derisa trafiku interesant të jetë një sondë shëndeti që nuk vjen kurrë.

Vëzhgoni shkëmbimin IKE në pajisje gjatë një nisjeje manuale; heshtja atje është përgjigje e rrugëtimit ose e murit të zjarrit, jo përgjigje e Azure.

Hapi 3: vendosni saktë adresën e partnerit

Azure ka nevojë për një adresë publike të arritshme për partnerin në objektin e portës së rrjetit lokal, zakonisht adresën publike të përkthyesit dhe jo adresën e brendshme të pajisjes. Identiteti me të cilin pajisja vërtetohet është fushë e veçantë dhe mund të ndryshojë në mënyrë legjitime nga adresa që Azure thërret. Mbani të dyja të ndara, sepse zëvendësimi i tyre prodhon një dështim vërtetimi që duket saktësisht si problem NAT.

Nëse adresa publike ndryshon, ai objekt duhet të ndryshojë bashkë me të. Një emër që zgjidhet në një adresë të vjetruar është më keq se një adresë statike që duhet ta përditësoni me dorë.

Shkruani të tre vlerat: adresën lokale të pajisjes, adresën publike të përkthyer dhe identitetin e konfiguruar të partnerit.

Hapi 4: hapni vetëm portat që NAT-T ka nevojë

NAT-T mbart ESP brenda UDP, dhe RFC 3948 përshkruan atë inkapsulim me portën 4500 të përdorur pas negociimit fillestar në portën 500. Muri juaj i zjarrit dhe përkthyesi duhet të dy të lejojnë shkëmbimin dhe trafikun e tij të kthimit. Lejimi i një porte TCP të palidhur nuk provon asgjë për këtë rrugë, dhe një rregull që lejon daljen por jo përgjigjen do të dështojë gjithsesi.

Përcjellja statike e një porte hyrëse nuk kërkohet automatikisht kur partneri nis dhe përkthyesi mban gjendjen. Bëhet e nevojshme kur hartëzimi është i paqëndrueshëm ose kur diçka në rrugë skadon gjendjen në mënyrë agresive.

Kapni një herë në të dy anët e përkthyesit; ndryshimi i inkapsulimit duket menjëherë.

Hapi 5: ndani transportin e jashtëm nga rrugëtimi i brendshëm

Një tunel që vendoset dhe nuk mbart asgjë është problem rrugëtimi, jo problem NAT-T. Sajtet kanë ende nevojë për përzgjedhës trafiku të përputhshëm, hapësira adresash që përputhen, rregulla aksesi dhe një rrugë kthimi për rrjetet e aplikacioneve. Asgjë nga këto nuk e ofron një shkëmbim IKE i suksesshëm.

Nëse dy sajtet përdorin diapazone private që mbivendosen, përkthimi brenda tunelit është një projektim i veçantë me rregullat e veta. Mos rinumeroni një nënrrjet vetëm sepse porta e jashtme ndodhet rastësisht pas një ruteri shtëpiak.

Klasifikoni dështimin sipas fazës përpara se të ndryshoni çdo gjë, dhe mbani atë klasifikim në tiketë në mënyrë që personi tjetër të nisë aty ku ju u ndalët.