VPN kill switch එකෙන් port 53 අවහිර වූ විට DNS විසඳෙන්නේ නැත
Kill switch එකට DNS හිතාමතා අවහිර කළ හැක. ටනලය තුළ පමණක් විසඳීම සහ ස්ථානීය resolver එකක් සඳහා ව්‍යතිරේකය සසඳා, ඇත්තටම ගැටළු ඇති වූ ස්ථරය කුමක්දැයි තීරණය කරන්න.
Kill switch එක ටනලය බිඳ දමන විට, එය DNS මාර්ගයද රැගෙන යයි, සහ ඉතිරි වන resolver එක ඔබ බලාපොරොත්තු වන එක නොවේ. නිර්මාණ දෙකක් එම මොහොත ඉතා වෙනස් ලෙස හසුරුවයි: ටනලය තුළ නොමැති සෑම DNS පැකට්ටුවක්ම අවහිර කිරීම, හෝව්‍යතිරේකයක් ලෙස resolver එකක් රඳවා තැබීම. දෙකම ආරක්ෂා කළ හැක. බ්‍රව්සරයේ ටැබයක සිට රෝග ලක්ෂණ බොහෝ දුරට සමාන ලෙස පෙනේ, එබැවින් පළමු කාර්යය වන්නේ ඔබ ඇත්තටම කුමන නිර්මාණය යෙදුවාද යන්න සොයා ගැනීමයි.
මම එම වෙනස මගේ ඇස හමුවේ තබා ගනිමි, මන්ද නිවැරදි කිරීම එක් එක් අවස්ථාවේ විරුද්ධ ය. එක් නිර්මාණයකට පුළුල් ව්‍යතිරේකයක් අවශ්‍ය වේ, අනෙකට පටු එකක්. අනුමාන කිරීම ඔබට පෞද්ගලිකත්වය හෝ අඩක් දිනක් වැය කරයි.
එකම බිඳවැටීම සඳහා DNS නිර්මාණ දෙකක්
A නිර්මාණය resolver එක ටනලය පිටුපස ඇති තවත් සේවාවක් ලෙස සලකයි. firewall නීති UDP සහ TCP 53 සඳහා අවසර දෙන්නේ ටනල අතුරුමුහුණතේ පමණි, සහ සේවාදායකයාට දෙන ලිපිනය ටනලය තුළ ඇති resolver එකකි. ටනලය වැටෙන විට සෙවීම් නතර වේ, එය දෝෂයක් නොව අපේක්ෂිත ප්‍රතිඵලයයි.
B නිර්මාණය ස්ථානීය ජාලයේ resolver එකක් ළඟා විය හැකි ලෙස තබා ගනී, සාමාන්‍යයෙන් 192.168.1.1 හි රවුටරය හෝ 127.0.0.53 හි මෙහෙයුම් පද්ධති stub එක, නාම විසඳීම ටනලය සමඟ මිය නොයා යුතු යන තර්කය මත. ගෘහස්ථ LAN එකක මෙය පහසු වේ, එහිදී රවුටරය මුළු නිවසටම විසඳයි. හෝටලයක හෝ ගුවන්තොටුපළක Wi-Fi එකක එම ව්‍යතිරේකයම තවත් කෙනෙකුගේ සේවාදායකයට යොමු කරයි, සහ ඔබ ටයිප් කරන සෑම නමක්ම හෙළිදරව් වේ, ඔබේ වෙබ් ගමනාගමනය අවහිරව පවතින විට පවා.
සීමාව resolver එක කාගේද යන්නයි. ස්ථානීය එක විශ්වාස කරන්නේ නම්, ව්‍යතිරේකය කුඩා හා අවංක සිදුරකි. විශ්වාස නොකරන්නේ නම්, ටනලය-පමණක් නිර්මාණය පමණක් රැඳේ, සහ මිල වන්නේ වැටුණු ටනලයක් සියලු නම් රැගෙන යාමයි.
VPN සේවාදායකයාගේම සෙවීම තවමත් ක්‍රියා කරන්නේ ඇයි
ටනලයක් පැවතීමට පෙර සේවාදායකයාට ද්වාරයේ host නාමය විසඳා ගත යුතුය, එබැවින් දැඩි අවහිර කිරීමක් සේවාදායකයාගේ ආරම්භක මාර්ගය ආවරණය නොකළ යුතුය. බොහෝ සේවාදායකයන් අන්ත ලක්ෂ්‍ය ලිපිනය cache කරයි නැතහොත් එම එකම host සඳහා ලේඛනගත ආරම්භක ව්‍යතිරේකයක් ලබා දෙයි. ඔබේ නීති කට්ටලය එම සෙවීම අවහිර කරන්නේ නම්, ටනලය කිසිදා ආපසු නොඑන අතර ලොග වලින් පෙන්වන්නේ තමන්ගේම සේවාදායකයට ළඟා විය නොහැකි සේවාදායකයෙකි; එය DNS හි නොව ප්‍රතිපත්තියේ දෝෂයකි.
බෙදුණු DNS යනු මෙය දිස්වන අනෙක් තැනයි. සේවාදායකයා අභ්‍යන්තර කලාපයක් පුද්ගලික resolver එකකට තල්ලු කර අනෙක් සියල්ල පද්ධති resolver එකට භාර කරයි. වැටීමෙන් පසු පොදු නම් තවමත් විසඳිය හැකි අතර අභ්‍යන්තර නම් කාලය ඉකුත් වී අසාර්ථක වේ, මන්ද පුද්ගලික කලාපයට තවත් මාර්ගයක් නැත. පරිශීලකයාට එය "VPN එක අන්තර්ජාලය කැඩුවා"; resolver ලොගයට එය කිසිදා නොපැමිණි විමසුමකි.
systemd-resolved යටතේ ඔබට බෙදීම සෘජුවම දැකිය හැක. resolvectl status එක් එක් සබැඳියේ DNS සේවාදායක සහ භාවිත මාර්ග වසම් ලැයිස්තුගත කරයි, සහ ටනලය පහළ ගිය පසු අභ්‍යන්තර වසම තවදුරටත් නොපවතින සබැඳියක සේවාදායකයට යොමු වේ. 127.0.0.53 හි stub එක තවමත් විමසුම පිළිගනී, පසුව පිළිතුරු නොදෙන ඉහළ ධාරාවක් එනතුරු රැඳී සිටී, එබැවින් අසාර්ථකත්වය වහාම ආපසු නොවී තත්පර කිහිපයක් ගනී.
ගුප්තකේතන DNS පැකට් පෙරහන මඟ හරින්නේ නැත
DNS over HTTPS සහ DNS over TLS 443 සහ 853 හරහා ගමන් කරයි, එබැවින් port 53 අවහිර කරන නීතිය ඒවා ගැන කිසිවක් පවසා නැත. port අනුව "DNS" අවහිර කිරීම port එකක් ගැන ප්‍රතිපත්තියකි, නාම විසඳීම ගැන නොවේ. ඔබේ kill switch ටනලයෙන් පිටත සියලු ගමනාගමනය අවහිර කරන්නේ නම්, DoH අහම්බෙන් ආවරණය වේ. captive portal එකක් හෝ පොදු resolver එකක් සඳහා අවසරයක් වෙන් කර ඇත්නම්, ආවරණය නොවේ.
සේවාදායක පැත්තේ පාලන වඩා ලාභදායක උත්තෝලනයයි. canary නාමය use-application-dns.net විසඳා නොගන්නා විට Firefox තම DoH resolver එක අත්හරියි, එබැවින් කළමනාකරණය කරන ලද ජාල එම වසම NXDOMAIN ලෙස ප්‍රකාශයට පත් කරයි; ව්‍යවසාය ප්‍රතිපත්තියට එය off ලෙස සවි කළ හැක. Android Private DNS සහ Chrome හි ආරක්ෂිත DNS ට තමන්ගේම ස්විච සහ තමන්ගේම පෙරනිමි අගයන් ඇත. ඒවා off කිරීම resolver ලිපින පසුපස හඹා යාමට වඩා විශ්වාසදායකය, මන්ද ලිපින ලැයිස්තුව වෙනස් වන අතර ඔබේ නීති කට්ටලය වෙනස් නොවේ.
මෙයට කිසිසේත් කාන්දුවක් සම්බන්ධ නොවන පිටපතක්ද ඇත. සවි කළ resolver එකක් සහිත යෙදුමකට එතනට ළඟා වීමට ජාල මාර්ගයක් තවමත් අවශ්‍යය. ගුප්තකේතනය වෙනස් කරන්නේ විමසුම කියවිය හැක්කේ කාටද යන්නයි, පැකට්ටුව යන්ත්‍රයෙන් පිටවිය හැකිද යන්න නොවේ, එබැවින් මුළු උපාංගයම අවහිර කිරීම සැකසුමට ස්පර්ශ නොකර එය පරාජය කරයි.
රෝග ලක්ෂණය ස්ථරයට ගැලපීම
බොහෝ වාර්තා එක් වාක්‍යයක් ලෙස පැමිණේ, සහ එම වාක්‍යය සාමාන්‍යයෙන් දැනටමත් ස්ථරය නම් කරයි. පහත වගුව මගේ නීතියක් ස්පර්ශ කිරීමට පෙර මා පසුකරන දේය; ඉලක්කය වන්නේ විමසුම අවහිර වුණාද, වැරදි දිශාවට ගියාද, නැතහොත් කිසිදා යැව්වේ නැද්ද යන්න තීරණය කිරීමයි.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
පළමු පේළි දෙක නම් මිනිසුන් වැරදි ලෙස රෝග විනිශ්චය කරන ඒවාය. නිශ්ශබ්ද වැටීම සහ ප්‍රතික්ෂේපය දෙකම බ්‍රව්සරයේ "DNS කැඩී ඇත" ලෙස පෙනේ, නමුත් ඔබේ kill switch තම කාර්යය කරන බව අදහස් වන්නේ ඉන් එකක් පමණි. ප්‍රතික්ෂේපය යනු යමක් පිළිතුරු දුන් බවයි, එබැවින් අවහිර කිරීම ඔබ සිතන තැන නොවේ.
resolver ප්‍රතිපත්තිය නැවත පිහිටුවා පසුව ඔප්පු කරන්න
නිර්මාණය නිවැරදි කරන්න, රෝග ලක්ෂණය නොවේ. ටනලය-පමණක් විසඳීම සඳහා ටනල අතුරුමුහුණතේ 53 ට අවසර දෙන්න, ටනල වින්‍යාසය සමඟ අභ්‍යන්තර resolver තල්ලු කරන්න, සහ භෞතික සබැඳිය DNS අවසරයකින් තොරව තබන්න. wg-quick තුළ resolver එක අතුරුමුහුණත් වින්‍යාසයට ලියන පේළිය DNS = වේ, එබැවින් එය අත්හැරෙන ටනලයක් පැරණි resolver එක එතැනම තබා සෑම විමසුමක්ම වැරදි මාර්ගයට යවයි. wg-quick අත්පොත එම හැසිරීම එක් එක් වේදිකාවට ලේඛනගත කරයි.
පසුව මෙම අනුපිළිවෙලින් තහවුරු කරන්න. Linux හිresolvectl status සක්‍රීය සබැඳිය පෙන්වයි, dig +short example.com පොදු නාමයක් පරීක්ෂා කරයි, dig @10.8.0.1 internal.example.com පුද්ගලික එක පරීක්ෂා කරයි, සහ sudo tcpdump -ni any port 53 දෙකම ධාවනය කරන අතරතුර පැකට්ටු භාවිත කරන අතුරුමුහුණත පෙන්වයි. Windows හිGet-DnsClientServerAddress -AddressFamily IPv4 සහ Resolve-DnsName example.com එකම කරුණු දෙක ලබා දෙයි: කවුරුන් වින්‍යාසගතද, සහ කවුරුන් පිළිතුරු දෙන්නේද.
සෘණ පරීක්ෂණයෙන් අවසන් කරන්න. ටනලය විසන්ධි කරන්න, නව පොදු නාමයක් අසාර්ථක වන බව තහවුරු කරන්න, පුද්ගලික නාමය අසාර්ථක වන බව තහවුරු කරන්න, සහ port 53 හි කිසිදු පැකට්ටුවක් භෞතික අනුකරණයෙන් පිටවී නැති බව තහවුරු කරන්න. cache කළ පිළිතුරු සඳහා පමණක් රැඳෙන අවහිර කිරීමක් කිසිසේත් රැඳෙන්නේ නැත.
ටිකට් වසා දැමීමට පෙර පිරික්සුම් ලැයිස්තුව:
- බිඳවැටීම අතරතුර භාවිත කළ resolver එක ප්‍රතිපත්තිය අදහස් කරන එකයි.
- සේවාදායකයාගේම අන්ත ලක්ෂ්‍ය සෙවීම cache හෝ ව්‍යතිරේකය තුළින් තවමත් අවසර ඇත.
- DoH සහ DoT අවහිර කිරීමෙන් ආවරණය වේ නැතහොත් ප්‍රතිපත්තියෙන් අක්‍රීයයි.
- ටනලය ගිය පසු පුද්ගලික කලාප විවෘතව නොව සංවෘතව අසාර්ථක වේ.