නිවසේ VPN සේවාදායකයට ගතික DNS අවශ්‍යද?

ගතික DNS නම නිවැරදි කරයි, ඇතුළට යන මාර්ගය නොවේ. පරීක්ෂණ තුනක් තීරණය කරයි hostname එක ප්‍රමාණවත්ද නැතහොත් ඇතුළු වන මාර්ගය කැඩී ඇත්ද කියා.

මගෙන් අසන නිවසේ VPN අසාර්ථකතා බොහොමයක් DNS අසාර්ථකතා නොවේ, එහෙත් මිනිසුන් පළමුව ගතික DNS දායකත්වයක් මිලදී ගනී. ඕනෑම දෙයක් වින්‍යාසගත කිරීමට පෙර, hostname එක සැබවින්ම කැඩී ඇති කොටසද යන්න තීරණය කරන්න. ඔබේ ISP ලබා දුන් ලිපිනය මාරු වන විට යාවත්කාලීන කරන්නා වාර්තාවක් නැවත ලියයි; එයට පෝට් එකක් විවෘත කළ නොහැක, කැරියර් NAT හරහා යා නොහැක, නැතහොත් ක්‍රියාත්මක WireGuard සැසියකට එහි අන්ත ලක්ෂ්‍යය වෙනස් වූ බව දැනගැනීමට සැලැස්විය නොහැක. ගතික DNS සම්පූර්ණ විසඳුමද නැතහොත් එහි එක් පේළියක් පමණද යන්න කොන්දේසි තුනක් තීරණය කරයි.

පළමු කොන්දේසිය: ඔබේ ලිපිනය සැබවින්ම මාරු වේ

නිවාස ලිපින සාමාන්‍ය හේතූන් නිසා මාරු වේ: විදුලිය ගිය පසු මොඩමය නැවත සමමුහුර්ත වේ, ISP එක සංචිතයක් නැවත සමතුලිත කරයි, දිගු බාධාවකින් පසු නව බද්දක් පැමිණේ. සමහර රේඛාවල ඒවා කලාතුරකින් ද මාරු වේ, එකම ලිපිනය වසරක් පවතිනු මම දැක ඇත; ව්‍යාපාරික සැලසුම්වල බොහෝ විට ස්ථිතික ලිපිනයක් ඇත. මාස දොළහක් තුළ කිසිවක් වෙනස් නොවී නම්, අතින් සංස්කරණය කරන තනි A වාර්තාවක් යනු ජීවමානව තැබිය යුතු ඩීමන් එකක් අඩුවකි.

අනුමාන කරනවාට වඩා මනින්න. රවුටරයේ තත්ත්ව පිටුවේ WAN ලිපිනය කියවා, එය බාහිර ලෝකය දකින දෙය සමඟ සසඳන්න. මෙය LAN හි යන්ත්‍රයකින් ධාවනය කරන්න:

curl -fsS https://api.ipify.org; echo

අගයන් දෙක වෙනස් නම්, ඔබේ රවුටරය ඉදිරියේ යමක් පරිවර්තනය කරමින් සිටී, කිසිදු hostname යාවත්කාලීනයක් එය නිවැරදි නොකරයි. 100.64.0.0/10 තුළ ඇති ලිපිනය කැරියර්-ශ්‍රේණියේ NAT සඳහා බෙදාගත් පරාසයයි, නිවැරදිව යාවත්කාලීන කළ නමක් තවමත් පිටතින් කාලය ඉකුත් වීමට හේතුව සාමාන්‍යයෙන් එයයි.

දෙවන කොන්දේසිය: සේවාලාභීහු නම නැවත විසඳති

කෙටි TTL යනු මිනිසුන් මඟ හරින කොටසයි. පුනරාවර්තී විසඳන්නන් වාර්තාවේ TTL ගරු කරයි, නමුත් සේවාලාභී ගොඩගැසුම් වෙන වෙනම හැඹිලි කරයි, දැනටමත් ඉහළ යන උමගක් කිසිවක් නැවත විසඳන්නේ නැත. දෝෂ නිරාකරණය කරන අතරතුර වාර්තාව තත්පර 60-300 ට සකසන්න; එය පැරණි පිළිතුරක් දෙන කවුළුව කෙටි කරයි, සම්බන්ධිත සැසියක් සංක්‍රමණය නොකරයි.

