VPN வழியாக ஒரே ஒரு தனியார் துணை வலையமைப்பை மட்டும் அனுப்புவது எப்படி

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

வடிவமைப்பைத் தீர்மானிக்கும் மூன்று நிபந்தனைகள்

முதலில், வலையமைப்பின் உரிமையாளரிடமிருந்து துல்லியமான முன்னொட்டு மற்றும் முகமூடி உங்களுக்குத் தேவை. 10.x வலையமைப்பு முன்னொட்டு அல்ல; 10.20.0.0/16 முன்னொட்டு. இது உங்கள் வீட்டு LAN, Docker பாலம் அல்லது நீங்கள் இயக்கும் மற்றொரு VPN உடன் ஒன்றிணையவில்லை என்பதை உறுதிசெய்யுங்கள், ஏனெனில் ஒன்றிணைவு வழியைத் தெளிவற்றதாக்கி, கர்னல் நீங்கள் நினைக்காத உள்ளீட்டைத் தேர்ந்தெடுக்கும்.

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

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

WireGuard: AllowedIPs தான் வழித்தட அட்டவணை

வாடிக்கையாளரில், AllowedIPs சுரங்கப்பாதைக்குள் நுழையக்கூடிய இடங்களைப் பட்டியலிடுகிறது, wg-quick ஒவ்வொரு உள்ளீட்டையும் சாதாரண வழியாக மாற்றுகிறது. எனவே இந்த வேலையின் வாடிக்கையாளர் பாதி ஒரே வரி.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

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

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

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

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

OpenVPN: வழியைத் தள்ளுங்கள், பின்னர் அது வந்து சேர்ந்ததா என்பதை உறுதிசெய்யுங்கள்

சாதாரண சேவையகத்தில் மாற்றம் சேவையகக் கட்டமைப்பில் வாடிக்கையாளர் தொகுப்புக்கு அருகிலுள்ள ஒரு கட்டளை.

push "route 10.20.0.0 255.255.0.0"

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

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

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

முகவரி குடும்பங்களைத் தனித்தனியாக வைத்திருங்கள்: தள்ளப்பட்ட IPv4 வழி IPv6 ஆகத் தீர்க்கப்படும் உள் சேவைக்கு எதுவும் செய்யாது, அந்தச் சேவை சுரங்கப்பாதையின் வழியாகத் தோல்வியடையும், மற்றவை நன்றாகத் தெரியும்.

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

IPsec: போக்குவரத்துத் தேர்வான்கள் ஒத்துப்போக வேண்டும்

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

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

நுழைவாயில் இரு பக்கமும் 0.0.0.0/0 உடன் கட்டமைக்கப்பட்டிருந்தால், IKEv2 இன் குறுக்கம் பொதுவாக குழந்தை SA ஐ இரு முன்மொழிவுகளின் வெட்டுப்புள்ளிக்குக் குறைக்கும், அதுவே விரும்பிய முடிவு. சில நுழைவாயில்கள் அதற்குப் பதிலாக தங்கள் கட்டமைக்கப்பட்ட தேர்வான்களுடன் பொருந்தாத முன்மொழிவை நிராகரிக்கின்றன, பதிவில் அப்போது வழி புகாருக்குப் பதிலாக தோல்வியடைந்த குழந்தை SA தெரியும். அப்படி நடக்கும்போது மாற்றம் நுழைவாயிலுக்கு உரியது, ஏனெனில் வாடிக்கையாளர் வழியால் மறுபக்கம் ஏற்காத தேர்வானுக்கு சுரங்கப்பாதையை உருவாக்க முடியாது.

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

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

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

முனைப்புள்ளி மற்றும் DNS ஐ முடிவுக்கு வெளியே வைத்திருங்கள்

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

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

சரிபார்த்து, பின்னர் மறுதொடக்கம் செய்து மீண்டும் சரிபாருங்கள்

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

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

முதல் வரி ஒரு இடைமுகத்தைப் பெயரிடுகிறது. அது உங்கள் இயற்பியல் இடைமுகத்தைப் பெயரிட்டால், வழி ஒருபோதும் வரவில்லை. Windows இல் Find-NetRoute -RemoteIPAddress 10.20.5.7 அதே கேள்விக்குப் பதிலளிக்கிறது, கடைசி சோதனை இன்னும் உங்கள் சாதாரண முகவரியைக் காட்ட வேண்டும், VPN சேவையகத்தின் முகவரியை அல்ல.

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

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