ஒரு OpenVPN கிளையன்டில் இரண்டு சேவை முகவரிகள்: iroute மற்றும் lo

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

மாற்றுப்பெயர் உள்ளூர், உரிமை தொலைவில்

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

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

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

கிளையன்டில் முகவரியை நிரந்தரமாகச் சேர்க்கவும்

சேவை முகவரியை ஹோஸ்ட் முன்னொட்டுடன் loopback இல் வைக்கவும், ஹோஸ்ட் அதை அடைய வேண்டிய துணை வலையமைப்பாக அல்ல, உள்ளூர் உள்ளீடாகக் கருதும். ip address add 10.66.0.10/32 dev lo அதை ஒரு முகவரிக்குச் செய்கிறது, இரண்டாவது முகவரிக்குக் கட்டளையை மீண்டும் இயக்குவது இரண்டு சேவைகளை மாதிரியாக்குகிறது.

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

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

ஹப் உண்மையில் படிக்கும் CCD கோப்பில் அதைக் கோரவும்

சேவையகத்தில் உரிமை அறிவிப்பு அங்கீகரிக்கப்பட்ட பொதுப் பெயரால் தேர்ந்தெடுக்கப்படும் ஒவ்வொரு கிளையன்ட் கோப்பிற்கும் செல்கிறது, client-config-dir பெயரிட்ட அடைவுக்குள். வரி iroute 10.66.0.10 255.255.255.255, ஒரு முகவரிக்கு ஒன்று, அது அந்த இலக்கிற்கான ட்ராஃபிக்கை எந்த இணை பெற வேண்டும் என்பதைச் சேவையகத்திற்குச் சொல்கிறது.

இரண்டு விவரங்கள் இதை அமைதியாக உடைக்கின்றன. கோப்பின் பெயர் சேவையகம் உண்மையில் பயன்படுத்தும் பெயருடன் பொருந்த வேண்டும், username-as-common-name விளையாட்டில் இருக்கும்போது அது வேறுபடும். மேலும் iroute கிளையன்ட் கட்டமைப்பு அடைவு கட்டமைக்கப்பட்ட TUN பயன்முறையில் மட்டுமே செயல்படும், எனவே பால அமைப்பில் அதே வரி எதுவும் செய்யாது. இருக்கும் கோப்பில் வரிகளைச் சேர்க்கவும், அதை மாற்ற வேண்டாம், ஏனெனில் அது ஏற்கனவே நிலையான முகவரி அல்லது push விருப்பங்களைக் கொண்டிருக்கலாம். OpenVPN 2.6 குறிப்பு அடைவு மற்றும் உரிமைக் கட்டளையை ஆவணப்படுத்துகிறது.

ஹப்பின் சொந்த கர்னலுக்கும் அந்த இலக்குகளுக்கு வழி தேவை, உள்ளூரில் உருவாக்கப்பட்ட ட்ராஃபிக் சுரங்கப்பாதை செயல்முறைக்குள் நுழைய. சேவையக கட்டமைப்பில் route 10.66.0.10 255.255.255.255 சேவையகம் தானே உருவாக்கும் ட்ராஃபிக்கை உள்ளடக்குகிறது, மற்ற கிளையன்ட்கள் இலக்கைத் தாங்களே கற்றுக்கொள்ள push "route 10.66.0.10 255.255.255.255" தேவை.

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

உள்ளீட்டுக் கொள்கை மற்றும் பதில் வழியைச் சரிபார்க்கவும்

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

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

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

முகவரிகள் மற்றும் உரிமையைத் தனித்தனியாகச் சோதிக்கவும்

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

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