OpenVPN නැවත සම්බන්ධ වන සෑම විටම පේළිය remote vpn.example.net 1194 නැවත විසඳයි, සහ resolv-retry infinite සෙවීම අසාර්ථක වූ විට පිටවීම වෙනුවට නැවත උත්සාහ කරමින් තබා ගනී. සේවාදායකයේ float ස්ථාපිත සැසියකට මූල ලිපිනය වෙනස් වූ සහකරුවෙකු අනුගමනය කිරීමට ඉඩ දෙයි. WireGuard වඩාත් සෘජුය: wg-quick up වින්‍යාසය යෙදෙන විට Endpoint විසඳයි, සේවාලාභියා උමග නැවත ගොඩනඟන විට එය නැවත විසඳයි, එබැවින් පැරණි ලිපිනයට තවමත් සාර්ථක වන අත් ගැටීම නතර වන තෙක් සාර්ථකව පවතී.

එම වෙනස සැලසුම හැඩගස්වයි. සේවාලාභීහු ඉල්ලුමට අනුව සම්බන්ධ වන්නේ නම්, ලිපින වෙනසකට නැවත සම්බන්ධ වීමක් වැය වේ. දින ගණනක් සැසිය විවෘතව තබා ගන්නේ නම්, ඊළඟ අත් ගැටීමේදී උමග මිය යනු ඇතැයි බලාපොරොත්තු වන්න, ඉහළින් පවතී යැයි උපකල්පනය නොකර සේවාලාභියාට නැවත උත්සාහ කිරීමට සලස්වන්න.

තෙවන කොන්දේසිය: ඇතුළු වන මාර්ගය තවමත් විවෘතය

ගතික DNS වෙනස් කරන්නේ නම යොමු වන තැන පමණි, අන් කිසිවක් නොවේ. රවුටරයේ පෝට් ඉදිරියට යැවීම, VPN සත්කාරකයේ ගිනි පවුරු රීතිය සහ ISP හි ඇතුළත පැකට් සඳහා අවසරය — සියල්ල වාර්තාවට වැදගත්කමක් ලැබීමට පෙර තිබිය යුතුය. ඉදිරියට යැවීම ඉලක්ක කරන්නේ කුමක් දැයි බලන්න: එය අතුරුමුහුණත වෙනුවට WAN ලිපිනයකට සවි කර ඇත්නම්, ලිපින වෙනසක් ඉදිරියට යැවීම නිහඬව බිඳ දමයි, දෝෂය වාර්තාවට පැමිණේ.

පිටතින් අත්හදා බලන්න. Wi-Fi කපා දැමූ ජංගම දත්තවල ඇති දුරකථනය ලාභම අවංක පරීක්ෂණයයි; එම LAN හි ඇති ලැප්ටොප් එක නොවේ. නම ඔබේ පොදු ලිපිනයට විසඳෙන විට සහ රවුටරයේ NAT ලූප්බැක් නොමැති විට, ඇතුළත පරීක්ෂණය අසාර්ථක වේ, වාර්තාව සම්පූර්ණයෙන් නිවැරදි වුවද, එයින් බොහෝ දෙනා කිසිදා වැරදි නොවූ වාර්තාවක් සංස්කරණය කිරීමට යවයි.

තුනම සත්‍ය වූ විට ධාවනය කළ යුත්තේ කුමක්ද

කුඩා සත්කාරකයක් සඳහා ddclient වඩාත් අඩුවෙන් පුදුම කරන යාවත්කාලීන කරන්නාය. අවම වින්‍යාසය සපයන්නා දකින ලිපිනය ප්‍රකාශයට පත් කරයි, එය ද්විත්ව NAT දෝෂය මඟ හරියි:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

