OpenVPN கிளையண்ட்கள் கேட்வேயின் IPsec தேர்விகளை ஏன் தவறவிடுகின்றன

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

கேட்வேயின் ping உங்கள் கிளையண்ட் ஒருபோதும் பயன்படுத்தாத ஓட்டத்தைச் சோதிக்கிறது

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

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

பயன்பாடு உண்மையில் தேவைப்படும் தொலை முன்னொட்டைத் தள்ளுங்கள்

இணைக்கப்பட்ட கிளையண்ட்களுக்கு 10.8.0.0/24 மற்றும் பாதுகாக்கப்பட்ட தொலை நெட்வொர்க்குக்கு 172.30.239.0/25 என்ற எடுத்துக்காட்டு இணையை எடுத்துக் கொள்ளுங்கள். கிளையண்டிற்குத் தேவையானது இரண்டாவது முன்னொட்டுக்கான வழி, கேட்வேயின் LAN அல்ல, வேறு சுரங்கப்பாதை முகவரியும் அல்ல. குளத்திற்குத் தள்ளப்பட்ட வழிதான் கிளையண்டை அந்தப் போக்குவரத்தை கேட்வேயிடம் ஒப்படைக்கச் செய்கிறது. அது இல்லாமல் பாக்கெட் நீங்கள் பிழைத்திருத்தும் கொள்கை முடிவை ஒருபோதும் அடையாது.

தள்ளப்பட்ட வழிகளை ஏற்கும் Community சேவையகத்தில், வழிமுறை உண்மையான முகமூடியை எடுக்கிறது: push "route 172.30.239.0 255.255.255.128". Access Server அதே இலக்கை நிறுவப்பட்ட பதிப்பின் தனியார் நெட்வொர்க் அல்லது அணுகல் விதி அமைப்புகள் வழியாக அமைக்கிறது, வழிமாற்று அல்லது மொழிபெயர்ப்பு பயன்முறை வேண்டுமென்றே தேர்ந்தெடுக்கப்படுகிறது. உரிமையாளர் உள்ளமைவுக்குப் பதிலாக உருவாக்கப்பட்ட ஃபயர்வால் சங்கிலிகளைத் திருத்துவதே செயல்படும் நிறுவலை மீண்டும் உருவாக்க முடியாததாக்கும் வழி.

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

தேர்விகள் கிளையண்ட் குளத்தை உள்ளடக்கச் செய்யுங்கள்

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

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

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

வேண்டுமென்றே வழிமாற்று அல்லது மொழிபெயர்ப்பைத் தேர்ந்தெடுங்கள்

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

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

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

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

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

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