VPN இடம் மாறியது: உங்கள் OpenVPN கிளையண்ட் இன்னும் பழைய IP-ஐ ஏன் அழைக்கிறது

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

DNS சொல்வதை அல்ல, சுயவிவரம் எதை அழைக்கிறது என்பதைப் பாருங்கள்

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

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

இரண்டு கோப்புகள், ஒரு இறுதிப்புள்ளி — இங்கே வழக்கமாகக் காணப்படுவது இதுதான்.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

கிளையண்டின் அடுத்த இணைப்பு முயற்சியைப் படியுங்கள்

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

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

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

நீங்கள் எந்த மறுதொடக்கம் செய்கிறீர்கள் என அறியுங்கள்

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

நிலைத்தன்மை அமைப்புகளும் முக்கியம், ஏனெனில் அவை அங்கீகரிக்கப்பட்டதைத் தக்கவைக்க உருவாக்கப்பட்டவை, புதிய முகவரிகளைத் துரத்த அல்ல.

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

நான்கு விருப்பங்களும் அவற்றின் தனித்தனி வேலைகளும்

புரவலன் பெயருடன் கூடிய remote தான் மறுதீர்வை சாத்தியமாக்கும் அமைப்பு; அந்த வரியில் நேரடி முகவரி இருந்தால் அது இயலாது. resolv-retry தேடல் தோல்வியடையும்போது என்ன நடக்கிறது என்பதைக் கட்டுப்படுத்துகிறது, 2.6 ஏற்கனவே அதை இயல்பாக முடிவிலியாக வைக்கிறது. எனவே அதைச் சேர்ப்பதால் எதுவும் மாறாது, வேறு பதிலுக்காக ஒருபோதும் அவ்வப்போது சரிபார்ப்பைத் திட்டமிடாது. அது புதிய முகவரிகளைக் கண்காணிக்கிறது என்பவர் மீட்பையும் புத்துணர்ச்சியையும் குழப்பியுள்ளார்.

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

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

கிளையண்டைக் குறை கூறுவதற்கு முன் புதிய இறுதிப்புள்ளியை உறுதிசெய்யுங்கள்

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

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

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