NAT પાછળના પીઅર સાથે Azure સાઇટ-થી-સાઇટ VPN: ચેકલિસ્ટ

આ તપાસ ક્રમમાં કરો અને જે પહેલી નિષ્ફળ જાય ત્યાં જ અટકો. Azure NAT પાછળના ઉપકરણને સપોર્ટ કરતું નથી એવા મોટા ભાગના અહેવાલ ખરેખર એવા પીઅર સરનામા હોય છે જ્યાં Azure પહોંચી શકતું નથી, અથવા એવી ટનલ હોય છે જે યોગ્ય બાજુથી ક્યારેય શરૂ થતી નથી. બહારનું પરિવહન અને અંદરનું રૂટિંગ બે અલગ સમસ્યા છે, અને તેમને ભેળવવાથી આખી બપોર વેડફાય છે. નીચેનું દરેક પગલું એવું નિરીક્ષણ આપે છે જે તમે બીજા કોઈને સોંપી શકો.

પગલું 1: પીઅર ખરેખર NAT પાછળ છે તેની ખાતરી કરો

ઉપકરણના WAN ઇન્ટરફેસ પરનું સરનામું Azure તેના માટે જે સરનામું જુએ છે તેની સાથે સરખાવો. જો તે અલગ હોય, તો કંઈક અનુવાદ કરી રહ્યું છે, અને એ અનુવાદક હવે તમારી VPN ડિઝાઇનનો ભાગ છે. પ્રદાતાને પૂછો કે મેપિંગ સ્થિર છે કે વહેંચાયેલું, કારણ કે વહેંચાયેલું મેપિંગ તમે શેના પર આધાર રાખી શકો તે બદલી નાખે છે. ખાનગી WAN સરનામું ધરાવતું અને ફોરવર્ડિંગ વગરનું ઉપકરણ સ્થિર જાહેર મેપિંગ સાથેના કેરિયર-ગ્રેડ NAT પાછળના ઉપકરણ કરતાં અલગ કેસ છે.

જો બંને સરનામાં મળે, તો અહીં અટકો: NAT તમારી સમસ્યા નથી અને આ યાદીનો બાકીનો ભાગ મદદ નહીં કરે.

ટિકિટમાં બંને સરનામાં અને અનુવાદકનું મોડેલ લખો. એ એક લીટી જ ગોઠવેલો પીઅર કેમ જવાબ આપતો નથી તે અંગેના આગલા પ્રશ્નો રોકે છે.

પગલું 2: કોણ શરૂ કરશે તે નક્કી કરો

Azure VPN Gateway FAQ NAT-T સપોર્ટ જણાવે છે અને ઉમેરે છે કે ઓન-પ્રિમાઇઝ ઉપકરણે NAT પાછળ હોય ત્યારે IPsec ટનલ શરૂ કરવી જોઈએ. આ સ્ટેટફુલ અનુવાદ કેવી રીતે કાર્ય કરે તેની સાથે મેળ ખાય છે, કારણ કે અંદરના ઉપકરણે પહેલું પેકેટ મોકલ્યું હોવાથી અનુવાદક મેપિંગ રાખે છે. જો Azureએ શરૂ કરવાનું હોય અને એ મેપિંગ બનાવવા કંઈ ન આવે, તો ટનલ ક્યારેય શરૂ થતી નથી.

પીઅરને એવી રીતે ગોઠવો કે ફક્ત-જવાબ આપનારની ભૂલ સ્પષ્ટ દેખાય, અને તપાસો કે ઉપકરણ પોતે ફરી પ્રયત્ન કરે છે કે ટ્રિગર જોઈએ છે. કેટલાંક ઉપકરણો ફક્ત ત્યારે જ ટનલ ઉપાડે છે જ્યારે રસપ્રદ ટ્રાફિક દેખાય, જે ત્યાં સુધી ઠીક છે જ્યાં સુધી રસપ્રદ ટ્રાફિક એવી હેલ્થ પ્રોબ ન બને જે ક્યારેય આવતી નથી.

મેન્યુઅલ શરૂઆત દરમિયાન ઉપકરણ પર IKE વિનિમય જુઓ; ત્યાંનું મૌન રૂટિંગ કે ફાયરવોલનો જવાબ છે, Azureનો જવાબ નહીં.

