Azure માં VPN ઉપકરણ સાથેનું VM પરતનો માર્ગ કેમ છોડી દે છે
Azure VM માંનું VPN ઉપકરણ જરૂરી છે કે UDR, NIC નું ફોરવર્ડિંગ ફ્લેગ અને અતિથિ નીતિ સહમત થાય. એક શાખા વિનંતી ત્રણેયમાંથી અનુસરો.
VPN ઉપકરણ ચલાવતું Azure VM બે સ્વતંત્ર નિર્ણય પ્રણાલીઓની અંદર રહે છે. પેકેટ કઈ સબનેટમાંથી નીકળે તે Azure નક્કી કરે છે, રૂટ ટેબલ અને NIC ના ફોરવર્ડિંગ સેટિંગનો ઉપયોગ કરીને. ઉપકરણની પોતાની ઓપરેટિંગ સિસ્ટમ નક્કી કરે છે કે તે ડિક્રિપ્ટ થયેલું પેકેટ આગળ મોકલશે કે નહીં. સંપૂર્ણ રીતે ઉપર આવતું ટનલ હજી પણ બીજી પ્રણાલીમાં નિષ્ફળ જઈ શકે છે, અને ત્યાં જ આવા મોટા ભાગના ડિપ્લોયમેન્ટ અટકે છે.
એક માર્ગના ત્રણ માલિક
એક શાખા નેટવર્ક લો 192.168.50.0/24 અને એક વર્કલોડ સબનેટ લો 10.0.10.0/24, ઉપકરણ આ સરનામે છે 10.0.0.4 તેના પોતાના સબનેટમાં. એક જ વિનંતી ત્રણ અલગ રૂપરેખાઓને સ્પર્શે છે.
| Decision | Configured in | How it fails |
|---|---|---|
| Where the workload subnet sends branch traffic | Azure route table entry | Traffic leaves the subnet and never reaches the appliance |
| Whether a NIC may accept traffic not addressed to it | Azure NIC IP forwarding | Packets arrive and disappear at the interface |
| Whether the guest forwards decrypted traffic | Guest OS or vendor appliance policy | Tunnel is up, workload is unreachable |
| Whether the workload accepts the source | NSG and service policy | Requests delivered, replies refused |
મોટા ભાગની સંસ્થાઓમાં દરેક પંક્તિનો માલિક અલગ ટીમ હોય છે, તેથી આ ખામી સામાન્ય રીતે એકને બદલે ત્રણ ટિકિટ તરીકે આવે છે.
જે રૂટ ઉપકરણ તરફ નિર્દેશ કરે છે
વર્કલોડ સબનેટ સાથે રૂટ ટેબલ જોડો અને શાખા પ્રીફિક્સને Virtual appliance પ્રકારનું આગળનું હોપ આપો 10.0.0.4 સરનામા તરીકે. ઉપકરણનું પહોંચી શકાય તેવું ખાનગી સરનામું વાપરો, ક્યારેય નહીં તેનું જાહેર VPN પ્રવેશ બિંદુ. આગળનું હોપ એવું સરનામું હોવું જોઈએ જ્યાં વર્કલોડ સબનેટ પહેલેથી પહોંચી શકે. વર્કલોડનું બાકીનું રૂટિંગ અકબંધ રાખો, સિવાય કે તમે જાણી જોઈને ડિફોલ્ટ રૂટ બદલવાનું નક્કી કર્યું હોય.
ઉપકરણને તેના પોતાના સબનેટમાં રાખો અને ખાતરી કરો કે શાખા ટ્રાફિક ઉપકરણ પર મોકલતો રૂટ ઉપકરણના પોતાના આઉટબાઉન્ડ માર્ગને પણ પકડતો નથી. આવો લૂપ શૂન્ય જવાબો સાથેના સ્વસ્થ ટનલ જેવો લાગે છે, અને રાત્રે 2 વાગ્યે તેને ડિબગ કરવો ખૂબ જ કષ્ટદાયક છે.
જે NIC ફ્લેગ બધા ભૂલી જાય છે
Azure માં દરેક NIC માટે IP ફોરવર્ડિંગ સેટિંગ છે, અને તે ડિફોલ્ટ રૂપે બંધ છે. તે એટલા માટે છે કે ફોરવર્ડિંગ કરતું NIC પોતાના સિવાયના કોઈને સંબોધિત પેકેટ મેળવે છે, અને તેમને ચૂપચાપ કાઢી નાખવું બાકીના બધા માટે સુરક્ષિત ડિફોલ્ટ છે.
az network nic update --resource-group rg-net --name appliance-nic --ip-forwarding true એક ઇન્ટરફેસ માટે તેને ચાલુ કરે છે. Microsoft ની NIC ફોરવર્ડિંગ માર્ગદર્શિકા દરેક જોડાયેલા NIC પર આ સેટિંગની માંગ કરે છે જે ટ્રાફિક ફોરવર્ડ કરે છે, તેથી એક-NIC ઉપકરણને પણ તે NIC પર તે સેટ કરવાની જરૂર છે.
ફ્લેગ કોઈ રૂટ નથી અને કોઈ ફાયરવોલ નિયમ પણ નથી. તેને ચાલુ કરવાથી પરવાનગી મળે છે અને બીજું કંઈ નહીં.
ડિક્રિપ્ટ થયેલા પેકેટ સાથે અતિથિ શું કરે છે
ટનલ સમાપ્ત થાય પછી, ઉપકરણનો પોતાનો સ્ટેક આગળનો નિર્ણય લે છે. Linux અતિથિ પર, IPv4 ફોરવર્ડિંગ રનટાઇમ સેટિંગ છે, અને sysctl -w net.ipv4.ip_forward=1 આગલા બૂટ સુધી ટકે છે. તેને કાયમી રૂપે એક ફાઇલમાં /etc/sysctl.d/ સાચવો. વેન્ડર ઉપકરણનું પોતાનું સમકક્ષ હોય છે, અને વેન્ડર પ્લેટફોર્મમાં પેસ્ટ કરેલી Linux સૂચનાઓ સામાન્ય રીતે કંઈ જ કરતી નથી.
અતિથિ ફાયરવોલ નીતિ ફરી અલગ છે, અને વર્કલોડનું નેટવર્ક સિક્યુરિટી ગ્રુપ પણ. VM ના જાહેર સરનામા પર UDP 500 અને 4500 ની પરવાનગી ટનલને રક્ષે છે; તે એ નથી કહેતું કે ડિક્રિપ્ટ થયેલી શાખા વિનંતી વર્કલોડ પોર્ટ સુધી પહોંચી શકે છે કે નહીં.
એક વિનંતી અને તેના જવાબને અનુસરો
એક માન્ય પ્રવાહ પસંદ કરો અને તેને શરૂઆતથી અંત સુધી અનુસરો. શાખાને એક રૂટની જરૂર છે 10.0.10.0/24 સાઇટ કનેક્શન દ્વારા, ઉપકરણને વર્કલોડ સબનેટ સુધી ડિલિવરી માર્ગની જરૂર છે, અને વર્કલોડ સબનેટને શાખા તરફ પરત રૂટની જરૂર છે.
ડિઝાઇન શાખાનું સ્રોત સરનામું જાળવે છે કે તેનું ભાષાંતર કરે છે તે વહેલું નક્કી કરો. NAT બદલે છે કે વર્કલોડ શું જુએ છે, તેથી તેના પ્રવેશ નિયમોએ તમે ખરેખર પસંદ કરેલું મોડેલ વર્ણવવું જોઈએ, અનુમાનિત ગેટવે સરનામું નહીં.
સફળ હેન્ડશેક તે સાંકળની એક કડી સાબિત કરે છે. જ્યારે જવાબ તે જ ઉપકરણ દ્વારા પાછો આવે છે અને વર્કલોડની પોતાની નીતિ તેને મંજૂરી આપે છે ત્યારે માર્ગ પૂર્ણ થાય છે.