ddclient VPN வெளியேற்றத்தை வெளியிடுகிறது: கண்டறிதல் மூலத்தைச் சரிசெய்யவும்

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

பெயர் எதை அடைய வேண்டும் என்பதை உறுதிப்படுத்துங்கள்

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

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

இடைமுக முகவரிகளுக்கும் விளக்கம் தேவை. வீட்டு ரவுட்டருக்குப் பின்னால் உள்ள மடிக்கணினி முகவரி பொது WAN முகவரி அல்ல, ரவுட்டரின் WAN முகவரியும் கேரியர்-தர NAT பின்னால் இருக்கலாம், அங்கே அதை வெளியிடுவது உள்நுழைவு அணுகலை உருவாக்க முடியாது.

எதையும் மாற்றுவதற்கு முன் மதிப்பை மீண்டும் உருவாக்குங்கள்

இரண்டு பாதைகளையும் தனித்தனியாகக் கவனியுங்கள். சுரங்கம் மேலே இருக்கும்போது ஆய்வு வெளியேற்றத்தைப் புகாரளிக்கிறது; சுரங்கம் கீழே இருக்கும்போது, அல்லது ஆய்வு இயற்பியல் இடைமுகத்தில் பிணைக்கப்பட்டிருக்கும்போது, அது வீட்டு முகவரியைப் புகாரளிக்கிறது: curl --interface eth0 https://ifconfig.me. அந்த இரண்டு பதில்களும் வேறுபட்டால், புதுப்பிப்பானைத் தொடாமலேயே குறையை மீண்டும் உருவாக்கியுள்ளீர்கள்.

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

கண்டறிதலைத் தேர்ந்தெடுத்த பாதைக்குத் திருப்புங்கள்

பெயர் வீட்டு WAN முகவரியை வெளியிட வேண்டும் என்றால், கண்டறிதல் அதே முகவரியைக் கவனிக்க வேண்டும். தோராயமான முன்னுரிமை வரிசையில் மூன்று வழிகள் வேலை செய்கின்றன: ரவுட்டர் தனது ஆதரவு பெற்ற புதுப்பிப்பான் வழியாக வெளியிடட்டும்; ரவுட்டர் உண்மையில் வழங்கும் பக்கத்திற்கு எதிராக ddclient இன் ரவுட்டர்-நிலை கண்டறிதலைப் பயன்படுத்துங்கள்; அல்லது வலை ஆய்வை வைத்துக்கொண்டு, சுரங்கத்திற்கு வெளியே செல்லுமாறு அதை இயற்பியல் இடைமுகத்தில் பிணையுங்கள்.

ரவுட்டர்-நிலை பாதைக்கு, புதிய ddclient வெளியீடுகள் usev4 மற்றும் fwv4 விருப்பக் குடும்பத்தைப் பயன்படுத்துகின்றன, பக்கத்தைச் சுற்றியுள்ள உரைக்கான விருப்பத் தவிர்ப்பு முறையமைப்புடன். உங்கள் நிறுவப்பட்ட பதிப்பிற்கான README ஐப் பாருங்கள், ஏனெனில் பழைய வெளியீடுகள் அதே கருத்தை use மற்றும் fw உடன் எழுதுகின்றன, தவறான வெளியீட்டிலிருந்து நகலெடுக்கப்பட்ட விருப்பப் பெயர் தொடங்கும்போது தோல்வியடைகிறது.

நீங்கள் வலைக் கண்டறிதலை வைத்திருந்தால், ஆய்வின் வழியமைப்பும் புதுப்பிப்பு API அழைப்பின் வழியமைப்பும் தனித்தனி முடிவுகள் என்பதை நினைவில் கொள்ளுங்கள். புதுப்பிப்பு அழைப்பு பதிவை வழங்குகிறது; ஆய்வு வழங்கப்படும் மதிப்பைத் தீர்மானிக்கிறது.

ரகசியங்களையும் பதிப்புகளையும் ஒழுங்காக வைத்திருங்கள்

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

ddclient README கண்டறிதல் அணுகுமுறைகளையும் அவற்றின் விருப்பப் பெயர்களையும் ஆவணப்படுத்துகிறது. ஒரே பதிவில் IPv4 மற்றும் IPv6 முடிவுகளைக் கலக்க வேண்டாம், ஒரு வெளியீட்டில் உள்ள விருப்பம் மற்றொன்றில் உள்ளது என்று கருத வேண்டாம்.

மதிப்பைச் சரிபார்த்து, பின்னர் அணுகலை

நேரடி புதுப்பிப்பை அனுமதிக்கும் முன் முன்மொழியப்பட்ட முகவரியை நோக்கமிடப்பட்ட இறுதிப் புள்ளியுடன் ஒப்பிடுங்கள், பின்னர் ஒரு அங்கீகரிக்கப்பட்ட புதுப்பிப்புக்குப் பின் அதிகாரமிக்க DNS ஐச் சரிபார்த்து தீர்விகளின் தற்காலிகச் சேமிப்புகளைக் கணக்கில் கொள்ளுங்கள். குறைந்த TTL காத்திருப்பைக் குறைக்கிறது; தவறான மதிப்பைச் சரியாக்காது.

பதிவு சரியான பிறகுதான், தேவையான ஃபயர்வால் மற்றும் அனுப்புதல் ஏற்கனவே அனுமதிக்கப்பட்ட நிலையில், சுயாதீன வலையமைப்பிலிருந்து உள்நுழைவுச் சேவையைச் சோதிக்க வேண்டும். சரியான A பதிவு அணுகக்கூடிய சேவையை நிரூபிக்காது, நிலையான VPN குத்தகை தனிப்பட்ட பெயரிடலை எளிமைப்படுத்தலாம், ஆனால் தவறான WAN ஐ சுட்டும் பொது ஹோஸ்ட் பெயரைச் சரிசெய்யாது.