C# OpenVPN સ્ટેટ ઓબ્ઝર્વર: સેશન પર નજર રાખો, NIC પર નહીં

ટનલ મરતી વખતે પણ તમારી એપ્લિકેશન કામ ચાલુ રાખે છે. Wi-Fi હજી ચાલુ છે, ઇન્ટરનેટ હજી જવાબ આપે છે, અને એપ્લિકેશન જે પ્રાઇવેટ API પર આધાર રાખે છે તે અગમ્ય બની ગયું છે. લોકો સામાન્ય રીતે અહીં જે .NET ઘટના તરફ વળે છે, NetworkAvailabilityChanged, તે આ પરિસ્થિતિનું બિલકુલ વર્ણન કરતી નથી. તે મશીનની એકંદર સ્થિતિમાં ફેરફારની જાણ કરે છે, અને VPN ડિસ્કનેક્ટ અને ફરી કનેક્ટ દરમિયાન પણ તે સ્થિતિ સાચી રહી શકે છે. ઓબ્ઝર્વરે ટનલનો માલિક ક્લાયન્ટ જોવો જોઈએ, નેટવર્ક સ્ટેકનો તેનો સારાંશ નહીં.

ઉપલબ્ધતા એકંદર છે, તમારી ટનલ નહીં

NetworkAvailabilityChanged ત્યારે સક્રિય થાય છે જ્યારે મશીનનો એકંદર ઉપલબ્ધતા જવાબ બદલાય છે, અને તે જવાબ loopback અથવા ટનલ સિવાયના દરેક સક્રિય ઇન્ટરફેસની ગણતરી કરે છે.

Wi-Fi ચાલુ હોય ત્યારે VPN ડ્રોપ થવાથી તે જે માપે છે તેમાં કંઈ બદલાતું નથી, તેથી જે નિષ્ફળતા તમારા માટે મહત્વની છે તે દરમિયાન ઘટના શાંત રહી શકે છે.

સ્ટેટ સ્ટ્રીમ ટનલનો માલિક ક્લાયન્ટનો છે

કયો ઘટક કનેક્શનનો માલિક છે તે ઓળખો: OpenVPN GUI કે સેવા, OpenVPN Connect, અથવા તમારી એપ્લિકેશને શરૂ કરેલી અને નિયંત્રિત કરતી પ્રક્રિયા. આ અલગ માલિકો છે જેમની પાસે અલગ સમર્થિત ઇન્ટરફેસ છે, અને ઓબ્ઝર્વરે ડિપ્લોયમેન્ટને અનુરૂપ ઇન્ટરફેસ વાપરવો જોઈએ. જે OpenVPN પ્રક્રિયા સાથે જોડાવાની તમને અધિકૃતતા છે, તેના માટે મેનેજમેન્ટ ઇન્ટરફેસ વર્તમાન સ્થિતિ, ઇતિહાસ અને રિયલ-ટાઇમ સૂચનાઓની જાણ કરે છે. સ્થાનિકીકૃત GUI કૅપ્શનમાં connected શબ્દ શોધવાને બદલે દસ્તાવેજીકૃત માળખાગત સંદેશાઓનું વિશ્લેષણ કરો.

મેનેજમેન્ટ ચેનલ વિશેષાધિકાર પ્રાપ્ત નિયંત્રણ સપાટી છે, તેથી નવો શ્રોતા ખોલશો નહીં અને GUI પાસે પહેલેથી જ હોય તેવી ચેનલ માટે તેની સાથે ઝઘડો કરશો નહીં.

જનરેશન ગાર્ડ જૂની પરિણામો રોકે છે

દરેક અવલોકન ચોક્કસ કનેક્શન પ્રયાસનું છે. નવો પ્રયાસ શરૂ થાય, ચેનલ ખોવાય અને ક્લાયન્ટ નિકાસની જાણ કરે ત્યારે જનરેશન કાઉન્ટર વધારો.

A કનેક્શન દરમિયાન શરૂ થયેલી પ્રોબ ધ્યાનમાં લો. ટનલ પડે છે, B કનેક્શન શરૂ થાય છે, અને પછી Aની વિલંબિત HTTP સફળતા આવે છે. ગાર્ડ વિના, તે જૂનું પરિણામ ડિસ્પ્લેને લીલું કરી દે છે જ્યારે B હજી પ્રમાણિત કરી રહ્યું હોય. રદ કરવાથી બગડેલું કામ ઘટે છે, અને જનરેશન તપાસ જ તેને રોકે છે કે જૂનું પૂર્ણ થવું વર્તમાન સ્થિતિ ન બને:

var generation = _generation;
var reachable = await ProbeAsync(token);
if (generation != _generation) return;
Publish(reachable);

UI ડિસ્પેચની આસપાસ પણ એ જ નિયમ લાગુ કરો, કારણ કે માર્શલ કરેલું અપડેટ જનરેશન આગળ વધ્યા પછી પણ આવી શકે છે.

ઇનિશિયલાઇઝેશન અને ફરી કનેક્ટ એક જ જીવનચક્ર છે

પ્રથમ કનેક્શન, ફરી કનેક્શન અને ચેનલ ગુમાવવાને એક જ નિયમસમૂહ સાથે એક જ જીવનચક્ર ગણો:

• જ્યાં ઇન્ટરફેસ પરવાનગી આપે ત્યાં એક પગલામાં વર્તમાન સ્થિતિ વાંચો અને સૂચનાઓ પર સબ્સ્ક્રાઇબ કરો.
• દરેક અવલોકનને કનેક્શન ઓળખ અને જનરેશન સાથે ટૅગ કરો.
• ફરી કનેક્ટ, નિકાસ અથવા ખોવાયેલી અવલોકન ચેનલ પર તૈયારી અમાન્ય કરો.
• માલિક ઇનિશિયલાઇઝેશન પૂર્ણ થવાની જાણ કરે તે પછી જ પ્રાઇવેટ સંસાધનની પ્રોબ કરો.
• ફક્ત તે પરિણામો પ્રકાશિત કરો જે હજી વર્તમાન જનરેશનના છે.

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

પુરાવા જણાવો, બુલિયન નહીં

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

જાહેર IP શોધ એ પુરાવો નથી કે પ્રાઇવેટ APIએ જરૂરી માર્ગ વાપર્યો, તેથી તેને એવું હોય તેમ રજૂ કરશો નહીં.

અમલને ઓબ્ઝર્વરની બહાર રાખો

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

પછી UIનો પ્રશ્ન સરળ બને છે: જે જાણીતું છે તે તેની ઉંમર સાથે બતાવો, અને જ્યારે અજ્ઞાત હોય ત્યારે અજ્ઞાત કહો.