Windows இல் OpenVPN அடாப்டர் திரும்பத் திரும்ப விழுகிறதா? நகல் IP சரிபார்க்கவும்

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

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

வாடிக்கையாளர் பதிவிலிருந்து அல்ல, Windows நிகழ்வு பதிவிலிருந்து தொடங்குங்கள்

Windows முகவரி முரண்பாடுகளை கணினி பதிவில் நிகழ்வு ID 4198 மற்றும் 4199 உடன் பதிவு செய்கிறது. முதல் ஒன்று ஒரு முகவரிக்குக் கண்டறியப்பட்ட முரண்பாட்டைத் தெரிவிக்கிறது, இரண்டாவது ஒரு இடைமுகம் தான் உள்ளமைக்கப்பட்ட முகவரியைப் பயன்படுத்த முடியவில்லை எனத் தெரிவிக்கிறது. எதுவும் OpenVPN ஐக் குறிப்பிடவில்லை, அதனால்தான் அவற்றைக் கவனிக்காமல் விடுவது எளிது.

அண்மைக் கால நிகழ்வுகளை எடுத்து அவற்றின் நேர முத்திரைகளை அடாப்டரின் புதுப்பித்தல் சுழற்சியுடன் ஒப்பிடுங்கள்: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. ஒவ்வொரு பதினைந்து வினாடிகளுக்கும் ஏற்படும் முரண்பாடு, அந்த முகவரிக்குத் தொடர்ந்து பதிலளிக்கும் உரிமையாளருக்கு எதிராக அதே முகவரியை மீண்டும் முயற்சிக்கும் வாடிக்கையாளருடன் பொருந்துகிறது. இணைக்கும் நேரத்தில் ஏற்படும் ஒற்றை முரண்பாடு மாறாக ஒரு முறை நிகழும் மோதலைச் சுட்டுகிறது. எப்படியிருந்தாலும், அடுத்த கேள்வி யார் அந்த முகவரியை வைத்திருக்கிறார்கள் என்பதுதான்.

மூன்று ஏற்பாடுகள் இரண்டு புரவலர்களை ஒரு முகவரியில் வைக்கின்றன

சேவையகத்திடம் அது எண்ணப்படி முகவரி யாரிடம் உள்ளது என்று கேளுங்கள், பின்னர் அதற்கு யார் பதிலளிக்கிறார்கள் என்று வலையமைப்பிடம் கேளுங்கள். grep -H ifconfig-push /etc/openvpn/ccd/* ஒவ்வொரு பிணைக்கப்பட்ட சுரங்கப்பாதை முகவரியையும் அது சார்ந்த சான்றிதழையும் பட்டியலிடுகிறது. ip -4 neigh show dev tap0 பாலம் இரண்டாம் அடுக்கில் கற்றதைக் காட்டுகிறது. அந்த இரண்டு பட்டியல்களையும் ஒப்பிடுவது பெரும்பாலான நகல்களை ஒரு நிமிடத்திற்கும் குறைவாகக் கண்டுபிடிக்கிறது.

மூன்று ஏற்பாடுகள் கிட்டத்தட்ட அனைத்தையும் விளக்குகின்றன: client-config-dir உள்ளீடு இரண்டு சான்றிதழ்களுக்கு ஒரு முகவரியைப் பிணைக்கிறது, பாலமாக்கப்பட்ட tap பகுதி ஒரு இயந்திரத்திற்கு மற்றொரு புரவலன் ஏற்கனவே நிலையாக வைத்திருக்கும் முகவரியைக் கொடுக்கிறது, அல்லது காலாவதியான குத்தகைக் கோப்பு இன்னும் இணைக்கப்பட்ட வாடிக்கையாளர் தனதெனக் கருதும் முகவரியைத் திருப்பித் தருகிறது. மூன்றாவது நிலை மிகவும் தந்திரமானது, ஏனெனில் ifconfig-pool-persist அறியப்பட்ட வாடிக்கையாளர்களுக்கு முகவரிகளை வேண்டுமென்றே மீண்டும் பயன்படுத்துகிறது.

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

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

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

சரியான வரிசையில் மீண்டும் தொடங்கி ஒவ்வொரு முகவரிக்கும் ஒரு உரிமையாளரை உறுதிசெய்யுங்கள்

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

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

டிக்கெட்டை மூடுவதற்கு முன் முழு புதுப்பித்தல் சுழற்சியைக் கவனியுங்கள்

ஒரு தூய வாசிப்பு எதையும் நிரூபிக்காது. குறைந்தது பத்து நிமிடங்கள் அடாப்டரைக் கவனித்து, நடுவில் மீண்டும் இணைப்பைக் கட்டாயப்படுத்துங்கள்: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. முகவரி மீண்டும் இணைப்பைத் தாண்டி விருப்பமான நிலையில் இருக்க வேண்டும்.

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

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