ඔබේ split tunnel නියමය සේවාවක් සමඟ ගැලපීම නැවතුණේ ඇයි

split tunneling සාමාන්‍යයෙන් එක් ක්‍රමයකින් හෝ දෙකකින් අසාර්ථක වේ. ටනලය තුළ තිබිය යුතු රථවාහන එය වටා යයි, නැතහොත් පිටත රැඳිය යුතු රථවාහන ඇතුළට ඇද ගනු ලැබේ. පසුගිය නියමයේ අසාර්ථකත්වය පළමු ආකාරයයි, එය වඩාත් ව්‍යාකූල කරයි, මන්ද නියමය ලියා ඇති පරිදිම ක්‍රියාත්මක වේ. වෙනස් වූයේ ගමනාන්තයයි: සේවාව දැන් නියමය කිසිදා නම් නොකළ ලිපිනයක ප්‍රතිචාර දක්වයි, ටනලයේ කිසිවක් වැරදි නැත.

නියමය සවි කරන්නේ කුමක්ද සහ DNS ආපසු දෙන්නේ කුමක්ද

split-tunnel නියමයක් යනු ගමනාන්ත පිළිබඳ ස්ථිතික ප්‍රකාශයක් වන අතර, සාමාන්‍යයෙන් prefix, මාර්ගය හෝ ලිපින ලැයිස්තුවක් ලෙස ප්‍රකාශ වේ. යැවීමේ අවස්ථාවේ දී පැකට්ටුවේ ගමනාන්තයට එරෙහිව එය ඇගයේ. hostname යනු ජීවිත කාලයක් සහ cache එකක් සහිත ලිපින කුලකයක් ආපසු දෙන සෙවීමක් වන අතර, පිළිතුර resolver, ප්‍රශ්න වර්ගය සහ මිනිත්තුව අනුව වෙනස් විය හැක.

එම වස්තූන් දෙක කිසිදා එකිනෙක සමඟ සාකච්ඡා නොකරයි. නියමය ලැබුණු prefix එක සමඟ ගැලපීම දිගටම කරගෙන යයි, සේවාව ලබා දෙන ලිපිනය දිගටම වෙනස් කරයි, ඒවා අතර පරතරය නිහඬව පළල් වේ. එබැවින් රෝග ලක්ෂණය ප්‍රදායික සැපයුම්කරු මාරුවීමකින් හෝ සහතික අලුත් කිරීමකින් පසුව දිස්වේ, වින්‍යාස වෙනසකින් පසුව නොවේ. කිසිවකු ටනලය සංස්කරණය නොකළ නිසා කිසිවකු ටනලය දෙස නොබලයි, රෝග විනිශ්චය ප්‍රතිපත්තිය දෙසට නොව යෙදුම දෙසට යොමු වේ.

ගැලපීම බිඳී යන ක්‍රම තුනක්

ප්‍රකට අවස්ථාව වන්නේ මාරු වූ සේවාවක්: ක්‍රියාකරු එයට නව ලිපිනයක් දුන්නා, DNS අනුගමනය කළා, ව්‍යතිරේකය අනුගමනය නොකළා. දෙවැන්න නියමය කිසිදා ආවරණය නොකළ ලිපින පවුලක් වන අතර, එය සිදුවන්නේ නමක් IPv4 සඳහා පමණක් වූ ව්‍යතිරේකය නොසලකා හරින AAAA වාර්තා ආපසු දීම ආරම්භ කරන විටය. තෙවැන්න resolver වෙනසක්: අභ්‍යන්තර සහ පොදු දර්ශනයක් එකම නමට වෙනස් ලිපින ආපසු දිය හැකි බැවින් ඔබේ යෙදුම භාවිතා කරන ලිපිනය ඔබ පරීක්ෂා කළ ලිපිනය නොවේ.

cache කළ සම්බන්ධතාවය සිව්වැනි ප්‍රභේදයක් වන අතර එය මඟ හැරීම පහසුය. යෙදුම තවමත් පැයකට පෙර විසඳා ගත් ලිපිනයක් සමඟ කතා කරමින් සිටිය හැකි අතර, එයින් අදහස් වන්නේ ඔබේ නව සෙවීම සහ එහි විවෘත socket එක සේවාව පිහිටා ඇති තැන ගැන එකඟ නොවන බවයි.

