એક Azure VPN VM પર બે જાહેર IP: કયું શું કરે છે

એક Azure VPN VM પર બે જાહેર IP એવી અપેક્ષા ઊભી કરે છે જે ભાગ્યે જ સાચી પડે છે: ક્લાયન્ટ જે સરનામા સાથે જોડાય છે તે જ સરનામું વેબસાઇટ જુએ છે. ત્રણ સ્વતંત્ર નિર્ણયો આ પરિણામ આપે છે અને તેમાંથી ફક્ત પ્રથમ જ ટનલ શ્રોતા વિશે છે. બીજું ગેસ્ટ સ્રોત છે જે ફોરવર્ડ કરેલા ક્લાયન્ટ ટ્રાફિક માટે વપરાય છે, અને ત્રીજું Azure ની આઉટબાઉન્ડ પદ્ધતિ છે જે તે સ્રોત પર લાગુ પડે છે. એક બદલો અને બાકીના બે જ્યાં હતા ત્યાં જ રહે છે, તેથી દરેકને સ્પષ્ટ રીતે નક્કી કરો.

નિર્ણય 1: ટનલ ક્યાં સમાપ્ત થાય છે

Azure જાહેર IP NIC પરના ખાનગી IP રૂપરેખાંકન સાથે સંકળાયેલું છે; તે ગેસ્ટ ઓપરેટિંગ સિસ્ટમની અંદર ઉમેરાતું સરનામું નથી. ધારવાને બદલે મેપિંગ વાંચો: az network nic show --ids /subscriptions/.../networkInterfaces/vpn-nic --query 'ipConfigurations[].{private:privateIPAddress,public:publicIPAddress.id}'. તે ક્વેરી જે ખાનગી સરનામું પરત કરે તે જ ગેસ્ટે ખરેખર રાખવાનું હોય છે.

એક NIC ઘણી IP રૂપરેખાંકનો ધરી શકે છે, તેથી બે જાહેર સરનામાંઓ માટે બે NIC ની જરૂર નથી. જો ડિઝાઇન ખરેખર બે NIC વાપરે છે, તો દરેક પોતાના ગેસ્ટ રૂટ અને આગલા હોપ લાવે છે, અને તમે સરળ બનાવવાને બદલે રૂટિંગ નિર્ણય ઉમેર્યો છે.

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

નિર્ણય 2: ફોરવર્ડ કરેલો ક્લાયન્ટ કયો સ્રોત વાપરે છે

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

સાંકડો SNAT નિયમ ગેસ્ટ-ખાનગી સ્રોત પસંદ કરી શકે છે, પરંતુ પછીના Azure અનુવાદને પાછળ પાડી શકતો નથી. VM ની અંદર દરેક ક્લાયન્ટ માટે જવાબદારીની જરૂર હોય ત્યારે SNAT પસંદ કરો; જ્યારે સબનેટની આઉટબાઉન્ડ ડિઝાઇન પહેલેથી સ્થિર જાહેર સ્રોત આપે છે અને બીજું અનુવાદ ફક્ત સ્થિતિ ઉમેરશે ત્યારે તેને છોડી દો.

નિર્ણય 3: કઈ Azure આઉટબાઉન્ડ પદ્ધતિ જીતે છે

Microsoftઆઉટબાઉન્ડ અગ્રતા ક્રમનું દસ્તાવેજીકરણ કરે છે: ઉપકરણ અથવા ગેટવે તરફનો લાગુ રૂટ અગ્રતા ધરાવે છે, અને સંબંધિત માર્ગ પર સબનેટ NAT Gateway કનેક્ટિવિટી ઇન્સ્ટન્સ-સ્તરીય જાહેર IP પર અગ્રતા ધરાવે છે. આ ક્રમને કારણે 10.20.0.5 પર અનુવાદ કરવાથી સાબિત થતું નથી કે વેબસાઇટ 198.51.100.20 જોશે. નિકાસ ડિઝાઇન સ્વીકારતા પહેલાં અસરકારક રૂટ ટેબલ, NAT Gateway સંબંધ અને NIC નું જાહેર IP એકસાથે વાંચો.

રાખોAzure NIC ફોરવર્ડિંગ સેટિંગLinux ફોરવર્ડિંગથી અલગ. ક્લાઉડ ફ્લેગ એવા પેકેટને મંજૂરી આપે છે જેનો સ્રોત કે ગંતવ્ય NIC ને સોંપાયેલ નથી; તે net.ipv4.ip_forward સક્ષમ કરતું નથી, અને ગેસ્ટ સેટિંગ ક્લાઉડની પરવાનગી આપતું નથી.

ટનલ સોકેટનો પોતાનો સ્રોત નિર્ણય છે

wg-quick હેઠળ WireGuard નું Address WireGuard ઇન્ટરફેસને સરનામું સોંપે છે; તે બાહ્ય UDP બાઇન્ડ સૂચના નથી. એન્ક્રિપ્ટેડ સોકેટનો સ્રોત રૂટિંગ ટેબલ અનુસરે છે, તેથી પોલિસી રૂટ અથવા બીજો ડિફોલ્ટ ઇન્ટરફેસ સરનામાને અડ્યા વિના તેને ખસેડી શકે છે.OpenVPNનો local વિકલ્પ અને UDP multihome એ જ રીતે વર્તે છે: તે શ્રોતા અને તેના જવાબો વિશે છે, દરેક ફોરવર્ડ કરેલા ક્લાયન્ટના ઇન્ટરનેટ સ્રોત વિશે નહીં.

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

શું સ્વીકારવું, અને કયા ક્રમમાં

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

સફળ ટનલ ફક્ત પ્રથમ ભાગ સાબિત કરે છે. નવા પ્રવાહ સાથે નિકાસની પરીક્ષા કરો, કારણ કે કેશ કરેલું કનેક્શન રૂટ બદલાયાના ઘણા સમય પછી પણ જૂનો સ્રોત વાપરી શકે છે.