પગલું 3: પીઅરનું સરનામું બરાબર મેળવો

Azureને પોતાના લોકલ નેટવર્ક ગેટવે ઑબ્જેક્ટમાં પીઅર માટે પહોંચી શકાય તેવું જાહેર સરનામું જોઈએ, સામાન્ય રીતે ઉપકરણના અંદરના સરનામા પર નહીં પણ અનુવાદકનું જાહેર સરનામું. ઉપકરણ જે ઓળખથી પ્રમાણિત કરે છે તે અલગ ક્ષેત્ર છે અને Azure જે સરનામે ડાયલ કરે છે તેનાથી કાયદેસર રીતે અલગ હોઈ શકે છે. બંનેને અલગ રાખો, કારણ કે તેમને અદલાબદલી કરવાથી પ્રમાણીકરણ નિષ્ફળતા થાય છે જે બરાબર NAT સમસ્યા જેવી દેખાય છે.

જો જાહેર સરનામું બદલાય, તો એ ઑબ્જેક્ટ પણ તેની સાથે બદલાવું જોઈએ. જૂના સરનામે રિઝોલ્વ થતું નામ જાતે અપડેટ કરવા પડતા સ્થિર સરનામા કરતાં ખરાબ છે.

ત્રણેય મૂલ્યો લખો: ઉપકરણનું લોકલ સરનામું, અનુવાદિત જાહેર સરનામું, ગોઠવેલી પીઅર ઓળખ.

પગલું 4: NAT-Tને જે પોર્ટ જોઈએ તે જ ખોલો

NAT-T UDPની અંદર ESP વહન કરે છે, અને RFC 3948 એ કેપ્સ્યુલેશન વર્ણવે છે જેમાં પોર્ટ 500 પરની પ્રારંભિક વાટાઘાટ પછી પોર્ટ 4500 વપરાય છે. તમારા ફાયરવોલ અને અનુવાદક બંનેને વિનિમય અને તેના પરત ટ્રાફિકની પરવાનગી આપવી પડશે. અસંબંધિત TCP પોર્ટને પરવાનગી આપવાથી આ માર્ગ વિશે કંઈ સાબિત થતું નથી, અને બહાર જવાની પરવાનગી આપતો પણ જવાબની નહીં એવો નિયમ તોય નિષ્ફળ જશે.

જ્યારે પીઅર શરૂ કરે અને અનુવાદક સ્થિતિ રાખે ત્યારે સ્થિર ઇનબાઉન્ડ પોર્ટ ફોરવર્ડ આપોઆપ જરૂરી નથી. તે ત્યારે જરૂરી બને છે જ્યારે મેપિંગ અસ્થિર હોય અથવા માર્ગમાં કંઈક સ્થિતિ આક્રમક રીતે સમાપ્ત કરે.

અનુવાદકની બંને બાજુએ એક વાર કેપ્ચર કરો; કેપ્સ્યુલેશનનો તફાવત તરત દેખાય છે.

પગલું 5: બહારના પરિવહનને અંદરના રૂટિંગથી અલગ કરો

જે ટનલ સ્થપાય છે પણ કંઈ વહન કરતી નથી તે રૂટિંગ સમસ્યા છે, NAT-T સમસ્યા નહીં. સાઇટ્સને હજી પણ સુસંગત ટ્રાફિક સિલેક્ટર, મેળ ખાતા સરનામા ક્ષેત્રો, ઍક્સેસ નિયમો અને એપ્લિકેશન નેટવર્ક માટે પરત માર્ગની જરૂર છે. સફળ IKE વિનિમય તેમાંથી કંઈ પણ આપતું નથી.

જો બંને સાઇટ્સ એકબીજા પર ચઢતા ખાનગી રેન્જ વાપરે, તો ટનલની અંદરનો અનુવાદ પોતાના નિયમો સાથેની અલગ ડિઝાઇન છે. ફક્ત એટલા માટે સબનેટને ફરી નંબર ન આપો કે બહારનું ગેટવે ઘરના રાઉટર પાછળ છે.

કંઈપણ બદલતા પહેલાં નિષ્ફળતાને તબક્કા પ્રમાણે વર્ગીકૃત કરો, અને એ વર્ગીકરણ ટિકિટમાં રાખો જેથી આગલી વ્યક્તિ તમે અટક્યા ત્યાંથી શરૂ કરે.