OpenVPN வாடிக்கையாளருக்குப் பின்னால் உள்ள துணை வலையத்தை ஏன் அணுக முடியவில்லை?

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

tun இடைமுகத்திற்கு ஒவ்வொரு வாடிக்கையாளருக்கும் அடுத்த தாவல் இல்லை. கர்னல் பல துணைவர்கள் கொண்ட ஒரே இடைமுகத்தைப் பார்க்கிறது, எனவே தொலைதூர LAN-க்கு எந்த வாடிக்கையாளர் பொதியைப் பெற வேண்டும் என்ற முடிவு OpenVPN செயல்முறைக்குள் எடுக்கப்பட வேண்டும். அந்த முடிவு iroute மூலம் கட்டமைக்கப்படுகிறது, அது இல்லாமல் பொதிக்கு செல்ல இடமில்லை.

சேவையகம் இடைமுகத்தின் அடிப்படையில் அல்ல, வாடிக்கையாளரின் அடிப்படையில் வழியமைக்கிறது

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

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

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

வாடிக்கையாளரைப் பெயரிடும் iroute பதிவை எழுதுதல்

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

LAN 10.20.0.0/24 ஆகவும் சான்றிதழின் பொதுப்பெயர் branch-router ஆகவும் உள்ள கிளைக்கு, அந்தப் பாதையில் உள்ள கோப்பில் iroute 10.20.0.0 255.255.255.0 போன்ற வரி உள்ளது. முதன்மைக் கட்டமைப்பிற்கு அடைவு விருப்பம் மட்டுமே தேவை; முன்னொட்டு வாடிக்கையாளரிடம் உள்ளது.

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

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

இரு திசைகளிலும் திரும்பும் வழியைக் கட்டமைத்தல்

தொலைதூர LAN-க்கு பொதிகளைக் கொண்டு செல்வது பாதி வேலை. வாடிக்கையாளர் அந்த LAN-இன் போக்குவரத்தையும் சுரங்கப் பாதைக்கு அனுப்ப வேண்டும், இது பொதுவாக வாடிக்கையாளருக்கு ஒரு வழியைத் தள்ளுவதன் மூலம் செய்யப்படுகிறது: push "route 10.8.0.0 255.255.255.0" போன்ற வரி ஒவ்வொரு வாடிக்கையாளருக்கும் சேவையகப் பக்க வலையத்தை எப்படி அடைவது என்று கூறுகிறது. கிளைக்கு, சமமான வழி சேவையகப் பக்கத்தில் அடைய வேண்டிய அனைத்திற்கும் சுரங்கப் பாதையை நோக்கிக் காட்டுகிறது.

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

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

சரியான ஆய்வுகளுடன் அணுகலைச் சரிபார்த்தல்

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

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

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