வீட்டு VPN சேவையகத்திற்கு டைனமிக் DNS தேவையா?

என்னிடம் கேட்கப்படும் வீட்டு VPN தோல்விகளில் பெரும்பாலானவை DNS தோல்விகள் அல்ல, இருப்பினும் மக்கள் முதலில் டைனமிக் DNS சந்தாவை வாங்குகிறார்கள். எதையும் கட்டமைக்கும் முன், hostname உண்மையில் உடைந்த பகுதியா என்பதைத் தீர்மானியுங்கள். உங்கள் ISP வழங்கிய முகவரி நகரும் போது புதுப்பிப்பான் பதிவை மீண்டும் எழுதுகிறது; அது ஒரு port ஐத் திறக்கவோ, carrier NAT ஐக் கடக்கவோ, அல்லது இயங்கும் WireGuard அமர்வு தன் முனைப்புள்ளி மாறியதைக் கவனிக்கவோ முடியாது. டைனமிக் DNS முழுத் தீர்வா அல்லது அதன் ஒரு வரி மட்டுமா என்பதை மூன்று நிபந்தனைகள் தீர்மானிக்கின்றன.

நிபந்தனை ஒன்று: உங்கள் முகவரி உண்மையில் நகர்கிறது

குடியிருப்பு முகவரிகள் சாதாரண காரணங்களுக்காக நகர்கின்றன: மின்தடைக்குப் பிறகு மோடம் மீண்டும் ஒத்திசைக்கிறது, ISP தொகுப்பை மறுசீரமைக்கிறது, நீண்ட இடைவெளிக்குப் பிறகு புதிய குத்தகை வருகிறது. சில இணைப்புகளில் அவை அரிதாகவே நகர்கின்றன, அதே முகவரி ஒரு வருடம் நீடிப்பதை நான் பார்த்துள்ளேன்; வணிகத் திட்டங்களில் பெரும்பாலும் நிலையான ஒன்று உள்ளது. பன்னிரண்டு மாதங்களில் எதுவும் மாறவில்லை என்றால், கையால் திருத்தப்படும் ஒரு A பதிவு என்பது உயிருடன் வைத்திருக்க வேண்டிய ஒரு டீமன் குறைவு.

யூகிக்காமல் அளவிடுங்கள். ரவுட்டரின் நிலைப் பக்கத்தில் WAN முகவரியைப் படித்து, வெளி உலகம் காண்பதுடன் ஒப்பிடுங்கள். இதை LAN இல் உள்ள இயந்திரத்திலிருந்து இயக்குங்கள்:

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

இரு மதிப்புகளும் வேறுபட்டால், உங்கள் ரவுட்டருக்கு முன் ஏதோ மொழிபெயர்க்கிறது, எந்த hostname புதுப்பிப்பும் அதைச் சரிசெய்யாது. 100.64.0.0/10 க்குள் உள்ள முகவரி carrier-தர NAT க்கான பகிரப்பட்ட வரம்பு, சரியாகப் புதுப்பிக்கப்பட்ட பெயரும் வெளியிலிருந்து நேரம் முடிவதற்கான பொதுவான காரணம் அதுவே.

நிபந்தனை இரண்டு: வாடிக்கையாளர்கள் பெயரை மீண்டும் தேடுகிறார்கள்

குறுகிய TTL தான் மக்கள் தவிர்க்கும் பகுதி. மீள்சுழல் தீர்விகர்கள் பதிவின் TTL ஐ மதிக்கின்றன, ஆனால் வாடிக்கையாளர் அடுக்குகள் தனித்தனியாக தேக்கி வைக்கின்றன, ஏற்கனவே எழுந்த சுரங்கப்பாதை எதையும் மீண்டும் தீர்க்காது. பிழைத்திருத்தத்தின் போது பதிவை 60-300 வினாடிகளில் வையுங்கள்; பழைய பதில் வழங்கப்படும் சாளரத்தை அது சுருக்குகிறது, இணைக்கப்பட்ட அமர்வை இடமாற்றாது.

OpenVPN மீண்டும் இணையும் ஒவ்வொரு முறையும் வரியை remote vpn.example.net 1194 மீண்டும் தீர்க்கிறது, மேலும் resolv-retry infinite தேடல் தோல்வியடையும் போது வெளியேறாமல் தொடர்ந்து முயலச் செய்கிறது. சேவையகத்தில் float நிறுவப்பட்ட அமர்வு மூல முகவரி மாறிய இணையைப் பின்தொடர அனுமதிக்கிறது. WireGuard இன்னும் நேரடியானது: wg-quick up கட்டமைப்பு பயன்படுத்தப்படும் போது Endpoint தீர்க்கிறது, சுரங்கப்பாதையை மீண்டும் கட்டும் போது வாடிக்கையாளர் அதை மீண்டும் தீர்க்கிறது, எனவே பழைய முகவரிக்கு எதிராக இன்னும் வெற்றிபெறும் கைக்குலுக்கல் நிற்கும் வரை வெற்றிபெறுகிறது.

