பயன்பாட்டை அடிப்படையாகக் கொண்ட vs இலக்கை அடிப்படையாகக் கொண்ட ஸ்பிளிட் டனலிங்: எதைத் தேர்ந்தெடுப்பது
ஒரு விதி செயல்முறையைப் பின்தொடர்கிறது, மற்றொன்று முகவரியைப் பின்தொடர்கிறது. நீங்கள் கட்டுப்படுத்த வேண்டியதன் அடிப்படையில் தேர்ந்தெடுத்து, பின்னர் அதே துணை வலையமைப்பில் ஒரு துணைச் செயல்முறையையும் இரண்டாவது பயன்பாட்டையும் சோதிக்கவும்.
பயன்பாட்டை அடிப்படையாகக் கொண்ட மற்றும் இலக்கை அடிப்படையாகக் கொண்ட ஸ்பிளிட் டனலிங் ஒரே வேலைக்கான இரண்டு அமைப்புகள் அல்ல. ஒன்று எந்த செயல்முறை பாக்கெட்டை அனுப்புகிறது என்று கேட்கிறது; மற்றொன்று அந்தப் பாக்கெட் எங்கே செல்கிறது என்று கேட்கிறது. முதல் கேள்விக்காக உருவாக்கப்பட்ட விதி போக்குவரத்து ஒரு துணைச் செயல்முறையிலிருந்து வரும்போது அமைதியாகத் தோல்வியடைகிறது, இரண்டாவதற்காக உருவாக்கப்பட்ட விதி நீங்கள் ஒருபோதும் பட்டியலிடாத முகவரிக்கு ஹோஸ்ட்பெயர் தீர்க்கப்படும்போது தோல்வியடைகிறது. தேவைக்குப் பொருந்தும் பொருளைத் தேர்ந்தெடுத்து, பின்னர் இரண்டு சோதனைப் பாக்கெட்டுகளால் நிரூபிக்கவும்: ஒன்று டனலைப் பயன்படுத்த வேண்டும், மற்றொன்று பயன்படுத்தக்கூடாது.
இரண்டு விதிகளும் வெவ்வேறு அடுக்குகளில் செயல்படுகின்றன
பயன்பாட்டு விதி பிணைய அடுக்குக்கு மேலே, இயக்க முறைமை அனுப்புநருக்கு வழங்கும் அடையாளத்திற்கு எதிராகச் செயல்படுத்தப்படுகிறது. Android இல் அது தொகுப்பின் பின்னால் உள்ள UID, மேலும் VPN சேவை ஒவ்வொரு UID க்கும் போக்குவரத்து டனலுக்குள் நுழைகிறதா என்பதைத் தீர்மானிக்கிறது. இலக்கைப் பற்றி எதுவும் கேட்கப்படுவதில்லை, எனவே தேர்ந்தெடுக்கப்பட்ட பயன்பாடு எதையும் அடைய முடியும், வேறு எந்தப் பயன்பாடும் உள் வலையமைப்பை அடைய முடியாது.
இலக்கு விதி பாக்கெட்டின் மீதே செயல்படுத்தப்படுகிறது. டனல் இடைமுகம் ஒரு தொகுதி முன்னொட்டுகளைக் கொண்டுள்ளது, வழிசெலுத்தல் அட்டவணை பொருந்தும் போக்குவரத்தை அதற்குள் அனுப்புகிறது, அனுப்பும் செயல்முறை பொருத்தமற்றது. அதனால்தான் இலக்கு விதி யாரும் பட்டியலிட நினைவில் கொள்ளாத சேவை, அச்சுப்பொறி அல்லது தொகுதிப் பணியை உள்ளடக்குகிறது, அதனால்தான் வாடிக்கையாளர் செயல்முறையை ஒருபோதும் பார்க்காத தளத்தில் அதை வெறும் இந்த நிரல் என்று கூற முடியாது.
பயன்பாட்டு விதிகள் மொபைல் வாடிக்கையாளர்களுக்கும் நிர்வகிக்கப்பட்ட முகவர்களுக்கும் பொருந்தும்
Android தேர்வை நேரடியாக வெளிப்படுத்துகிறது: VpnService.Builder.addAllowedApplication() மற்றும் addDisallowedApplication() தொகுப்புப் பெயர்களை எடுத்து ஒவ்வொரு UID க்கும் முடிவைச் செயல்படுத்துகின்றன, Android இன் VPN உருவாக்குநர் வழிகாட்டியில் விவரிக்கப்பட்டபடி. iOS இல் தொகுப்பு அடையாளங்களை அடிப்படையாகக் கொண்ட ஒவ்வொரு பயன்பாட்டிற்குமான VPN விதிகள் மூலம் சமமான ஏற்பாடு உள்ளது, பொதுவாக கையால் எழுதுவதற்குப் பதிலாக MDM சுயவிவரத்தால் வழங்கப்படுகிறது.
டெஸ்க்டாப் வாடிக்கையாளர்கள் பலவீனமான இடம். பெரும்பாலான Windows மற்றும் macOS VPN வாடிக்கையாளர்கள் இலக்கின் அடிப்படையில் வழிசெலுத்துகின்றன, செயல்முறை அடிப்படையிலான தேர்வை அளிப்பதில்லை, ஏனெனில் டனல் இயக்கி செயல்முறைகளை அல்ல, பாக்கெட்டுகளைப் பார்க்கிறது. உங்கள் திட்டம் மடிக்கணினியில் ஒரு பயன்பாட்டை டனல் செய்வதைச் சார்ந்திருந்தால், அதைச் சுற்றி வடிவமைப்பதற்கு முன் வாடிக்கையாளரின் உண்மையான திறன்களைச் சரிபார்க்கவும்; ஒருவேளை நீங்கள் இலக்குப் பட்டியலுக்கும் இரண்டாவது இயந்திரத்திற்கும் இடையே தேர்ந்தெடுக்கிறீர்களாக இருக்கலாம்.
மக்கள் தவறவிடும் விளைவு: அந்தத் தளங்களில் வழிகளால் பயன்பாட்டு விதியைப் பின்பற்ற முடியாது. பயன்பாட்டின் சேவையகத்திற்கு ஒரு ஹோஸ்ட் வழியைச் சேர்த்தால் உலாவி மற்றும் புதுப்பிப்பான் உட்பட அனைவரின் போக்குவரத்தும் அந்தச் சேவையகத்திற்கு டனல் செய்யப்படும்.
இலக்கு விதிகள் துணை வலையமைப்புப் பட்டியல்களுக்கும் தள அணுகலுக்கும் பொருந்தும்
WireGuard மாதிரியை வெளிப்படையாக்குகிறது. AllowedIPs என்பது குறியாக்கச் சாவி வழிசெலுத்தல்: இலக்கு ஒரு சகாவின் பட்டியலுக்குள் விழும் உள் பாக்கெட் அந்தச் சகாவுக்கு குறியாக்கப்படுகிறது, மற்ற அனைத்தும் சாதாரண பாதை வழியாக குறியாக்கம் இல்லாமல் வெளியேறும். பெயரிட ஒரு செயல்முறையும் இல்லை, என்ன சேர்க்கப்பட்டுள்ளது என்பதில் எந்தத் தெளிவின்மையும் இல்லை.
OpenVPN தள்ளப்பட்ட வழிசெலுத்தல் அட்டவணை வழியாக அதே இடத்தை அடைகிறது. route-nopull சேவையகம் வழிகளைக் கட்டளையிடுவதைத் தடுக்கிறது, பின்னர் வாடிக்கையாளர் பக்க route 10.20.0.0 255.255.0.0 vpn_gateway அலுவலக முன்னொட்டைச் சரியாக உள்ளடக்குகிறது. IPv6 இந்த ஒவ்வொரு வாடிக்கையாளரிலும் தனி அறிக்கை, அதை மறப்பது சரியாகத் தோன்றும் IPv4 பிரிவைச் சுற்றி கசிவதற்கான மிகவும் பொதுவான வழி.
ஹோஸ்ட்பெயர் ஒரு வழி அல்ல. சுயவிவரம் ஒரு டொமைன் புலத்தை வழங்கினால், அதை வாடிக்கையாளர் ஒருமுறை தீர்க்கும் பெயராகக் கருதுங்கள், நிரந்தர முகவரி வரம்பாக அல்ல; உள்ளடக்க விநியோக வலையமைப்புகளும் சுமை சமநிலைப்படுத்திகளும் நாளை வேறு முகவரிகளைத் தரும்.
இரு மாதிரிகளும் உடையும் இடம்: உதவியாளர்கள், பகிரப்பட்ட சேவைகள், தீர்விகள்
துணைச் செயல்முறைகள் பயன்பாட்டு விதிகளை உடைக்கின்றன சேவையகக் கோளாறு போலத் தோன்றும் வகையில். உலாவியின் புதுப்பிப்பான், செயலிழப்பு அறிக்கையாளர், SYSTEM ஆக இயங்கும் ஒத்திசைவு சேவை மற்றும் வேறு தொகுப்பில் உட்பொதிக்கப்பட்ட WebView அனைத்தும் தனித்தனி அடையாளங்கள், எனவே உலாவியை டனல் செய்வது உண்மையான கோரிக்கையை டனலுக்கு வெளியே விட்டுவிடலாம். நேர்மாறாகவும் அதே குழப்பம்: டனல் செய்யப்பட்ட செயல்முறைக்குள் பகிரப்பட்ட நூலகத்தை அழைக்கும் விலக்கப்பட்ட பயன்பாட்டின் போக்குவரத்தும் டனல் வழியாகவே செல்கிறது.
இலக்கு விதிகள் பகிரப்பட்ட சேவைகளிலும் பெயர்களிலும் உடைகின்றன. கோப்புப் பங்கீடுகள், அச்சுப்பொறிகள், உள் DNS மற்றும் உரிம சேவையகம் அனைத்தும் முகவரிகளில் வாழ்கின்றன, எனவே ஒரு பயன்பாட்டு டனல் உலாவிக்கு அணுகலைத் தரும் அதே வேளையில் மேப் செய்யப்பட்ட இயக்ககம் இறந்ததாகவே இருக்கும். அந்த மூடல் வேறுபாடு எந்த மாதிரியிலும் பிழை அல்ல, ஆனால் ஒரு பயன்பாட்டு டனல் VPN இயங்குகிறது ஆனால் பங்கீடு போய்விட்டது என்ற நிலையை அடிக்கடி உருவாக்குவதற்கான காரணம் அதுவே.
தீர்விகள் இரண்டையும் கடக்கின்றன. வாடிக்கையாளர் உள் DNS சேவையகங்களை அமைத்தால், ஆனால் இயக்க முறைமை பொது தீர்விக்கு HTTPS மேல் DNS ஐப் பயன்படுத்தினால், பதில் டனலுக்கு வெளியிலிருந்து வருகிறது, இலக்கு விதி ஒருபோதும் பொருந்தாமல் போகலாம். விதி தவறு என்று முடிவெடுக்கும் முன் எந்தத் தீர்வி உண்மையில் பதிலளித்தது என்று பார்க்கவும், வாடிக்கையாளர் பக்கத்தில் டனல் தீர்வியை நிறுவியதா என்று உறுதிசெய்யவும். DNS ஐ டனலுக்கு வெளியே விடும் பிரிவு வழிசெலுத்தல் அட்டவணையில் சரியானதாகத் தோன்றும், இருப்பினும் ஒவ்வொரு உள் பெயரிலும் தோல்வியடையும்.
செயல்முறை: தேர்ந்தெடு, பயன்படுத்து, சரிபார்
மெனுவிலிருந்து அல்ல, தேவையிலிருந்து தொடங்கவும். இலக்கு இந்தப் பயன்பாடு மட்டும் டனலைப் பயன்படுத்தலாம் என்பதாக இருந்தால், பயன்பாட்டு விதிகளும் அவற்றை ஆதரிக்கும் தளமும் தேவை. இலக்கு இந்த வலையமைப்புகள் டனல் வழியாக அணுகக்கூடியவை என்பதாக இருந்தால், முன்னொட்டுகள் தேவை. பதில் இரண்டுமானால், அவற்றை இரண்டு தனி கட்டுப்பாடுகளாகச் செயல்படுத்தி எது எந்தத் தோல்விக்குப் பொறுப்பு என்று எழுதுங்கள்.
நீங்கள் வெளிப்படுத்தக்கூடிய மிகக் குறுகிய வடிவத்தைப் பயன்படுத்தி, பின்னர் வாடிக்கையாளரின் நிலைச் சின்னத்திற்குப் பதிலாக வழிசெலுத்தல் அட்டவணையைக் கேட்டு சரிபார்க்கவும்:
ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40
முதல் இரண்டு வரிகள் உண்மையான இலக்கு பயன்படுத்தும் இடைமுகத்தைப் பெயரிடுகின்றன; wg show அமைக்கப்பட்ட முன்னொட்டுப் பட்டியலை அச்சிடுகிறது; Windows இல் Find-NetRoute பாக்கெட் அனுப்பப்படும்போது ஸ்டாக் பதிலளிக்கும் அதே கேள்விக்குப் பதிலளிக்கிறது. இடைமுகம் டனலாக இருந்தால், விதி பொருந்தியது.
பின்னர் விலக்கப்பட வேண்டிய இரண்டாவது பாக்கெட்டை வேறு பயன்பாட்டிலிருந்து அதே இலக்கிற்குச் சோதிக்கவும். டிக்கெட்டில் வாடிக்கையாளர் பதிப்பு, விதி வகை, முன்னொட்டு அல்லது தொகுப்புப் பட்டியல் மற்றும் கவனிக்கப்பட்ட இரண்டு முடிவுகளைப் பதிவு செய்யவும். அந்த முடிவு இணையே அடுத்த பொறியாளருக்கு கொள்கை தவறாக அமைக்கப்பட்டதா அல்லது போக்குவரத்து ஒருபோதும் அதற்கு சொந்தமானதல்லவா என்பதைச் சொல்கிறது.