යෙදුම සැබවින්ම භාවිතා කරන ගමනාන්තය කියවන්න

බ්‍රව්සර් ටැබයට නොව මෙහෙයුම් පද්ධතියට සහ socket වගුවට අසන්න. සෙවීම නම දැන් විසඳෙන්නේ කුමකටද යන්න පිළිතුරු දෙයි, socket වගුව ප්‍රක්‍රියාව සම්බන්ධ වී ඇති ලිපිනය පෙන්වයි, එය වැඩිමහල් විය හැක. න්‍යායක් සකස් කිරීමට පෙර දෙකම ධාවනය කරන්න, මන්ද ඒවා අතර වෙනස දළ වශයෙන් අවස්ථා භාගයක පිළිතුරම වේ.

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

පසුව නියමය ආවරණය කරන දෙය සමඟ සසඳන්න. වත්මන් ලිපිනය ව්‍යතිරේකයෙන් පිටත වැටී ඉල්ලීම තවමත් අසාර්ථක වේ නම්, ටනල වින්‍යාසය ස්පර්ශ නොකර ඔබ හේතුව සොයාගෙන ඇත. යෙදුම නියමය සමඟ ගැලපෙන ලිපිනයකට සම්බන්ධ වී ඉල්ලීම තවමත් අසාර්ථක වේ නම්, ගැටලුව ටනලයෙන් එහා ඇති අතර මෙය වැරදි විමර්ශනයකි.

රෝග ලක්ෂණය නොව යාන්ත්‍රණය අලුත්වැඩියා කරන්න

නිෂ්පාදිතය නඩත්තු කරන domain පදනම් සැලැස්මට සහාය දක්වන්නේ නම්, එය භාවිතා කර එහි ලේඛනගත නැවුම් කිරීම සහ විෂය පථයේ හැසිරීම අනුගමනය කරන්න. එය ස්ථිතික අනුමානයක් නඩත්තු කරන ලද පිළිතුරකින් ප්‍රතිස්ථාපනය කරයි, විශේෂාංගය ලේඛනගත පරිදි ක්‍රියා කරන බවට රඳා පැවතීමේ පිරිවැයක් සමඟ.

සැලැස්ම ස්ථිතික ලැයිස්තුවක් මත රඳා පවතී නම්, එයට හිමිකරුවෙකු සහ යාවත්කාලීන සැලැස්මක් දෙන්න. ලිපිනය සොයා ගන්නා ආකාරය, වෙනස අනුමත කරන්නේ කවුද සහ ලැයිස්තුව සැපයුම්කරු මාරුවීම අනුගමනය කරන වේගය සැලැස්ම කියැවිය යුතුය. හිමිකරුවෙකු නොමැති ලැයිස්තුවක් යනු දන්නා හේතුවක් සහිත අනාගත බාධාවකි.

කෙටි පරීක්ෂණයක දී දුටු සෑම ලිපිනයක්ම ග්‍රහණය කිරීම සඳහා පමණක් ව්‍යතිරේකය විශාල අසල්වැසි ජාලයකට පළල් නොකරන්න. එය අලුත්වැඩියාවක් නොවේ; එය ආරක්ෂක මායිමේ ස්ථිර වෙනසක් වන අතර, නියමය පවතින තාක් අදාළ නොවන සේවා ටනලය මග හැරීමට නිහඬව ඉඩ දෙනු ඇත.

අභිප්‍රායේ දෙකොටසම තහවුරු කරන්න

split-tunnel සැලැස්මකට අභිප්‍රායන් දෙකක් ඇත, අලුත්වැඩියාව දෙකම රැකිය යුතුය. ආරක්ෂිත සේවාව ටනලය හරහා යා යුතුය, බැහැර කළ කාණ්ඩ එය වටා යාම දිගටම කළ යුතුය. අලුත්වැඩියා කළ ගමනාන්තයට නව සම්බන්ධතාවයක් පරීක්ෂා කරන්න, පසුව පිටත රැඳිය යුතු දෙයක් පරීක්ෂා කරන්න.

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

නව ලිපිනය, තෝරාගත් යාන්ත්‍රණය සහ දිනය සටහන් කරන්න. එම සටහන ඊළඟ පුද්ගලයාට VPN තම ස්වකීය වින්‍යාසය අහඹු ලෙස නොසලකා හැරිය යැයි නිගමනය කිරීමෙන් වළක්වයි.