રીબૂટ પછી VPN સર્વરની પુનઃપ્રાપ્તિ ચકાસો: પહેલા શું તપાસવું

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

ચાર માલિકો, ચાર અલગ પરીક્ષણો

રીસ્ટાર્ટ પહેલા નક્કી કરો કે ટનલને શું પાછું લાવવાનું છે. તમે ચલાવો છો તે પરીક્ષણ અને લાગુ કરો છો તે સુધારો બંને તે જવાબ પર આધાર રાખે છે, અને ચાર સામાન્ય માલિકો છે: VPN ડેમન માટે systemd unit, WireGuard ઇન્ટરફેસ માટે wg-quick ઇન્સ્ટન્સ unit, કન્ટેનર રનટાઇમ, અથવા નેટવર્ક મેનેજર પ્રોફાઇલ. જો તમે માલિકનું નામ ન કહી શકો, તો અટકો અને તેને શોધો, કારણ કે અપેક્ષિત સ્ટાર્ટઅપ માર્ગ વિના રીબૂટ પરીક્ષણ ફક્ત એટલું કહે છે કે કંઈક થયું.

દરેક માલિક પોતાની રૂપરેખા અલગ જગ્યાએ રાખે છે. systemd દ્વારા સંચાલિત OpenVPN સર્વર શરૂ થતી વખતે તેની રૂપરેખા વાંચે છે, તેથી બૂટ વખતે ફાઇલમાં જે હોય તે જ ચાલે છે. wg-quick ઇન્ટરફેસ તેના સરનામાં, રૂટ અને DNS એ જ ફાઇલમાંથી મેળવે છે, એટલે કે શેલમાંથી હાથે ઉપર લાવેલું અને ક્યારેય unit તરીકે સક્ષમ ન કરેલું ઇન્ટરફેસ પાછું નહીં આવે. કન્ટેનર તેનું એન્ટ્રીપોઇન્ટ પાછું લાવે છે, પણ હોસ્ટના ફાયરવોલ ફેરફારો નહીં, સિવાય કે તે કન્ટેનરની બહાર હોય.

પહેલા બેઝલાઇન, નહીં તો પરિણામનો કોઈ અર્થ નથી

જ્યારે તે કામ કરે ત્યારે કાર્યરત સ્થિતિ નોંધો: ટનલ પરના સરનામાં, ક્લાયન્ટ સબનેટ માટેના રૂટ, NAT અથવા ફોરવર્ડિંગ નિયમો, સાંભળતું સોકેટ, અને ફોરવર્ડિંગ sysctl. ip addr show wg0, ip route, nft list ruleset અથવા iptables-save, ss -lunp અને sysctl net.ipv4.ip_forward મોટાભાગના હોસ્ટ પર પૂરતા છે.

સેવા કેવી રીતે શરૂ થવા માટે રૂપરેખાંકિત છે તે નોંધો, ફક્ત એ નહીં કે તે ચાલી રહી છે. systemctl is-enabled wg-quick@wg0 અને systemctl is-active wg-quick@wg0 અલગ પ્રશ્નોના જવાબ આપે છે, અને બૂટ વખતે સક્ષમ સ્થિતિ જ મહત્વની છે, જેમ systemctl(1) માં વર્ણવેલ છે. OpenVPN માટે, હોસ્ટ કઈ ટેમ્પલેટ વાપરે છે તે તપાસો, કારણ કે openvpn@server અને openvpn-server@server અલગ ડિફોલ્ટ સાથેના અલગ unit છે.

રીસ્ટાર્ટ ચલાવો અને પહેલી નિષ્ફળતા વાંચો

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

ટનલ નકામું હોય ત્યારે પણ ડેમન સક્રિય હોઈ શકે છે, અને આ સૌથી સામાન્ય ખોટો પાસ છે. જો unit ફક્ત network.target ની રાહ જુએ, network-online.target ની નહીં, તો નેટવર્ક ઓનલાઇન થવા પહેલા સ્ટાર્ટઅપ પૂર્ણ થઈ શકે છે. પ્રમાણપત્રો, કી અથવા CRL જેવી સંદર્ભિત ફાઇલો તે ક્ષણે વાંચી ન શકાય તેવી હોઈ શકે, કારણ કે માઉન્ટ અથવા સિક્રેટનો માર્ગ હજી તૈયાર નથી. unit નો જર્નલ વાંચ્યા સિવાય બંનેમાંથી કોઈ સમસ્યા systemctl status માં દેખાતી નથી.

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

તમારો સુધારો નક્કી કરતી ત્રણ શરતો

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

સેટિંગની માલિકી હોય ત્યાં જ સુધારો કરો. ફોરવર્ડિંગ sysctl drop-in માં મૂકો, NAT નિયમો બૂટ વખતે લોડ થતા નિયમસમૂહમાં મૂકો, unit ને શરૂ કરવાને બદલે સક્ષમ કરો, અને સિક્રેટ એવા માર્ગ પર રાખો જે unit શરૂ થવા પહેલા અસ્તિત્વમાં હોય. unit માં ઊંઘ ઉમેરવી અવલંબનને ઘોષિત કરવાને બદલે છુપાવે છે.

runbook માં પરિણામ નોંધો

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

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