WireGuard வாடிக்கையாளர் OpenVPN வாடிக்கையாளரை அடைய முடியவில்லையா?

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

அறிகுறியில் ஒரு நேரத்தில் ஒரு பகுதி மட்டுமே குறைகிறது

இந்த வடிவமைப்பு wg1 இல் 10.71.0.0/24 இன் WireGuard குளத்தையும் tun1 இல் 10.72.0.0/24 இன் OpenVPN குளத்தையும் பயன்படுத்துகிறது, இரண்டும் ஒரே நுழைவாயிலில் முடிகின்றன. சோதிக்கப்படும் கோரிக்கை 10.71.0.5 இலிருந்து 10.72.0.30 இல் உள்ள HTTPS க்குச் செல்கிறது. கீழேயுள்ள ஒவ்வொரு படியும் அந்த ஒரே ஓட்டத்தைப் பற்றியது. ஒவ்வொரு சோதனைக்கும் வேறு தோல்விக் கையொப்பம் இருந்தாலும் பயனர் அவற்றை ஒரே மாதிரியாகவே அனுபவிக்கிறார், பொதுவாக ஒரு நேரத்தில் மூன்றில் ஒன்று மட்டுமே குறைகிறது.

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

ஸ்போக்கின் இலக்கு பரப்பை விரிவாக்குங்கள்

WireGuard வாடிக்கையாளரில், ஏற்கனவே உள்ள peer பதிவு OpenVPN இலக்குக்காக நுழைவாயிலைத் தேர்ந்தெடுக்க வேண்டும், அதாவது இலக்கு முன்னொட்டு அந்த peer இன் அனுமதிக்கப்பட்ட பட்டியலில் இருக்க வேண்டும். அதைச் சேர்ப்பது இரண்டாவது சுரங்கப்பாதையை உருவாக்காது; அந்த முகவரியைத் தேடும்போது வாடிக்கையாளர் எந்த peer ஐத் தேர்ந்தெடுக்கிறார் என்பதை மாற்றுகிறது, wg-quick உடன் பாதை வழக்கமாகப் பட்டியலைத் தானாகவே பின்பற்றுகிறது.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

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

நுழைவாயிலில் மூல உரிமையை வைத்திருங்கள்

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

AllowedIPs = 10.71.0.5/32

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

OpenVPN பக்கத்திற்குத் திரும்பும் பாதையைக் கொடுங்கள்

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

push "route 10.71.0.0 255.255.255.0"

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

நீங்கள் அனுமதிக்க நினைத்த அந்த ஒரே சேவையை மட்டும் அனுமதியுங்கள்

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

இவை அனுப்பப்படும் போக்குவரத்துக்கான விதிகள், நுழைவாயிலின் இரு VPN சேவைகளுக்கான கேட்கும் விதிகளிலிருந்து வேறுபட்டவை. வெளிப்புற UDP துறைகளைத் திறப்பது உட்புறக் கோரிக்கைக்கு அதிகாரம் அளிக்காது, உட்புறக் கோரிக்கைக்கு அதிகாரம் அளிக்க நுழைவாயிலுக்கு வரம்பற்ற SSH அல்லது அனுப்புதலில் இயல்புநிலை அனுமதி தேவையில்லை. இலக்கின் சொந்த firewall உம் கேட்கும் முகவரியும் பொருந்த வேண்டும், ஏனெனில் loopback உடன் பிணைக்கப்பட்ட சேவை மிகக் கவனமாகப் பாதையிடப்பட்ட பொதியையும் மறுக்கிறது. உரையாடலின் ஒரு திசையை மட்டும் மூடும் கொள்கை வழக்கமாக வெற்றிகரமான கோரிக்கையும் அமைதியான பதிலும் கொண்டு தோல்வியடைகிறது, இது மூன்றில் மிகக் குழப்பமான முடிவு.

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