કેવી રીતે Azure વેબ એપ VPN દ્વારા ઓન-પ્રિમિસીસ સુધી પહોંચે છે

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

કાર્યકર ખરેખર શું મોકલે છે

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

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

રૂપરેખાંકન ટ્રાફિક, જેમ કે સ્ટાર્ટઅપ પર કન્ટેનર ઇમેજ પુલ, તેના પોતાના રૂટીંગ નિયમોનું પાલન કરે છે અને જ્યારે તમારા API કૉલ્સ સફળ થાય છે ત્યારે નિષ્ફળ થઈ શકે છે.

એકીકરણ સબનેટ એ સ્રોત છે જેને તમારે મંજૂરી આપવી જોઈએ

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

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

ગંતવ્યની બાજુ સાંકડી રાખો: એક સેવા, એક બંદર, એક દિશા, પરત જવાનો માર્ગ સ્પષ્ટપણે માન્ય છે.

પિયરિંગ અને ગેટવે ટ્રાન્ઝિટ સ્પષ્ટ છે

જો VPN ગેટવે હબ VNet અને સ્પોકમાં ઇન્ટિગ્રેશન સબનેટમાં બેસે છે, તો પાથને હબ પીઅરિંગ પર મંજૂર ગેટવે ટ્રાન્ઝિટ અને સ્પોક પીઅરિંગ પર રિમોટ ગેટવે ઉપયોગ સક્ષમ કરવાની જરૂર છે. બે VNets વચ્ચે પોતે જ પીઅરિંગ ટ્રાફિક વહન કરે છે અને વધુ કંઈ નથી. એકીકરણ સબનેટ પર અસરકારક માર્ગો એ છે જ્યાં તમે પુષ્ટિ કરો છો કે ગેટવે નેક્સ્ટ હોપ ખરેખર ત્યાં છે.

એક હબ-એન્ડ-સ્પોક ડિઝાઇન કે જેનું રૂટ ટેબલ ફાયરવોલને 0.0.0.0/0 મોકલે છે તે એક સામાન્ય પ્રકાર છે, અને તે ફાયરવોલને પછી ઓન-પ્રિમીસીસ ઉપસર્ગ માટે તેના પોતાના નિયમની જરૂર છે.

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

ઇનબાઉન્ડ ખાનગી એન્ડપોઇન્ટ એ બીજી દિશા છે

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

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

લેગસી પોઈન્ટ-ટુ-સાઈટ રૂપરેખાંકનની નકલ કરશો નહીં કારણ કે જૂના ઉદાહરણએ તેનો ઉપયોગ કર્યો છે.

એપના પોતાના સંદર્ભ સાથે ચકાસો

તમારા લેપટોપમાંથી નહીં અને સમાન VNet માં VM પરથી નહીં, જમાવવામાં આવેલી એપ્લિકેશનમાંથી પરીક્ષણ કરો. ઉકેલાયેલ સરનામું, કનેક્શન પરિણામ અને એપ્લિકેશન-લેવલ પ્રતિસાદને અલગથી લોગ કરો, કારણ કે DNS નિષ્ફળતા, TCP સમયસમાપ્તિ અને ત્રણ અલગ અલગ માલિકો પર પ્રમાણીકરણ અસ્વીકાર બિંદુ. જો નામ રિઝોલ્યુશન નિષ્ફળ જાય, તો ટનલને સ્પર્શ કરતા પહેલા VNet માટે ખાનગી DNS ઠીક કરો.

લીલી ટનલની સ્થિતિ જ સાબિત કરે છે કે ગેટવે ઉપર છે. તે પસંદગીકારો, ફાયરવોલ નિયમો અથવા DNS વિશે કશું કહેતું નથી.

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