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

તમારી પાસે હજુ શું છે તે ફરી જુઓ

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

PathDepends onUsually fails when
Provider consoleAccount access and the provider's own APICredentials live in a wiki only reachable over the tunnel
Management subnetA second interface and its own routingThe bad change was a global route or firewall policy
Second tunnelA different listener, port and credentialsBoth listeners were changed in the same edit
Physical or local consoleBeing in the buildingNobody has been in the building for a year

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

સ્વતંત્રતા એ નિર્ભરતાનો પ્રશ્ન છે

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

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

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

એક નિયંત્રિત ફેરફાર માટે બીજો રસ્તો વાપરો

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

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

યાદશક્તિથી નહીં, પુનઃપ્રાપ્તિ માર્ગથી ચકાસો

જે ચકાસણી મહત્વની છે તે એ છે કે સામાન્ય માર્ગ પાછો આવે છે કે નહીં, અને પુનઃપ્રાપ્તિ સત્ર એ જ જગ્યા છે જ્યાં તમે તેને ક્રમમાં પુષ્ટિ કરો છો:

systemctl status openvpn-server@server --no-pager
ss -lntup | grep -E ':(1194|443)\b'
nft list ruleset | sed -n '1,40p'
journalctl -u openvpn-server@server --since '-10 min' --no-pager | tail -n 30

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

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

ઇન્વેન્ટરી અદ્યતન રાખો

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

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

સંબંધિત લેખો