OpenVPN வழியாக காலி LAN விளையாட்டு பட்டியலா? கண்டறிதல் பாதையை சரிபார்க்கவும்

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

அமர்வில் சேர்வதை அதைக் கண்டுபிடிப்பதிலிருந்து பிரிக்கவும்

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

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

சுரங்கப்பாதையைத் தொடுவதற்கு முன் நேரடிச் சேர்வைச் சோதிக்கவும்

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

கண்டறிதல் துறைமுகமும் அமர்வு துறைமுகமும் ஒரே எண் என்று கருத வேண்டாம். விளையாட்டுகள் பொதுவாக ஒரு UDP துறைமுகத்தில் அறிவித்து மற்றொன்றில் வீரர்களை ஏற்கின்றன, தவறான துறைமுகத்திற்காகக் கட்டப்பட்ட ரிலே காலியாகவே இருக்கும் பட்டியலைத் தருகிறது.

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

ஒளிபரப்பு எங்கு நிற்கிறது என்பதைப் புரிந்து கொள்ளுங்கள்

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

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

மல்டிகாஸ்ட் கண்டறிதலுக்கு வேறு முகவரி வகுப்புடன் அதே சிக்கல் உள்ளது, அதற்கு ஒளிபரப்பு விலக்கு அல்ல, மல்டிகாஸ்ட் வழித்தடம் அல்லது ரிலே தேவை.

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

தானியங்கி கண்டறிதல் தேவையானால், முதலில் உண்மையான பரிமாற்றத்தை அடையாளம் காணுங்கள்: ஒளிபரப்பா அல்லது மல்டிகாஸ்டா, இலக்கு முகவரி, UDP துறைமுகம், அதை அனுப்பும் இடைமுகம், பதிலுக்குள் உள்ள முகவரி. இந்த ஐந்து உண்மைகளுக்கு மட்டுப்படுத்தப்பட்ட நெறிமுறைக்கு ஏற்ற ரிலே முழு Ethernet பிரிவை விரிவாக்குவதை விட மிகக் குறுகலானது.

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

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

வடிவமைப்பிற்கு Ethernet தேவைப்படும்போது மட்டுமே பாலம் அமைக்கவும்

Ethernet சட்டகங்கள் TAP-க்குள் பயணிக்கின்றன, எனவே TAP சுரங்கப்பாதை வேண்டுமென்றே பாலமிடப்பட்ட ஒளிபரப்பு களத்தைச் சேர்ந்ததாக இருக்கலாம். வெறுமனே dev tun ஐ dev tap ஆக மாற்றுவது அந்தப் பாலத்தைக் கட்டாது, சேவையக உள்ளமைவை இணக்கமாக்காது, பயன்பாட்டைப் புதிய இடைமுகத்தைத் தேர்ந்தெடுக்கவும் வைக்காது. OpenVPN பாலமிடல் வழிகாட்டி ஒரு காலி லாபிக்கான தீர்வு அல்ல, பரந்த ஏற்பாட்டை விவரிக்கிறது.

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

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