එකවර VPN යෙදුම් දෙකක්: ඇත්තටම අදාළ වන්නේ කුමන kill switch ද?
දෙවන VPN සේවාදායකයා කිසිදා පළමුවැන්නාගේ kill switch උරුම නොකරයි. කුමන ප්‍රතිපත්තිය අදාළ වේද යන්න කොන්දේසි තුනක් තීරණය කරයි, සහ ඔබේ ප්‍රතිපත්තිය පරීක්ෂා කරන ආකාරය.
VPN සේවාදායකයන් දෙදෙනෙකුට එකිනෙකා අසල ක්‍රියා කළ හැකි නමුත් ඔවුන්ගේ kill switch එක ප්‍රතිපත්තියකට ඒකාබද්ධ නොවේ. සෑම සේවාදායකයාම තමන්ගේම උමඟ සඳහා නීති ස්ථාපනය කරන අතර අනෙකා සිටින බව කිසිවෙකු නොදනී. පළමුව සම්බන්ධ වී තිබූ වැඩ සේවාදායකයා සමඟ මට මෙය විඳින්නට සිදු විය: දෙවන යෙදුමට තම අතට අත දීම සම්පූර්ණ කළ නොහැකි විය, „Connecting“ මත විනාඩි දහයක් රැඳී සිටියේය, පළමු උමඟ නිහඬව සියල්ල ගෙන ගියේය. දෙවන යෙදුම ආරක්ෂා වේද යන්න කොන්දේසි තුනක් මත රඳා පවතී, අයිකන දෙකම සම්බන්ධයි යැයි පවසනවාද යන්න මත නොවේ.
kill switch සැබවින්ම සීමා වන්නේ කුමකටද
මෙහෙයුම් පද්ධතිය තුළ එකම kill switch ධජයක් නොමැත. එවැන්නක් ප්‍රචාරය කරන සේවාදායකයා නීති කට්ටලයක් ස්ථාපනය කරයි: මගේ උමඟ හරහා පිටතට නොයන සියල්ල ඉවත් කරන්න, සහ උමඟ නැති වූ විට බොහෝ විට fail closed ලෙස ක්‍රියා කරන්න. Linux තුළ මෙය සාමාන්‍යයෙන් nftables හෝ iptables දාමයකි, Windows තුළ Windows Filtering Platform පෙරහන් කට්ටලයක්, Android සහ iOS තුළ උමඟ සේවාවේම මාර්ගකරණය සහ VPN නොමැතිව සම්බන්ධතා අවහිර කරන එම පද්ධති සැකසුම. Android VPN මාර්ගෝපදේශය මෙම සේවා ආකෘතිය විස්තර කරයි ඔබට වේදිකාවේ දෘෂ්ටිය අවශ්‍ය නම්.
විෂය පථය තමයි වැදගත් කොටස. „wg0 පිටතට යන අතුරුමුහුණතේ පැකට්ටු පමණක් අවසර දෙන්න“ වැනි නීතියක් දෙවන උමඟක් තිබේද යන්න ගැන තැකීමක් නොකරයි. වෙනත් සේවාදායකයෙක් wg1 එසවුවහොත්, පළමු සේවාදායකයාගේ නීති එම පැකට්ටු සාමාන්‍ය ගමනාගමනය ලෙස සලකයි: සාමාන්‍යයෙන් ඉවත් කෙරේ, සමහර විට අවසර දෙයි. කෙසේ වුවද තීරණය ගන්නේ පළමු සේවාදායකයාය, දෙවන යෙදුම බලා සිටින බව ඔහු නොදනී.
කවුරුන් ආවරණය වේද යන්න තීරණය කරන කොන්දේසි තුන
සෑම සංයෝජනයක්ම ගණන් කිරීම අවශ්‍ය නැත. ප්‍රශ්න තුනක් මිනිත්තු කිහිපයකින් මෙය තීරණය කරයි.
- වේදිකාව දෙවන උමඟකට ඉඩ දෙන්නේද? බොහෝ Android දුරකථන සහ iPhone එක් භාවිතා කරන්නෙකුගේ පැතිකඩකට සක්‍රීය VPN සේවාවක් එකක් පමණක් පිළිගනී, එබැවින් දෙවන යෙදුමට කිසිදා උමඟක් නොලැබේ, කිසිවක් ක්‍රියාත්මක නොකරයි. ඔබට එක් ප්‍රතිපත්තියක් ලැබේ, ඉඩ දිනාගත් යෙදුමෙන්.
- පෙරනිමි මාර්ගය අයිති කුමන ක්‍රියාවලියටද? Windows, macOS සහ Linux උමඟ දෙකක් පහසුවෙන් දරාගනී. පෙරනිමි මාර්ගය අවසන් වරට හෝ වඩා හොඳ මෙට්‍රිකයක් සමඟ සකස් කළ සේවාදායකයාට හිමිය, අනෙක් සේවාදායකයා සම්බන්ධ නමුත් නිෂ්ක්‍රීයයි. Linux තුළ wg-quick හි පෙරනිමි මාර්ග ප්‍රකාරය පෞද්ගලික වගුවක් සහ fwmark නීතියක් සහිත ප්‍රතිපත්ති පාදක මාර්ගකරණය භාවිත කරයි, එබැවින් දෙවන wg-quick උමඟ පළමුවැන්න ප්රතිස්ථාපනය කරනවාට වඩා තරඟකාරී නීතියක් එකතු කරයි.
- දෙවන සේවාදායකයාට තමන්ගේම සේවාදායකයට ළඟා විය හැකිද? පළමු kill switch පෙරනිමි ප්‍රතික්ෂේපය නම්, දෙවන යෙදුමේ බාහිර අන්ත ලක්ෂ්‍යය තවත් ඉවත් කළ ගමනාන්තයක් පමණි. එය නිහඬව නැවත උත්සාහ කරයි, කිසිදා දෝෂයක් වාර්තා නොකරයි.
කෙටි අනුවාදය, සහාය ත්‍රෙඩ් සඳහා:
| Setup | What you actually get |
|---|---|
| Second client cannot hold a tunnel | One active policy; the other app only reports that it is waiting |
| Both tunnels up, second took the default route | The first kill switch blocks traffic it never meant to touch; the connection dies, or leaks if its rules are broad |
| First kill switch allows only its own endpoint and interface | Second client never connects; first tunnel unaffected |
| Both up, DNS written by whichever client ran last | Name resolution breaks for one side when either tunnel drops |
එම පේළි දෙකක් පද්ධති තැටියේ අයිකනයෙන් එකම ලෙස පෙනේ, එබැවින් අයිකනය මෙහි ඇති දුර්වලම සාක්ෂියයි.
පළමුව අසාර්ථක වන්නේ කුමක්ද, එය කෙසේ පෙනේද
අනෙක සුවපත්ව සිටියදී සේවාදායකයෙක් „Connecting“ මත සිරවී සිටීම සෑම විටම පාහේ අන්ත ලක්ෂ්‍ය බඩගින්නකි: ක්‍රියාත්මක kill switch දෙවන සේවාදායකයාගේ තම සේවාදායකය වෙත අතට අත දීම ඉවත් කරයි. මෙය ලාභදායී ලෙස තහවුරු කරන්න පළමු සේවාදායකයාගේ අවහිර කිරීමේ නීති එක් උත්සාහයක් සඳහා තාවකාලිකව නවත්වා. දෙවැන්නා වහාම සම්බන්ධ වුවහොත් ප්‍රශ්නයට පිළිතුරු ලැබී ඇත.
DNS දෙවන අසාර්ථකත්වයයි. සේවාදායකයන් තම අතුරුමුහුණත සඳහා විසඳන සැකසුම් සකසයි, සමහරු ගෝලීය ලැයිස්තුවම කෙළින්ම ලියා දමයි. උමඟ දෙකම ඉහළින් ඇති විට විමසුම් එක් පැත්තකින් පිටතට යා හැකි අතර විසඳනය අනෙක් පැත්තට අයත් වේ. කුමන හෝ යෙදුමක් විසන්ධි කරන්න, ඉතිරි වූ යෙදුම ළඟා නොවන නාම සේවාදායකයක් රඳවා ගනී: පිටු මිනිත්තුවක් රැඳී පසුව නැවත විසඳේ, VPN තවමත් සම්බන්ධ ලෙස පෙන්වයි.
තෙවැන්න මාර්ග සැලෙන බවයි. නැවත සම්බන්ධතා පෙරනිමි මාර්ගය නැවත පිළිවෙළ කරයි, අතුරුමුහුණතට බැඳුණු kill switch එය අනුගමනය නොකරයි. මොහොතකට පෙර උමඟ තුළ තිබූ ගමනාගමනය දැන් ඉවත් කිරීමේ නීතියකට ගැළපේ, එය පරිශීලකයාගේ පැත්තෙන් හදිසියේ ක්‍රියා කිරීම නවත්වන VPN ලෙස කියවේ.
ඇත්තටම කුමන ප්‍රතිපත්තිය ක්‍රියාත්මකද පරීක්ෂා කරන්න
මෙය හානිකර නොවන ගමනාගමනය සමඟ කරන්න, ඔබට අහිමි වන දෙයක් සමඟ නොවේ.
Linux තුළ කර්නලයෙන් අසන්න කවුරුන් දිනනවාද සහ ගිනිපවුර බැඳෙන්නේ කුමකටද කියා. ip -4 route show default පිටතට යන මාර්ගය ඇති උමඟ නම් කරයි. ip rule show ප්‍රතිපත්ති පාදක මාර්ගකරණය ක්‍රීඩාවේ තිබේද යන්න පෙන්වයි. sudo nft list ruleset | grep -n oifname ඉවත් කිරීම් අතුරුමුහුණත් නාමයකට, ලකුණකට හෝ මුළු පිටතට යන දාමයට බැඳී තිබේද යන්න පෙන්වයි.
Windows තුළ එම කතාවම මාර්ග මෙට්‍රිකයේ සහ පෙරහන් ලැයිස්තුවේ ජීවත් වේ: Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric සහ Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match "VPN". macOS තුළ, netstat -rn -f inet | head -5 සහ scutil --dns | head -20.
පසුව මිනිසුන් මඟ හරින පියවර ගන්න: උමඟ හිතාමතා නවත්වා, අසාර්ථක විය යුතු යැයි ඔබ බලාපොරොත්තු වන ගමනාගමනය සැබවින්ම අසාර්ථක වන බව තහවුරු කරන්න. සම්බන්ධිත අයිකනයක් යනු අතුරුමුහුණතේ තත්ත්වයක් මිස බලාත්මක කිරීමක් නොවේ.
සේවාදායකයන් දෙදෙනෙක් වැරදි නිර්මාණයක් වන්නේ කවදාද
දෙවන යෙදුම පිටුපස ඇති එකම අවශ්‍යතාව වැඩි ආරක්ෂාවක් නම්, එය ඉවත් කරන්න. අන්තර්ක්‍රියා කරන අවහිර කිරීමේ ප්‍රතිපත්ති දෙකක් එකකට වඩා අඩුවෙන් අනාවැකි කළ හැකි අතර, සෑම නැවත සම්බන්ධතාවක්ම කිසිදු සැපයුම්කරුවෙකු පරීක්ෂා නොකරන තත්ත්වයකට වැටීමේ අවස්ථාවකි.
ඔබට සැබවින්ම දාමයක් අවශ්‍ය නම්, උදාහරණයක් ලෙස වාණිජ පිම්මක් හරහා ළඟා වන ආයතනික ද්වාරයක්, එක් බලාත්මක කිරීමේ ලක්ෂ්‍යයක් ඇති නිර්මාණයක් තෝරන්න. එය සාමාන්‍යයෙන් අදහස් කරන්නේ දාමයට සහාය දෙන එක් රවුටරයක් හෝ එක් සේවාදායකයක් මිස එකම පෙරනිමි මාර්ගය සඳහා තරඟ කරන ඩෙස්ක්ටොප් යෙදුම් දෙකක් නොවේ. කළමනාකරණය කළ උපාංගයක අනුමත සේවාදායකයා තබාගෙන අනෙක් සියල්ල විෂය පථයෙන් පිටත ලෙස සලකන්න, තැටියේ කුමක් පෙන්වුවත්.
දෙකම තබා ගැනීමට පෙර පිරික්සුම් ලැයිස්තුව
ලැයිස්තුව පිළිවෙළින් සම්පූර්ණ කරන්න; පළමුව අසාර්ථක වන අයිතමය තමයි නිවැරදි කළ යුත්තේ.
- හරියටම එක් සේවාදායකයෙකුට පෙරනිමි මාර්ගය සහ විසඳනය හිමි බව තහවුරු කරන්න.
- දෙවන සේවාදායකයා ඉහළින් තැබීමට අවශ්‍ය නම් එහි සේවාදායකයේ අන්ත ලක්ෂ්‍යය පැහැදිලිව අවසර දී සෑම සේවාදායක යාවත්කාලීනයකින් පසු නැවත පරීක්ෂා කරන්න.
- කිසියම් උමඟක් වැටුණු විට අපේක්ෂිත ප්‍රතිඵලය ලියා එම අවස්ථාවම පරීක්ෂා කරන්න.
- නැවත ඇරඹීමෙන් පසු අසාර්ථකත්ව මාර්ගය පරීක්ෂා කරන්න, ආරම්භක අනුපිළිවෙළ වෙනස් විට.
- කළමනාකරණය කළ පැතිකඩක නවතින්න, යමක් එකතු කිරීමට පෙර හිමිකරුගෙන් අසන්න.
තෙවන පියවර අසාර්ථක වුවහොත්, අවංක පිළිතුර නම් ඔබට ප්‍රතිපත්තියක් දෙන්නේ එක් සේවාදායකයෙක් පමණක් බවයි. විශ්වාස කරන්නේ කාටද තීරණය කර අනෙකාට යාමට ඉඩ දෙන්න.