તમારું VPN ફક્ત લોગિન પછી જ કામ કરે છે, કીરિંગને કારણે

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

લોગિન તેને કેમ કામ કરાવે છે

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

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

ટનલ કોણ શરૂ કરશે તે નક્કી કરો

બે સપોર્ટેડ પેટર્ન છે, અને તેમને મિશ્ર કરવો એ આ નિષ્ફળ જવાની બીજી રીત છે. NetworkManager સિસ્ટમ-સ્કોપ્ડ કનેક્શન સક્રિય કરી શકે છે, જે યોગ્ય છે જ્યારે મશીન પહેલેથી ત્યાં તેનું નેટવર્કિંગ કેન્દ્રિત કરે છે. વૈકલ્પિક રીતે, એક સમર્પિત systemd યુનિટ સીધું VPN ચલાવે છે અને જાતે ઇન્ટરફેસનું માલિક છે.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

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

રહસ્ય ત્યાં મૂકો જ્યાં સેવા વાંચી શકે

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

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

ખરેખર જે ઘટના બને છે તેની કસોટી કરો

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

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

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

ફક્ત ઇન્ટરફેસ નહીં, રૂટ અને DNS ચકાસો

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

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

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