இந்த வேறுபாடு திட்டத்தை வடிவமைக்கிறது. வாடிக்கையாளர்கள் கோரிக்கையின் பேரில் இணைந்தால், முகவரி மாற்றத்திற்கு ஒரு மறுஇணைப்பு செலவாகும். பல நாட்கள் அமர்வைத் திறந்து வைத்தால், அடுத்த கைக்குலுக்கலில் சுரங்கப்பாதை இறந்துவிடும் என எதிர்பாருங்கள், அது நீடிக்கும் எனக் கருதாமல் வாடிக்கையாளரை மீண்டும் முயலச் செய்யுங்கள்.

நிபந்தனை மூன்று: உள்ளே வரும் வழி இன்னும் திறந்துள்ளது

டைனமிக் DNS பெயர் எங்கு சுட்டுகிறது என்பதை மட்டுமே மாற்றுகிறது, வேறு எதையும் அல்ல. ரவுட்டரில் port forwarding, VPN புரவலனில் firewall விதி, ISP யின் உள்வரும் பொதிகளுக்கான அனுமதி — அனைத்தும் பதிவு முக்கியமாகும் முன் இருக்க வேண்டும். forwarding எதை இலக்காகக் கொள்கிறது எனப் பாருங்கள்: அது இடைமுகத்திற்குப் பதிலாக WAN முகவரியில் பூட்டப்பட்டிருந்தால், முகவரி மாற்றம் forwarding ஐ அமைதியாக உடைக்கிறது, குற்றம் பதிவின் மீது விழுகிறது.

வெளியிலிருந்து சோதியுங்கள். Wi-Fi அணைக்கப்பட்ட செல்லுலார் தரவில் உள்ள தொலைபேசி மிக மலிவான நேர்மையான சோதனை; அதே LAN இல் உள்ள மடிக்கணினி அல்ல. பெயர் உங்கள் பொது முகவரிக்குத் தீர்க்கப்படும்போது ரவுட்டரில் NAT loopback இல்லாவிட்டால், உள்ளேயிருந்து சோதனை தோல்வியடைகிறது, பதிவு முழுமையாகச் சரியாகவே உள்ளது, இதுவே பெரும்பாலோரை ஒருபோதும் தவறாக இல்லாத பதிவைத் திருத்த அனுப்புகிறது.

மூன்றும் பொருந்தும்போது எதை இயக்க வேண்டும்

சிறிய புரவலனுக்கு 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 ஐயும் குறித்து வையுங்கள், வழங்குநருக்கு மோசமான பிற்பகல் இருக்கும் போது இரண்டையும் கையால் வெளியிடலாம்.

பதில் இல்லை என்றால்

நிபந்தனை ஒன்று அல்லது மூன்று தோல்வியடைந்தால், கட்டமைப்பு அல்ல, முடிவு மாறுகிறது. carrier NAT க்குப் பின்னால் உங்கள் நடைமுறை விருப்பங்கள் ISP யிடம் பொது முகவரி கேட்பது, நுழைவுப் புள்ளியை நிலையான முகவரியுள்ள சிறிய VPS க்கு நகர்த்துவது, அல்லது தன் சந்திப்பை வைத்திருக்கும் மேலடுக்கைப் பயன்படுத்துவது. முகவரி நிலையானது என்றால், புதுப்பிப்பானைத் தவிர்க்கவும்: ஒரு A பதிவு, IPv6 இயக்கினால் ஒரு AAAA பதிவு, அதே port forwarding.

வாடிக்கையாளர்கள் இணைந்திருக்கும் போது முகவரி மாறினால், நேர்மையான திருத்தம் வாடிக்கையாளரிடமே உள்ளது: மறுஇணைப்பு தருக்கம் மற்றும் மறுமுயற்சி இடைவெளி, வேகமான புதுப்பிப்பான் அல்ல. இரண்டாவது வழங்குநரைச் சேர்ப்பது இடைவெளியை மறைக்கிறது மட்டுமே.

தொடர்வதற்கு முன் நான்கு விஷயங்களை வரிசையாக உறுதிப்படுத்துங்கள்:

• புதுப்பிப்பான் வெளியிடும் முகவரி ரவுட்டரின் WAN முகவரியுடன் பொருந்துகிறது.
• பதிவின் TTL மாற்றம் சில நிமிடங்களில் தெரியும் அளவுக்குச் சிறியது.
• port forwarding நிலையான முகவரிக்கு அல்ல, இடைமுகத்திற்குப் பிணைக்கப்பட்டுள்ளது.
• கடைசி மாற்றத்திற்குப் பிறகு ஒரு உண்மையான வாடிக்கையாளர் மீண்டும் இணைந்து போக்குவரத்தைக் கடத்தியுள்ளார்.

நான்கும் பொருந்தினால், அமைப்பை அப்படியே விடுங்கள்; உங்கள் அடுத்த தோல்வி பெயரிடல் சிக்கல் அல்ல, ஒரு சாவி அல்லது firewall விதி. ஏதேனும் தோல்வியடைந்தால், மற்றொரு நகரும் பகுதியைச் சேர்ப்பதற்கு முன் அந்த வரியைச் சரிசெய்யுங்கள். RFC 2136 புதுப்பிப்பு பொறிமுறையையே விவரிக்கிறது, டீமன் கம்பியில் என்ன வைக்கிறது எனப் பார்க்க விரும்பினால்.