VPN શરૂ થયા પછી Azure VM IMDS કે WireServer સુધી પહોંચી શકતું નથી
ગેસ્ટ VPN 168.63.129.16 અને 169.254.169.254 નો રૂટ ચોરી શકે છે. સ્થિર /32 ઉમેરતા પહેલાં પોલિસી રાઉટિંગ વાંચો, અને એડમિન એક્સેસ અલગ રાખો.
VM ચાલુ છે, VPN ક્લાયન્ટ કહે છે કે કનેક્ટેડ છે, અને થોડી મિનિટો પછી Azure એજન્ટ અસ્વસ્થ હોવાનું જણાવવા લાગે છે. ક્યારેક SSH ટકી રહે છે અને પોર્ટલનું Run Command નહીં, જે લોકોને રૂટ ટેબલને બદલે એજન્ટ તરફ ધકેલે છે. ટનલ ઉપર આવતાં ગેસ્ટના પોતાના ફોરવર્ડિંગ નિર્ણયો બદલાઈ ગયા, અને સામાન્ય રીતે બે પ્લેટફોર્મ સરનામાં પહેલાં પીડિત થાય છે. હું તેને એજન્ટ નિષ્ફળતા ગણતા પહેલાં રાઉટિંગ લક્ષણ ગણું છું.
લક્ષણ તૂટેલા એજન્ટ જેવું લાગે છે
નીચેનાં બંને સરનામાં ઉપાય તરીકે સૂચવવામાં આવે છે, અને તે એક જ સેવા નથી. એક માટે /32 કોપી કરવું કારણ કે તે બીજા માટે કામ કરતું હતું—એ જ રીતે કામચલાઉ ઉપાય એવી કાયમી ગોઠવણ બને છે જેને દૂર કરવાની કોઈ હિંમત કરતું નથી.
જે ક્રમ કામ કરે છે તે છે: પહેલાં ખાતરી કરો કે નિષ્ફળ કૉલ ખરેખર કયા સરનામાને લક્ષ્ય બનાવે છે, પછી ગેસ્ટ તેને કેવી રીતે ઉકેલે છે તે વાંચો. બાકીનું બધું વધારાના પગલાં અને લાંબી ફેરફાર વિન્ડો સાથેનું અનુમાન છે.
168.63.129.16 જાહેર લક્ષ્ય નથી
168.63.129.16 Azure નું ખાસ વર્ચ્યુઅલ પ્લેટફોર્મ સરનામું છે, અને તેની એક ભૂમિકા WireServer છે, જે VM એજન્ટ ફેબ્રિક સાથે વાત કરવા વાપરે છે. Microsoft દસ્તાવેજ કરે છે કે એજન્ટનો TCP પોર્ટ 80 અને 32526 તરફનો ટ્રાફિક ઉપલબ્ધ રહેવો જોઈએ. તે સામાન્ય ઇન્ટરનેટ હોસ્ટ નથી, અને તે એવી વસ્તુ નથી જે સંપૂર્ણ-ટનલ VPN એ દૂરના એક્ઝિટ સુધી લઈ જવી જોઈએ. તેથી સ્વસ્થ દેખાતી ટનલ પણ એજન્ટને ભૂખ્યો રાખી શકે છે.
પ્લેટફોર્મ સરનામાનું દસ્તાવેજીકરણ એ પણ કહે છે કે આ સરનામું વપરાશકર્તા-વ્યાખ્યાયિત રૂટને આધીન નથી, જે Azure ફેબ્રિકની લાક્ષણિકતા છે, તમારા ગેસ્ટ વિશેનું વચન નથી. સ્થાનિક ફાયરવોલ નિયમ કે VPN ક્લાયન્ટની પોતાની રાઉટિંગ પોલિસી હજી પણ માર્ગ તોડી શકે છે, અને તેમાંથી કંઈ પણ VNet ના રૂટ ટેબલમાં રહેતું નથી.
જો એજન્ટ જ સમસ્યાનું જણાવે છે, તો કંઈ પણ ફરીથી ઇન્સ્ટોલ કરતા પહેલાં સેવાની સ્થિતિ અને તે સરનામા સુધીનો માર્ગ તપાસો.
169.254.169.254 ના પોતાના નિયમો છે
169.254.169.254 એ Azure Instance Metadata Service માટેનું link-local સરનામું છે. તેના પ્રતિ વિનંતીઓની પોતાની આવશ્યકતાઓ છે: પ્રાથમિક NIC અને પ્રાથમિક IP, સરનામાને સમર્થન આપતી DHCP ગોઠવણ, અને કોઈ પણ HTTP પ્રોક્સીને બાયપાસ કરવી. દૂરના VPN એક્ઝિટ કે મનસ્વી ઇન્ટરનેટ ગેટવે દ્વારા તેમને મોકલવું એ Microsoft વર્ણવે છે તે એક્સેસ મોડલ નથી.
એ પ્રોક્સી કલમ એવા લોકોને પકડે છે જેમણે રૂટ ઠીક કર્યો છે અને હજી નિષ્ફળતા જુએ છે. ગેસ્ટ HTTP પ્રોક્સી IMDS તોડી શકે છે જ્યારે ip route get બરાબર તમે અપેક્ષા રાખો તે ઇન્ટરફેસ પરત આપે છે, તેથી રૂટની સાથે પ્રોક્સી બાકાતો પણ તપાસો.
આ ડિબગ કરતી વખતે મેટાડેટા પ્રતિસાદો સપોર્ટ ટિકિટમાં પેસ્ટ કરશો નહીં. તેમાં એવા ઓળખપત્રો અને ઇન્સ્ટન્સ વિગતો હોઈ શકે છે જે ઘટનાથી વધુ ટકે છે.
ગેસ્ટના પોલિસી રાઉટિંગ વાંચો, ફક્ત મુખ્ય ટેબલ નહીં
Linux ગેસ્ટ પર ત્રણ માત્ર-વાંચન આદેશો સ્તરોને અલગ પાડે છે: પોલિસી નિયમો માટે ip -4 rule show, પછી કર્નલ ખરેખર જે નિર્ણયો લે છે તે માટે ip -4 route get 168.63.129.16 અને ip -4 route get 169.254.169.254. VPN જોડાય તે પહેલાં અને પછી તેમને ચલાવો. તે બે આઉટપુટ વચ્ચેનો તફાવત તમારો ફેરફાર-સમૂહ છે, અને ક્લાયન્ટે શું કર્યું તે અંગેના કોઈ પણ અનુમાન કરતાં તે વધુ ઉપયોગી છે.
પોલિસી નિયમો ઇન્સ્ટોલ કરતો VPN ક્લાયન્ટ મુખ્ય ટેબલને અડ્યા વિના રાખીને પણ તે લુકઅપને ફેરવી શકે છે. તેથી ફક્ત મુખ્ય ટેબલ સુધારતો ઉપાય એક હોસ્ટ પર કામ કરતો દેખાય છે અને બીજા પર કંઈ કરતો નથી. બહુવિધ NIC વાળા ગેસ્ટ સમાન સમસ્યા બીજી બાજુથી ઉમેરે છે, કારણ કે જવાબ નિર્ભર કરે છે કે નિયમ કઈ NIC અને સ્રોત સરનામું પસંદ કરે છે.
જૂના ગેટવે દ્વારા બંને /32 રૂટ ઉમેરતી રેસીપીનો પ્રતિકાર કરો. link-local પ્લેટફોર્મ માર્ગ અને સામાન્ય WAN આગલું હોપ અલગ વસ્તુઓ છે, અને સર્વગ્રાહી બાકાત વાસ્તવિક પોલિસી સંઘર્ષ છુપાવે છે.
વ્યવસ્થાપન અને પુનઃપ્રાપ્તિ અલગ રાખો
તમારો SSH કે RDP પ્રતિસાદ પણ સંપૂર્ણ-ટનલ ડિફોલ્ટ દ્વારા પકડાઈ શકે છે, પણ તે પ્લેટફોર્મ એન્ડપોઇન્ટને બદલે એડમિનિસ્ટ્રેટરના અવલોકિત સરનામાને લક્ષ્ય બનાવે છે. તેને તેની પોતાની વિનંતી-પ્રતિસાદ જોડીમાંથી નિદાન કરો, અને VPN પોલિસી બદલતા પહેલાં સીરિયલ કન્સોલ જેવી સ્વતંત્ર પુનઃપ્રાપ્તિ ચેનલ રાખો. જો કોઈ ડિપ્લોયમેન્ટ VM ને ફરી ચાલુ કરે અને એજન્ટ અસ્વસ્થતા જણાવે, તો રૂટ ફેરફારને કારણે રીબૂટ થયું એમ માનવાને બદલે નોંધાયેલી ક્રિયા અને જવાબદાર સેવા તપાસો.
પછી ત્રણ પ્રવાહ અલગ-અલગ ચકાસો: તમે ખરેખર ઇચ્છતા હતા તે ખાનગી સંસાધન, સમર્થિત એજન્ટ અને પ્લેટફોર્મ સંચાર, અને વ્યવસ્થાપન માર્ગ. એકને પુનઃસ્થાપિત કરવું એ બાકીના બે ટકી ગયા છે તેનો પુરાવો નથી.
મંજૂર બાકાત ગેસ્ટ નેટવર્ક અને VPN ગોઠવણના માલિક હેઠળ લખો, જેમાં ફરી જોડાવા અને ફરી ચાલુ થવા પર શું થાય તેનો સમાવેશ થાય. Azure UDR એ ગેસ્ટનું રૂટ ટેબલ નથી, અને તેમને સંપાદિત કરવાથી સ્થાનિક પોલિસી નિયમ સુધરશે નહીં.