Azure P2S VPN નો પરત ટ્રાફિક ફક્ત એક જ દિશામાં કામ કરે છે

ટનલ આઇકન લીલું છે, NSG પરવાનગી આપતું લાગે છે, અસરકારક રૂટ સાચા લાગે છે, અને તેમ છતાં VM જોડાયેલા ક્લાયન્ટ તરફ પાછું કનેક્શન ખોલી શકતું નથી. સામાન્ય ધારણા એ છે કે કાર્યરત point-to-site ટનલ સમમિતીય છે: જો ક્લાયન્ટ VM સુધી પહોંચે, તો VM ક્લાયન્ટ સુધી પહોંચે. એ ધારણા તર્કની ભૂલ છે, ગોઠવણીની નહીં. ટનલ વણમાગી પ્રવાહની એક દિશા વહન કરી શકે અને બીજી ફેંકી શકે, અને સુધારો એ પર આધાર રાખે કે કયો સ્તર તેને ફેંકે છે.

દંતકથા: જોડાયેલી ટનલ એ દ્વિદિશા ટનલ છે

VPN ટનલ નીતિ-માર્ગ છે, તાર નહીં. દરેક દિશા સિલેક્ટર, રૂટ અને ફિલ્ટર સાથે મેળવવામાં આવે છે, અને તેમાંથી કોઈપણ એક દિશાને મંજૂરી આપીને બીજીને અવરોધી શકે છે.

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

પહોંચ ચકાસતા પહેલા દિશા ચકાસો

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

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

IKEv2 point-to-site પરત માર્ગ સામાન્ય શંકાસ્પદ છે

આ લેખ પાછળના Azure અહેવાલમાં, એક ક્લાયન્ટ IKEv2 દ્વારા VM સુધી પહોંચી શકતો હતો, પરંતુ VM થી ક્લાયન્ટ તરફનું આવક ICMP નિષ્ફળ રહ્યું જ્યાં સુધી ગેટવેનો ટનલ પ્રકાર OpenVPN પર બદલાયો નહીં. અહેવાલકર્તા જણાવે છે કે Microsoft એ IKEv2 point-to-site માર્ગમાં મર્યાદા પુષ્ટિ કરી છે, જ્યાં ક્લાયન્ટે સેશન શરૂ ન કર્યું હોય ત્યાં સુધી VM થી ક્લાયન્ટ તરફનો પરત ટ્રાફિક સમમિતીય રીતે રૂટ થતો નથી. IKEv2 ટ્રાફિક સિલેક્ટર પર આધાર રાખે છે, અને ગેટવેએ તે કિસ્સામાં પરત દિશાનું પાલન કર્યું નહીં.

તેથી OpenVPN સામાન્ય રીતે વધુ સારો ટનલ પ્રકાર બનતો નથી. તે ટનલ પ્રકારને આ વર્કલોડ માટેની કસોટી મેટ્રિક્સમાં ચલ બનાવે છે.

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

દંતકથા: બ્રોડકાસ્ટ શોધ VNet સીમા ઓળંગે છે

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

બ્રોડકાસ્ટ શોધને DNS નામ, ડિરેક્ટરી સેવા અથવા સ્પષ્ટ સાથી-યાદી સાથે બદલો. જો એપ્લિકેશન પાસે unicast વિકલ્પ ન હોય, તો ડિઝાઇનને વિશાળ ટનલ નહીં, અલગ શોધ પ્રક્રિયા જોઈએ.

શું બદલવું, અને તે કેવી રીતે સાબિત કરવું

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

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