OpenVPN iroute vs கர்னல் பாதை: எது இல்லை?

10.77.20.0/24 க்கான ஒரு பாக்கெட் OpenVPN சேவையகத்தில் இரண்டு தனித்தனி முடிவுகளை எடுக்கிறது: இயக்க முறைமை அதை VPN இடைமுகத்திற்கு ஒப்படைக்க வேண்டும், OpenVPN அந்த முன்னொட்டை எந்த இணைக்கப்பட்ட வாடிக்கையாளர் வைத்திருக்கிறது என்பதை அறிந்திருக்க வேண்டும். கர்னல் பாதை இல்லாவிட்டால் பாக்கெட் சுரங்கப்பாதைக்கு முன்பே விழும், பியர் பாதை இல்லாவிட்டால் அதற்குப் பிறகு விழும். தொலைதூர LAN இலிருந்து இரண்டு தோல்விகளும் ஒரே மாதிரி தெரிகின்றன, உங்களிடம் எது உள்ளது எனக் கண்டறிய ஒவ்வொரு பக்கமும் ஒரு கட்டளை தேவை.

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

இரண்டு முடிவுகள், ஒரு பாதை அல்ல

10.77.20.0/24 ஒரு வாடிக்கையாளருக்குப் பின்னால் உள்ள தள-தள இணைப்பை கற்பனை செய்யுங்கள். சேவையகத்தின் கர்னல் பாதை, எடுத்துக்காட்டாக ip route add 10.77.20.0/24 dev tun0, பொருந்தும் பாக்கெட்டுகளை சுரங்கப்பாதை சாதனத்திற்கு அனுப்புகிறது. பிறகு OpenVPN வாடிக்கையாளர் கட்டமைப்பு கோப்பகத்தில் உள்ள iroute உள்ளீடுகளால் கட்டப்பட்ட தனது உள் அட்டவணையைப் பார்க்கிறது, எந்தப் பியர் இணைப்பு அவற்றைப் பெறும் என முடிவெடுக்க. கர்னல் பாதை இல்லாமல் பாக்கெட் ஒருபோதும் செயல்முறையை அடையாது, பியர் பாதை இல்லாமல் அது செயல்முறையை அடைந்து எங்கும் செல்லாது.

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

iroute எங்கே இருக்கிறது, என்ன கூறுகிறது

உள்ளீடு வாடிக்கையாளரின் common_name பெயரில் உள்ள ஒரு-வாடிக்கையாளர் கோப்பில், client-config-dir கீழ், iroute 10.77.20.0/24 எனச் செல்கிறது. கோப்பு பெயர் பொருத்தம் அலங்காரம் அல்ல: OpenVPN அங்கீகரிக்கப்பட்ட அடையாளத்தைத் தேடி அதே பெயரில் கோப்பைப் படிக்கிறது, எனவே site-a எனும் கோப்பு அதன் பொதுப் பெயர் site-a ஆக உள்ள வாடிக்கையாளருக்கு மட்டுமே பொருந்தும். அத்தகைய கோப்பு இல்லாத வாடிக்கையாளர்களை முழுமையாக நிராகரிக்க வேண்டுமெனில் ccd-exclusive சேர்க்கவும், ஒவ்வொரு வாடிக்கையாளரும் தள நுழைவாயிலாக இருக்கும்போது இதுவே சரியான அமைப்பு. ஒவ்வொரு நுழைவாயிலுக்கும் ஒரு கோப்பை வைத்து, நீங்கள் உண்மையில் வழங்கும் சான்றிதழ் பொருளின் பெயரால் அதைப் பெயரிடுங்கள்.

தொலைதூர LAN ஐக் குறை சொல்வதற்கு முன் சேவையகத்திலிருந்து உள்ளீட்டைச் சோதியுங்கள். நிலை கோப்பு இணைக்கப்பட்ட வாடிக்கையாளர்களை அவர்களின் பொதுப் பெயர்களுடன் பட்டியலிடுகிறது, --verb 4 உடன் இயங்கும் சேவையகம் பியர் இணையும் தருணத்தில் iroute நிறுவப்படுவதைப் பதிவு செய்கிறது. இணைக்கும்போது எதுவும் தெரியவில்லை எனில், கோப்பு தவறான கோப்பகத்தில் உள்ளது அல்லது தவறான அடையாளத்தைக் குறிப்பிடுகிறது.

பொறி: கோப்பு உள்ளது, அடையாளம் தவறு

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

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

பியருக்கு அப்பால் பாதையை முடிக்கவும்

பியர் உரிமை பாதையின் நடுப்பகுதி, முடிவு அல்ல. வாடிக்கையாளர் பாக்கெட்டுகளை சுரங்கப்பாதையிலிருந்து தனது LAN க்கு அனுப்ப வேண்டும், அதாவது அந்த ஹோஸ்ட்டில் IP அனுப்புதல் இயக்கப்பட்டு, கடந்து செல்ல அனுமதிக்கும் firewall விதி இருக்க வேண்டும். தொலைதூர LAN இல் உள்ள ஹோஸ்ட்களுக்கு சுரங்கப்பாதை முகவரிக்கு திரும்பும் பாதை தேவை: நுழைவாயிலை நோக்கித் திரும்பும் பாதை, அல்லது வாடிக்கையாளர் பக்கத்தில் வேண்டுமென்றே வடிவமைக்கப்பட்ட NAT. விநியோகத்தின் இயல்புநிலை மதிப்பை ஊகிக்காமல் sysctl net.ipv4.ip_forward மூலம் வாடிக்கையாளரில் அனுப்புதல் அமைப்பை உறுதிப்படுத்துங்கள்.

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

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