shell ලූපයක් වෙනුවට සෑම මිනිත්තු කිහිපයකට වරක් systemd කාලසටහනකින් එය ධාවනය කරන්න, සාර්ථකත්වය උපකල්පනය නොකර සපයන්නාගේ පිළිතුර ලොග් කරන්න. අක්තපත්‍ර යතුරක් මෙන් සලකන්න, එය සෑම සේවාලාභියෙකු යවන තැන තීරණය කරන බැවිනි: ගිණුම් මුරපදය වෙනුවට සීමිත යාවත්කාලීන ටෝකනයක් භාවිත කරන්න, ගොනුව 0600 මාදිලියේ තබන්න, යාවත්කාලීන HTTPS හරහා යවන්න.

කැපවීමට පෙර සත්‍යාපනය කරන්න

එක් සෙවීමක් ඉතිරි ලෝකය දකින දෙය කියයි, වෙනසකින් පසු රැඳී සිටිය යුතු TTL මුද්‍රණය කරයි:

dig +noall +answer vpn.example.net @1.1.1.1

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

තත්පර හැටක ආපසු හැරවීමක් තබා ගන්න: අවසන් වරට ක්‍රියා කළ ලිපිනය සහ පෙර TTL සටහන් කරන්න, සපයන්නාට නරක සවසක් ඇති විට දෙකම අතින් ප්‍රකාශයට පත් කළ හැකි වන පරිදි.

පිළිතුර නැත වන විට

කොන්දේසි එක හෝ තුන අසාර්ථක වුවහොත්, වින්‍යාසය නොව තීරණය වෙනස් වේ. කැරියර් NAT පිටුපස ඔබේ ප්‍රායෝගික විකල්ප වන්නේ ISP වෙතින් පොදු ලිපිනයක් ඉල්ලීම, ප්‍රවේශ ලක්ෂ්‍යය ස්ථාවර ලිපිනයක් සහිත කුඩා VPS එකකට ගෙන යාම, හෝ තමන්ගේම හමුවීමක් රඳවා ගන්නා ආවරණයක් භාවිත කිරීමයි. ලිපිනය ස්ථිතික නම්, යාවත්කාලීන කරන්නා මඟ හරින්න: එක් A වාර්තාවක්, IPv6 ධාවනය කරන්නේ නම් එක් AAAA වාර්තාවක්, එම පෝට් ඉදිරියට යැවීමම.

සේවාලාභීහු සම්බන්ධව සිටියදී ලිපිනය වෙනස් වන්නේ නම්, අවංක නිවැරදි කිරීම සේවාලාභියා තුළම පවතී: නැවත සම්බන්ධ වීමේ තර්කනය සහ නැවත උත්සාහ කිරීමේ පරතරය, වඩා වේගවත් යාවත්කාලීන කරන්නෙකු නොවේ. දෙවන සපයන්නෙකු එකතු කිරීම පරතරය සඟවයි.

ඉදිරියට යාමට පෙර කරුණු හතරක් පිළිවෙලට තහවුරු කරන්න:

  • යාවත්කාලීන කරන්නා ප්‍රකාශයට පත් කරන ලිපිනය රවුටරයේ WAN ලිපිනය සමඟ ගැළපේ.
  • වාර්තාවේ TTL වෙනසක් මිනිත්තු කිහිපයකින් දිස්වන තරම් කෙටිය.
  • පෝට් ඉදිරියට යැවීම ස්ථිතික ලිපිනයකට නොව අතුරුමුහුණතට සම්බන්ධය.
  • අවසන් වෙනසින් පසු සැබෑ සේවාලාභියෙකු නැවත සම්බන්ධ වී ගමනාගමනය ගොස් ඇත.

හතරම සත්‍ය නම්, වින්‍යාසය එසේම තබන්න; ඔබේ ඊළඟ අසාර්ථකත්වය නාමකරණ ගැටලුවක් නොව යතුරක් හෝ ගිනි පවුරු රීතියකි. යමක් අසාර්ථක නම්, තවත් චලනය වන කොටසක් එකතු කිරීමට පෙර එම පේළිය නිවැරදි කරන්න. RFC 2136 යාවත්කාලීන ක්‍රියාවිධියම විස්තර කරයි, ඩීමන් රැහැනට දමන දෙය දැකීමට අවශ්‍ය නම්.

අදාළ ලිපි