VPN ඒකකය ජාලයට පෙර ඇරඹී පසුව මිය යන්නේ ඇයි
සම්බන්ධතාවයට ලිපිනයක් ලැබීමට පෙර ඇරඹෙන ඒකකය අහඹු ලෙස පෙනෙන ආකාරයකින් අසාර්ථක වේ. ජර්නලයෙන් අනුපිළිවෙල ඔප්පු කරන්න, පසුව රැඳී සිටීම සහ නැවත උත්සාහය එක් කරන්න.
යන්ත්‍රය බූට් කරන්න, ලොග් වන්න, සහ ටනලය ඉහළට ආපසු තත්පර කිහිපයකින් මිය ගිය බව දැනගන්න. පැතිකඩ හොඳින් තිබුණි, සහතිකය හොඳින් තිබුණි, සහ ඉතිරි වූ එකම සලකුණ එම බූටයේ ජර්නලයයි. සාමාන්‍යයෙන් සිදු වූයේ තරඟයකි: යන්ත්‍රයට ලිපිනයක් ලැබීමට පෙරම ඒකකය ඇරඹුණි, සහ එය ප්‍රකාශ කළ අනුපිළිවෙල පෙනෙන ආකාරයේ අර්ථයක් නොදුන්නේය. පහත සියල්ල එම තරඟය සාක්ෂිවලින් ඔප්පු කිරීම සහ එය නිවැරදිව වැසීම පිළිබඳවය.
ඉලක්කය රැස්වීමේ ස්ථානයකි, කළමනාකරුවෙකු නොවේ
network-online.target ජාලයක් යනු කුමක්දැයි නොදනී. මෙය සම්බන්ධීකරණ ලක්ෂ්‍යයක් වන අතර, සම්බන්ධතාවය භාවිතයට ගත හැකි වන තෙක් ඇරඹීම ප්‍රමාද කළ යුතු සේවාව එකතු කරයි, සහ අර්ථ දැක්වීම යන්ත්‍රයට හිමි ජාල කළමනාකරුට පවරයි. බොහෝ ඩෙස්ක්ටොප් සහ සේවාදායකවල මෙයින් අදහස් වන්නේ NetworkManager හෝ systemd-networkd විසින් සපයන රැඳී සිටීමේ සේවාවයි. කිසිවක් සක්‍රීය නොකළහොත් ඉලක්කයට රැඳී සිටීමට කිසිවක් නැත, එබැවින් යමක් එය ඇදගන්නා මොහොතේම එය සම්පූර්ණ වේ, සහ එය DHCP පිළිතුරු දීමට බොහෝ කලකට පෙර විය හැකිය. ඔබේ ඒකකයේ අනුපිළිවෙල පේළිය අවංක වූ අතර එසේ වුවද නිෂ්ඵල විය.
එබැවින් පළමු ප්‍රශ්නය ඔබේ ඒකකය ප්‍රකාශ කරන දෙය නොවේ. මෙම යන්ත්‍රයේ යමක් සැබවින්ම රැඳී සිටීම සිදු කරන්නේද යන්නයි.
ඒකක ගොනුව වෙනුවට අවසාන බූටය කියවන්න
ඒකක ගොනු අභිප්‍රාය විස්තර කරන අතර, ජර්නලය සිදු වූ දේ විස්තර කරයි. එම බූටයට පමණක් ඉල්ලන්න, ඒකාකාරී කාල මුද්‍රා සමඟ, එවිට සෑම පණිවිඩයක්ම එකම ඔරලෝසුවක වාඩි වේ. පසුව පේළි දෙකක් සොයන්න: ටනල් ඒකකය ඇරඹීමට පටන් ගත් මොහොත, සහ ලිපිනය දර්ශනය වූ හෝ රැඳී සිටීමේ සේවාව අවසන් වූ මොහොත. එම සංඛ්‍යා දෙක අනුපිළිවෙලට තබන්න, තරඟය එක්කෝ තහවුරු වේ, නැතහොත් ඉවත් වේ.
යැදුම් දෘශ්‍යය මෙය තහවුරු කරයි. ටනල් ඒකකය සඳහා තීරණාත්මක දාමයක රැඳී සිටීමේ සේවාවක් නොමැති නම්, එම මාර්ගයේ කිසිවක් ඇරඹීම ප්‍රමාද නොකළ අතර, ඉලක්කය ඔබ උපකල්පනය කළ කාර්යය නොකළේය. දෘශ්‍ය දෙකක්, එක් නිගමනයක්.
systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@officeරැඳී සිටීම එක් කරන්න, පසුව නැවත උත්සාහය
සකසන ලද ඒකකය සංස්කරණය කිරීම වෙනුවට drop-in භාවිත කරන්න, එවිට පැකේජ යාවත්කාලීනය වෙනස නිශ්ශබ්දව ඉවත නොදමයි. නියෝග දෙකක් වැදගත්ය: ඒකකය ඉලක්කයට පසුව අනුපිළිවෙලට තැබිය යුතු අතර, ඉලක්කය එම ගනුදෙනුවටම ඇදගත යුතුය. අනුපිළිවෙල පමණක් ඉලක්කය අමතන්නේ නැත; කැමැත්ත එය කරයි.
OpenVPN සේවාලාභියාගේ සකසන ලද ඒකකය දැනටමත් දෙකම දරයි. අතින් ලියන ලද ඒකක සාමාන්‍යයෙන් එකක් හෝ කිසිවක් දරන්නේ නැත, එය කිසිවක් එක් කිරීමට පෙර පරීක්ෂා කිරීම වටී.
[Service]
Restart=on-failure
RestartSec=15නිශ්චිත නින්දක් උගුලක් වන්නේ ඇයි
ExecStartPre තුළ නින්දක් අනුපිළිවෙල නිවැරදි කිරීමක් ලෙස දැනෙන අතර අමතර පියවර සහිත ප්‍රමාදයක් ලෙස හැසිරේ. එය සෞඛ්‍ය සම්පන්න වූවන් ඇතුළු සෑම බූටයක්ම මන්දගාමී කරයි, සහ ඔබ තෝරාගත් සංඛ්‍යාවට වඩා සම්බන්ධතාවය වැඩි කාලයක් ගත වූ විට එය තවමත් පරාජය වේ.
ඊටත් නරක ලෙස, රැඳී සිටීමේ සේවාව ක්‍රියාත්මක වේද යන්න එය සඟවයි, එබැවින් ඊළඟ අසාර්ථකත්වය එකම ගැටලුවේ වෙනත් වේලාවක් ලෙස නොව, සම්පූර්ණයෙන් නව ගැටලුවක් ලෙස දිස් වේ. කෙටි නැවත ඇරඹීමේ ප්‍රමාදය වඩා හොඳ මෙවලමයි: සෞඛ්‍ය සම්පන්න බූටයක එයට කිසිදු වියදමක් නැති අතර පරාජය වූ තරඟය තවත් උත්සාහයක් බවට පත් කරයි. පරතරය සංයමයෙන් තබන්න, ඒකකය සාර්ථක වීමට ඉඩ දෙන්න. එය සදාකාලිකව නැවත ඇරඹෙන්නේ නම්, පැතිකඩ කැඩී ඇති අතර කොපමණ නැවත උත්සාහයක් වුවද එය වෙනස් නොකරයි, එබැවින් පරතරය වැඩි කරනවා වෙනුවට ලොගය කියවන්න.
අනුපිළිවෙල නිවැරදි වුවත් නම් තවමත් අසාර්ථක වන විට
ටනල් මාර්ගයක් සහිත සක්‍රීය ඒකකයක් යනු අනුපිළිවෙල තම කාර්යය කළ බවයි, සහ ඉතිරි දෝෂය තවත් එක් ස්ථරයක් ඉහළින් ඇත. සාමාන්‍ය ස්වරූපය වන්නේ ටනලයේ up ස්ක්‍රිප්ටය විසින් යොදන විසඳුම්කරු සැකසුමයි, සම්බන්ධතාවය හෝ විසඳුම්කරු එය රඳවා ගැනීමට සූදානම් වීමට පෙර. අසාර්ථකත්වය අතරතුර විසඳුම්කරුගේ තත්ත්වය ටනල් ඒකකය නැවත ඇරඹීමෙන් පසු තත්ත්වය සමඟ සසඳන්න.
නැවත ඇරඹීම සොයාගැනීම් නිවැරදි කරන්නේ නම්, ඔබට වැරදි DNS සේවාදායකයක් නොව ඇරඹීමේ අනුපිළිවෙලේ දෝෂයක් ඇත, සහ එම දෙකට වෙනස් නිවැරදි කිරීම් අවශ්‍යය. පසුව සේවා නැවත ඇරඹීමක් වෙනුවට සීතල බූටයකින් සියල්ල ඔප්පු කරන්න, මන්ද නැවත ඇරඹීම දැනටමත් ඉහළට ඇති ජාලයක් සමඟ ක්‍රියා කරන අතර ඔබ හඹා යන දෝෂය හරියටම සඟවයි. සම්බන්ධතාවය හිතාමතා මන්දගාමී කර නැවත නැවත කරන්න, සහ ජාලය වේගවත් විට පමණක් ක්‍රියා කරන ඒකකය තවමත් කැඩී ඇති ලෙස සලකන්න.