હું Windows લેપટોપ પર Azure VPN ક્લાયન્ટ જોડું છું, સરનામા-પ્રતિધ્વનિ પૃષ્ઠ ખોલું છું અને મારા ઘરના રાઉટરે આપેલું એ જ જાહેર સરનામું જોઉં છું. દરમિયાન 10.20.0.4 પરનું જમ્પ બોક્સ જવાબ આપે છે અને ખાનગી એન્ડપોઇન્ટ નામ ઉકેલાય છે, તેથી ટનલ તૂટેલી નથી. પોઇન્ટ-ટુ-સાઇટ ગેટવે બરાબર એ જ કરે છે જે તેનું ડિફોલ્ટ રૂપરેખાંકન કહે છે: ખાનગી પ્રીફિક્સ વહન કરે છે અને બાકીનું બધું સ્થાનિક લિંક પર છોડી દે છે. Azure ની માલિકીનું એગ્રેસ સરનામું મેળવવું એ રૂટિંગ ડિઝાઇનમાં ફેરફાર છે, સમારકામ નહીં.

ગેટવે ડિફોલ્ટ રૂપે શું જાહેર કરે છે

ગેટવે વર્ચ્યુઅલ નેટવર્કના સરનામા જગ્યા માટે રૂટ પુશ કરે છે, ઉપરાંત પીઅર નેટવર્ક જ્યાં ગેટવે ટ્રાન્ઝિટ મંજૂર છે અને સાઇટ-ટુ-સાઇટ કનેક્શન અથવા BGP દ્વારા શીખેલા સ્થાનિક પ્રીફિક્સ. તે સમૂહમાં કોઈ 0.0.0.0/0 નથી. તમારી ઓપરેટિંગ સિસ્ટમ તેનું ડિફોલ્ટ રૂટ Wi-Fi અથવા Ethernet પર રાખે છે, તેથી જાહેર API તરફ જતું પેકેટ ક્યારેય ટનલમાં પ્રવેશતું નથી.

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

સ્પ્લિટ ટનલ અને ફોર્સ્ડ ટનલિંગ સાથે સાથે

Split tunnel, the defaultForced tunneling
Internet traffic exits throughlocal ISP or office routerfirewall or appliance inside Azure
Source address the API seesyour home or office IPthe firewall public IP
Inspection and logging in Azurenonepolicy rules plus flow logs
Ongoing costgateway onlygateway, firewall hours, data processing
What usually breaksnothing on the egress pathDNS, on-premises routes, overlapping local ranges

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

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

ટનલને ડિફોલ્ટ રૂટ વહન કરાવો

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

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

તે લીટી દૃષ્ટાંતરૂપ છે, કૉપી-પેસ્ટ માટે પૂર્ણ નથી: પહેલાં Get-AzVirtualNetworkGateway સાથે ગેટવે ઑબ્જેક્ટ મેળવો અને GWOBJ ની જગ્યાએ તેને મૂકો, અને ચલાવતા પહેલાં ખાતરી કરો કે SKU અને ડિપ્લોયમેન્ટ મૉડલ કસ્ટમ રૂટ સ્વીકારે છે. એ જ પ્રીફિક્સ પોર્ટલમાં પોઇન્ટ-ટુ-સાઇટ રૂપરેખાંકન પૃષ્ઠ પર દેખાય છે, અને જો તમે પહેલેથી ગેટવેને સ્ક્રિપ્ટ ન કરતા હોવ તો તેમને સેટ કરવાનું વધુ સુરક્ષિત સ્થાન એ છે.

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

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

ઉપરના બંને ડિઝાઇન IPv4 છે. બે /1 પ્રીફિક્સ IPv6 માટે કંઈ કરતા નથી, અને પોઇન્ટ-ટુ-સાઇટ IPv6 સપોર્ટ એટલો સાંકડો છે કે સમાનતાનું વચન આપતા પહેલાં સંયોજનની કસોટી કરવી જોઈએ.

પહેલાં રૂટ તપાસો, પછી એક્ઝિટ

પેકેજ ફરી ઇન્સ્ટોલ કર્યા પછી અને ફરી જોડાયા પછી, ખાતરી કરો કે ક્લાયન્ટે ખરેખર અડધા ભાગ ઇન્સ્ટોલ કર્યા છે. Windows પર Get-NetRoute -DestinationPrefix 0.0.0.0/1 અને 128.0.0.0/1 માટે એ જ પ્રશ્ન ટનલ ઇન્ટરફેસનું નામ આપવું જોઈએ, અને route print તમારા મૂળ ડિફોલ્ટની બાજુમાં બંને બતાવે છે. Linux પર ip route show એ બે પ્રીફિક્સ સૂચિબદ્ધ કરવા જોઈએ; જો ન કરે, તો પ્રોફાઇલે તેમને ક્યારેય વહન કર્યા નથી.

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

એ જ સત્રમાં એક ખાનગી ગંતવ્ય ફરી કસોટી કરો. ફેરફાર પછી જવાબ આપવાનું બંધ કરતું જમ્પ હોસ્ટ એ સામાન્ય સંકેત છે કે નવા પ્રીફિક્સે કંઈક ખસેડ્યું છે, કાં તો પહેલાં જાહેર થયેલો વધુ સાંકડો સ્થાનિક રૂટ, કાં તો નામ ઉકેલવાનું હવે તમારા ખાનગી ઝોન માટે ફોરવર્ડર વગરના રિઝોલ્વર તરફ જવું.

ક્યારે સ્પ્લિટ ટનલને શાંત રહેવા દેવું

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

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

ફેરફાર બંધ કરતા પહેલાં ચાર વસ્તુઓની ખાતરી કરો: ઇન્સ્ટોલ કરેલું ક્લાયન્ટ પેકેજ નવું છે, બે /1 રૂટ ટનલ ઇન્ટરફેસ પર છે, એક ખાનગી ગંતવ્ય હજી પણ જવાબ આપે છે, અને દૂરસ્થ સેવાનો લોગ ફાયરવોલ સરનામું બતાવે છે.

સંબંધિત લેખો