શા માટે nc -uz સાબિત કરી શકતું નથી કે OpenVPN સર્વર તૈયાર છે

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

UDP તપાસ શું નિરીક્ષણ કરી શકે છે અને શું નહીં

nc -uz એક ડેટાગ્રામ મોકલે છે અને નીકળી જાય છે, અને જે સ્થિતિ પરત આપે છે તે સ્થાનિક મોકલવાનું વર્ણન કરે છે. બંધ પોર્ટ ICMP port unreachable સાથે જવાબ આપી શકે છે, પરંતુ આ સ્કેન મોડનું દસ્તાવેજી વર્તન તેને નિષ્ફળતામાં ફેરવતું નથી, અને ફિલ્ટર થયેલ પોર્ટ કોઈ જ જવાબ આપતું નથી. તેથી મૌન અને સફળતા કૉલર માટે એક જ અર્થ ધરાવે છે.

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

તપાસને રૂપરેખાંકિત ટ્રાન્સપોર્ટ સાથે મેળવવું બંનેમાંથી કોઈપણ પરિણામ પર ભરોસો કરતાં પહેલાં આવે છે. UDP ડિપ્લોયમેન્ટને જુદું સંકેત જોઈએ છે, જુદો પ્રોટોકોલ નહીં.

ત્રણ કૉલર, ત્રણ જુદા પ્રશ્નો

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

આ એક જ તપાસ નથી, અને એક તપાસ ત્રણેયને પ્રામાણિકપણે આવરી શકતી નથી. પહેલા કૉલર પસંદ કરો, પછી પુરાવો.

વર્તમાન ઇન્સ્ટન્સમાંથી તપાસ બનાવો

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

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

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

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

તેને જાણી જોઈને તોડો અને તપાસ જુઓ

તપાસ ત્યારે જ વિશ્વસનીય છે જ્યારે તમે તેને નિષ્ફળ થતી જોઈ છે. સર્વર બંધ કરો, તપાસ ચલાવો અને અપેક્ષિત પરિણામની પુષ્ટિ કરો. પછી તેને ફરી શરૂ કરો અને પુષ્ટિ કરો કે તપાસ બીજા કોઈ ફેરફાર વિના પુનઃપ્રાપ્ત થાય છે.

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

બ્લોક લાઇન દ્વારા લાઇન વાંચો. netcat આદેશ છાપે છે exit=0 જ્યારે કંઈ બંધાયેલું નથી, અને એ જ આખી સમસ્યા એક લાઇનમાં છે. પ્રથમ ss કંઈ છાપતું નથી, પુનઃપ્રારંભ સફળ થાય છે, અને બીજું ss ફરી શ્રોતા બતાવે છે. જો તમારી તપાસ બંધ સર્વર સામે પાસ થાય, તો તે સ્થાનિક સ્ટેક માપે છે અને બીજું કંઈ નહીં.

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

સ્ટેટસ લાઇને શું કહેવું જોઈએ

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

તે ઓળખને વાસ્તવિક વપરાશકર્તાઓથી અલગ રાખો અને તેને તપાસને જરૂરી લઘુતમ પરવાનગીઓ આપો. વિશાળ પ્રવેશ સાથેની તૈયારી તપાસ સુવિધા માટે ઉમેરાયેલી નવી હુમલાની સપાટી છે. તેની ઓળખપત્રોને અન્ય કોઈપણ ખાતાની જેમ ફેરવો, કારણ કે પ્રમાણીકરણ બંધ કરતી તપાસ બરાબર એવા સર્વર જેવી લાગે છે જેણે ક્લાયન્ટ સ્વીકારવાનું બંધ કર્યું છે.

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