Azure VPN NAT ઓવરલેપિંગ VNet સરનામાં ઠીક કરતું નથી
સમાન ખાનગી શ્રેણી ધરાવતા બે VNet ફક્ત NAT હોવાને કારણે જોડાશે નહીં. પહેલાં જોડાણનો પ્રકાર તપાસો, પછી ફરી નંબર આપો અથવા અનુવાદ ઉપનામની માલિકી રાખો.
બંને VNet 10.40.1.0/24 વાપરે છે, ટનલ ઉપર આવે છે, અને કંઈ કામ કરતું નથી. બીજું VPN ગેટવે ઉમેરવાથી તે બદલાતું નથી, અને નીચી રૂટ મેટ્રિક પણ નહીં, કારણ કે સમસ્યા પાથ પસંદગીમાં નથી. એક જ ખાનગી સરનામાંને જવાબ આપતા બે વર્કલોડ દરેક પેકેટને અસ્પષ્ટ ગંતવ્ય અને ચકાસી ન શકાય તેવા પરત માર્ગ સાથે છોડી દે છે. કોઈપણ અનુવાદનું આયોજન કરતાં પહેલાં શોધો કે તમે ખરેખર કયો જોડાણ પ્રકાર બનાવ્યો છે, કારણ કે તે એક પસંદગી નક્કી કરે છે કે Azure ની NAT સુવિધા બિલકુલ ઉપલબ્ધ છે કે નહીં.
લક્ષણ ખરેખર તમને શું કહે છે
જ્યારે VNet A માંનો હોસ્ટ 10.40.1.10 પર મોકલે છે, રૂટિંગ કોષ્ટક તેને ફક્ત ક્યાંક જ દિશા આપી શકે છે. જો VNet B માં પણ 10.40.1.10 હોય, તો તે સરનામું એવું ગંતવ્ય નથી જે પાથ અલગ પાડી શકે; તે બે માલિકોવાળું એક સરનામું છે.
લોકો સામાન્ય રીતે જે બીજું ગેટવે તૈનાત કરે છે તે મદદ કરતું નથી. તે તમને બીજી ટનલ આપે છે, બીજું સરનામું નહીં, અને નકલી શ્રેણી ટનલની અંદર અપરિવર્તિત મુસાફરી કરે છે. તે જ કન્ફિગરેશનને પણ બમણું કરે છે જે તમારે સુસંગત રાખવું પડે છે. જે તે કરી શકતું નથી તે એ છે કે એક સરનામું બે હોસ્ટનો અર્થ આપે.
VPN પીઅરના જાહેર સરનામાં બદલવાથી પણ કંઈ થતું નથી. તે સરનામાં ટનલના અંતિમ બિંદુઓ ઓળખે છે, જ્યારે અથડામણ અંદર વહન કરાયેલી ખાનગી શ્રેણીમાં છે.
જોડાણનો પ્રકાર નક્કી કરે છે કે NAT ઉપલબ્ધ છે કે નહીં
Azure VPN Gateway માં ખરેખર NAT ક્ષમતા છે, અને તે ચોક્કસ ગેટવે SKU પર રૂટ-આધારિત IPsec આંતર-સાઇટ જોડાણો માટે દસ્તાવેજીકૃત છે. એ જ દસ્તાવેજીકરણ VNet-to-VNet અને point-to-site જોડાણોને બાકાત રાખે છે, તેથી આ સુવિધા એવું ચેકબોક્સ નથી જે દરેક ગેટવે સંબંધમાં દેખાય.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
મૂળ VNet-to-VNet માટે પણ શરૂઆતથી જ VNet અને સ્થાનિક-નેટવર્ક શ્રેણીઓ ઓવરલેપ ન થવી જરૂરી છે, જે બાકાત સાથે સુસંગત છે. તે જ કારણસર VNet પીઅરિંગ પણ ઓવરલેપનો ઉકેલ નથી.
એક સમર્થિત વિકલ્પ છે જેને લોકો મૂળ પ્રકાર સાથે ભેળવી દે છે: બીજા VNet ને સ્થાનિક નેટવર્ક તરીકે મોડેલ કરો અને તેને સાઇટ-થી-સાઇટ જોડાણ તરીકે જોડો. તે અલગ સંસાધન અને અલગ ડિઝાઇન છે, તેથી નામ બદલાયેલા જોડાણને નામ બદલવા તરીકે નહીં, પણ ચકાસવાના ફેરફાર તરીકે ગણો.
ફરી નંબર આપો, અથવા ઉપનામની માલિકી ધરાવતી વસ્તુ સાથે અનુવાદ કરો
જો બંને VNet તમારા હોય, તો આયોજિત ફરી-નંબરિંગની સરખામણી અનુવાદના ચાલુ ખર્ચ સાથે કરો. ફરી-નંબરિંગ એપ્લિકેશન કન્ફિગરેશન, DNS રેકોર્ડ, સુરક્ષા નિયમો અને દરેક હાલના જોડાણને સ્પર્શે છે, પણ પછી સામાન્ય રીતે વંચાય તેવું નેટવર્ક છોડે છે. તે એક સમયે એક સબનેટ કરો, DNS ફેરફાર સૌથી છેલ્લે. અડધું ફરી-નંબર થયેલી શ્રેણી બંને વિકલ્પો કરતાં ખરાબ છે, કારણ કે પછી બંને પ્રીફિક્સ આગળ કોષ્ટક વાંચનારને સત્તાવાળા લાગે છે.
જ્યાં ફરી-નંબરિંગ વ્યવહારુ નથી, ત્યાં ઉપનામ માટે વાસ્તવિક માલિક સાથેની અનુવાદિત ડિઝાઇન વાપરો. VNet A માંના કૉલર VNet B ના 10.40.1.10 સુધી 10.140.1.10 તરીકે પહોંચી શકે છે, પણ તે ઉપનામને અનુવાદ કરતું ઉપકરણ, તેની તરફનો રૂટ અને જવાબ માટે સુસંગત વર્તન જોઈએ. ફક્ત DNS માં ઉમેરાયેલું સરનામું અનુવાદ નથી.
બંને શ્રેણીઓને બંને દિશામાં નોંધો: કૉલર શું ડાયલ કરે છે, ગંતવ્ય સ્રોત તરીકે શું જુએ છે, અને કઈ બાજુ શરૂઆત કરી શકે છે. Azure ના પોતાના NAT નિયમો તેમના SNAT મેપિંગ માટે વિપરીત અનુવાદ સમાવે છે, તેથી તમે હાથે મેળ ખાતો DNAT નિયમ લખતા નથી, પણ તે સગવડ એ જોડાણ પ્રકારો પર અટકે છે જેને આ સુવિધા સમર્થન આપે છે.
શું કામ નહીં કરે
વપરાશકર્તા-નિર્ધારિત રૂટ કે રૂટ મેટ્રિક ગુમ થયેલો સરનામા ભેદ પેદા કરી શકતા નથી. બંને હજી અસ્પષ્ટ ગંતવ્ય પર કાર્ય કરે છે, અને પેકેટ કોષ્ટક જે પસંદ કરે તે આગામી હોપ પર પહોંચે છે.
નકલી શ્રેણીને વધુ ચોક્કસ પ્રીફિક્સ તરીકે રૂટ કોષ્ટકમાં ઉમેરવાથી અસ્પષ્ટતા ફક્ત એક પગલું ખસે છે. તે બીજી દિશાને પણ તોડવાની પ્રવૃત્તિ ધરાવે છે, જ્યાં જવાબ પાસે હવે બે વિશ્વસનીય સ્રોત હોય છે.
બંને દિશામાં ટ્રાફિક સાથે ડિઝાઇન સ્વીકારો
ટનલ સ્થિતિથી નહીં, દરેક બાજુથી નવી મંજૂર કામગીરીથી ડિઝાઇન સાબિત કરો. જોડાયેલી IPsec ટનલ કહે છે કે પીઅર ક્રિપ્ટોગ્રાફી પર સહમત છે; ગંતવ્યો અલગ પડ્યાં કે નહીં તે વિશે તે કંઈ કહેતી નથી.
પછી નકારાયેલા માર્ગો ચલાવો: એવું સરનામું જે અગમ્ય રહેવું જોઈએ, અને એવી સેવા જેને નીતિએ અવરોધવી જોઈએ. જો બંને હજી સફળ થાય, તો અનુવાદ ડિઝાઇનના ઇરાદા કરતાં વિશાળ છે.
જે હકીકતો પછી આ સેટઅપ સમજાવશે તેની સાથે સમાપ્ત કરો: મૂળ શ્રેણી, પ્રસ્તુત શ્રેણી, અનુવાદ કરતું ઉપકરણ, અને દરેક બાજુ જે દિશામાં શરૂઆત કરી શકે. જો તેમાંથી કોઈ ખૂટે, તો આગામી ઇજનેરને એવું નેટવર્ક વારસામાં મળે છે જ્યાં બે હોસ્ટ એક જ નામ વહેંચે છે અને કોઈને યાદ નથી કે એક કેમ જવાબ આપે છે.