போக்குவரத்து உண்மையில் VPN வழியாகவே செல்கிறதா? அதை எவ்வாறு சரிபார்ப்பது
வழி தேடல், முதல் தாவல், இயற்பியல் அடாப்டரில் பிடிப்பு மற்றும் வெளியிலிருந்து முகவரி சரிபார்ப்பு ஆகியவை கேள்வியின் வெவ்வேறு பகுதிகளுக்குப் பதிலளிக்கின்றன.
கணினி தட்டுக்குழுவின் சின்னத்திலிருந்து இரு கோளாறுகள் ஒரே மாதிரி தெரிகின்றன: சுரங்கப்பாதைக்குள் செல்லும் போக்குவரத்து மற்றும் அதை அமைதியாகச் சுற்றிச் செல்லும் போக்குவரத்து. இரண்டு நிலைகளிலும் கிளையண்ட் Connected காட்டுகிறது, ஏனெனில் Connected என்பது சுரங்கப்பாதையின் இடைமுகம் உள்ளது என்பதையும் கிளையண்ட் தனக்குத் தேவையான வழிகளை நிறுவியது என்பதையும் மட்டுமே குறிக்கிறது. ஒரு பயன்பாட்டின் ஒரு பாக்கெட் அந்த வழிகளைப் பயன்படுத்தியதா என்பது தனிக் கேள்வி, அதற்கான பதில் அடுக்கின் வேறு இடத்தில் கிடைக்கும். நான்கு அளவீடுகள் அதன் பெரும்பகுதியைத் தீர்க்கின்றன — வழி தேடல், முதல் தாவல், இயற்பியல் அடாப்டரில் பிடிப்பு மற்றும் வெளியிலிருந்து கவனிப்பு — மேலும் சேவையகத்தின் சொந்த அமர்வுத் தோற்றம் மீதியை மூடுகிறது.
பாக்கெட் எடுக்கும் வழியிலிருந்து தொடங்குங்கள்
வழித்தட அட்டவணையே முடிவு, எனவே முழுவதையும் படித்து ஊகிப்பதற்குப் பதிலாக ஒரு இலக்கைப் பற்றி அதைக் கேளுங்கள். Linux இல், ip route get கர்னல் தேர்ந்தெடுத்த இடைமுகத்தையும் மூல முகவரியையும் பெயரிடுகிறது:
ip route get 203.0.113.10
ip route get 10.20.5.7Windows இல், Find-NetRoute -RemoteIPAddress 203.0.113.10 route print -4 ஐ விட பயனுள்ளதாக உள்ளது, அதே காரணத்திற்காக: வென்ற வழியைப் புகாரளிக்கிறது, இருக்கும் எல்லா வழிகளையும் அல்ல. இருப்பினும் அதன் 0.0.0.0 வரிசைக்காக அட்டவணையை ஒருமுறை படியுங்கள். அங்கு /1 இணை இருப்பது முழு சுரங்கப்பாதை கிளையண்ட் இயல்புநிலை வழியை மீண்டும் எழுதியுள்ளது என்று பொருள்: OpenVPN இன் redirect-gateway def1 விருப்பம் சுரங்கப்பாதை வழியாக 0.0.0.0/1 மற்றும் 128.0.0.0/1 ஐ நிறுவுகிறது, இது இயற்பியல் இயல்புநிலையை நீக்காமல் நீண்ட முன்னொட்டுப் பொருத்தத்தில் இருக்கும் 0.0.0.0/0 ஐ வெல்கிறது. அதனால்தான் இரண்டு இயல்புநிலை வழிகள் ஒன்றாக இருக்க முடியும், எல்லாமும் இன்னும் சுரங்கப்பாதைக்குள் செல்லும்போது.
இரு விவரங்கள் அட்டவணையைப் பொய்யாக்குகின்றன. முதலில், இயல்புநிலை வழிகளின் எண்ணிக்கையை அல்ல, பொருந்திய முன்னொட்டைப் பாருங்கள், ஏனெனில் இடைமுக அளவீடு அல்லது /1 இணை வெற்றியாளரைத் தீர்மானிக்கிறது. இரண்டாவது, ஏற்கனவே உள்ள இணைப்பு தான் நிறுவப்பட்ட பாதையையே வைத்திருக்கும்; சுரங்கப்பாதை உயர்ந்த பிறகு திறந்த அமர்வு மீட்டமைக்கப்படும் வரை பழைய வழியைப் பயன்படுத்தலாம், அதனால்தான் மீண்டும் இணைப்பது வழித்தடப் பிரச்சினையைச் சரிசெய்ததாகத் தோன்றுகிறது. இயங்கும் கிளையண்ட் — ps ax | grep openvpn — செயல்முறை தொடங்கியது என்பதை மட்டுமே நிரூபிக்கிறது.
ஒரு உள் மற்றும் ஒரு பொது பெயரைப் பின்தொடருங்கள்
வழி தேடல் நோக்கத்தைக் காட்டுகிறது; பாதை வழங்கலைக் காட்டுகிறது. இணைந்திருக்கும்போது உள் பெயராக இருக்க வேண்டிய ஒரு பெயரையும் இருக்கக் கூடாத ஒரு பெயரையும் பின்தொடர்ந்து முதல் தாவலை ஒப்பிடுங்கள்:
traceroute intranet.corp.example
traceroute 1.1.1.1இரண்டிற்கும் ஒரே முதல் தாவல் என்பது உள் பெயர் சுரங்கப்பாதைக்குள் ஒருபோதும் நுழையவில்லை என்பதையும் கோளாறு அதற்கு மேலே உள்ளது என்பதையும் குறிக்கிறது, பொதுவாக பொது முகவரியாகத் தீர்க்கப்படும் பெயர் அல்லது ஒருபோதும் நிறுவப்படாத வழி. உள் போக்குவரத்து 10.8.0.1 வழியாகவும் பொது போக்குவரத்து 192.168.1.1 வழியாகவும் சென்றால், பிளவுபட்ட சுரங்கப்பாதை அதற்காக அமைக்கப்பட்டதைச் சரியாகச் செய்கிறது. VPN நுழைவாயிலை அடைந்து பின்னர் நேர முடிவுகளை மட்டும் திருப்பித் தரும் தடம் பொதுவாகத் திரும்பும் பாதை அல்லது சேவையக தீச்சுவர் சிக்கல், காணாமல் போன முன்னனுப்பு வழி அல்ல.
வடிகட்டிய ICMP இந்தச் சரிபார்ப்பைப் பொய்யாக்குகிறது: இரு தடங்களிலும் நட்சத்திரங்கள் இறந்த சுரங்கப்பாதை போலத் தெரிகின்றன, பொதுவாக அது தீச்சுவர். முடிந்த இடத்தில் TCP துறையைச் சோதியுங்கள் — Linux இல் traceroute -T -p 443 — மேலும் தடம் எந்தத் தீர்ப்பான் பதிலளித்தது என்று கூறாது என்பதை நினைவில் கொள்ளுங்கள்: ஒரு பெயர் உள்ளூரில் தீர்க்கப்பட்டு சுரங்கப்பாதை வழியாகவும் அடையக்கூடும்.
சுரங்கப்பாதையில் அல்ல, இயற்பியல் அடாப்டரில் பிடியுங்கள்
வலைப்பின்னல் உண்மையில் என்ன பார்க்கிறது என்பதைக் காட்டும் ஒரே இடம் இயற்பியல் இணைப்பு. சுரங்கப்பாதை மேலே இருக்கும்போது அலுவலகத்திற்கான அமர்வு VPN சேவையகத்திற்கு முகவரியிடப்பட்ட மறையாக்கப்பட்ட சுமையாகத் தெரிய வேண்டும், 10.20.5.7 உடன் இணைப்பாக அல்ல:
sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5முதல் வடிகட்டி உள்ளூரில் வெளியேறும் பெயர்த் தீர்வைப் பிடிக்கிறது, இது மிகவும் பொதுவான மற்றும் மிகவும் அமைதியான கசிவு — பக்கம் இன்னும் ஏற்றப்படுகிறது, தீர்ப்பான் வினவலைப் பார்த்தது மட்டுமே. இரண்டாவது சுரங்கப்பாதைக்குள் மட்டுமே இருக்க வேண்டிய உள் முகவரிக்குச் செல்லும் சாதாரண போக்குவரத்தைப் பிடிக்கிறது. Windows இல், pktmon இயக்கி இல்லாமல் அதே வேலையைச் செய்கிறது: pktmon filter add -p 53, பின்னர் pktmon start --capture --pkt-size 128, பின்னர் pktmon stop மற்றும் pktmon format pktmon.etl -o capture.txt. இந்தக் கொடிகள் Windows பதிப்புகளுக்கிடையே சிறிது வேறுபடுகின்றன, எனவே தொடரியலை நம்புவதற்கு முன் pktmon filter add /? ஐச் சரிபார்க்கவும்.
கசிவுகளைக் கண்டறிய இயற்பியல் இடைமுகத்தில் பிடியுங்கள்; சுரங்கப்பாதையில் பிடிப்பது அங்கே இருப்பதாக நீங்கள் ஏற்கனவே நம்பும் பாக்கெட்டுகளைக் கொண்டுள்ளது, சேவையகத்தில் அது மூலம் நுழைவாயில் என்று இருக்கும் படிக்க முடியாத வெளிப்புற பாக்கெட்டுகளைக் கொண்டுள்ளது. எந்த இடைமுகத்தின் பைட் கணக்கீடுகளும் பாக்கெட்டுகளை விவரிக்கின்றன, நிரல்களை அல்ல; போக்குவரத்தை ஒரு செயல்முறைக்குக் கூற சாக்கெட்டுகளை செயல்முறைகளுடன் இணைக்கும் கண்காணிப்பு தேவை.
வெளிப்புற சேவையைக் கேளுங்கள், பின்னர் ஒவ்வொரு பயன்பாட்டிற்கும் மீண்டும் கேளுங்கள்
வெளியேறலை நிரூபிக்கும் ஒரே சரிபார்ப்பு வெளியிலிருந்து வரும் பதில்: தான் பார்த்த மூல முகவரியைத் திருப்பித் தரும் சேவை. இடைமுகத்தைத் தேர்ந்தெடுக்கக்கூடிய ஷெல்லிலிருந்து அதை இயக்கி, இருமுறை இயக்குங்கள்:
sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ipவேறுபட்ட பதில்கள் இரு பாதைகளுக்கும் ஆதாரத்தையும் குறிப்பிட்ட பயன்பாட்டைச் சோதிக்கும் வழியையும் தருகின்றன: அதைப் பிணைக்கவும், அல்லது ஒரே வழியுடன் வலைப்பின்னல் பெயர்வெளியில் இயக்கி, தொலை முனை எந்த முகவரியைப் பதிவு செய்கிறது எனப் பாருங்கள். ஒரே மாதிரியான பதில்களே சுவாரஸ்யமான கோளாறு: ஒன்று பிணைப்பு வேலை செய்யவில்லை, அல்லது ஹோஸ்ட்டுக்கும் தொலை முனைக்கும் இடையே ஏதோ வந்து சேர்வதற்கு முன் மூல முகவரியை மீண்டும் எழுதுகிறது. Windows இல், curl --interface அடாப்டரின் பெயரை அல்ல, முகவரியைக் கேட்கிறது.
VPN முகவரியைப் புகாரளிக்கும் உலாவி அந்த உலாவியை நிரூபிக்கிறது. மின்னஞ்சல் கிளையண்ட், தொகுப்பு மேலாளர், காப்பு முகவர் அல்லது இரண்டாவது உலாவி சுயவிவரம் ஒவ்வொன்றும் வேறு பாதையை எடுக்கலாம், குறிப்பாக ப்ராக்ஸி அமைப்பு அல்லது பிளவுபட்ட சுரங்கப்பாதை வழி அவற்றில் ஒன்றை மூடும்போது. முகவரி மாற்றம் தானாகவே கசிவுக்கான ஆதாரம் அல்ல: சுமை சமநிலைப்படுத்தி பார்த்த வெளியேற்றத்தைப் பொறுத்து வேறுவிதமாகப் பதிலளிக்கலாம், எனவே பக்கத்தை அல்ல, பதிவு செய்யப்பட்ட மூல முகவரியை ஒப்பிடுங்கள்.
சகாவை உறுதிப்படுத்த சேவையகத் தோற்றத்தைப் பயன்படுத்துங்கள்
சேவையகம் வேறு கேள்விக்குப் பதிலளிக்கிறது: சகா இணைந்துள்ளாரா, எவ்வளவு எடுத்துச் சென்றார், அமர்வு மீண்டும் தொடங்கியதா. சேவையகத்தில் சகா செயலில் இருக்கும்போது கிளையண்ட் கணக்கீடுகள் அரிதாக நகர்ந்தால், கிளையண்ட் அட்டவணை என்ன சொன்னாலும் பயன்பாட்டுப் போக்குவரத்து சுரங்கப்பாதைக்குள் செல்லவில்லை என்று பொருள். எதுவும் வேலை செய்யவில்லை எனக் கூறும் பயனருக்கு நிறைய தரவை நகர்த்தும் சகா வேறு விசாரணை.
இங்கே இரு பொறிகள் உள்ளன. முகமூடி சுரங்கப்பாதை ஒவ்வொரு ஓட்டத்தையும் நுழைவாயிலிலிருந்து வந்ததாகக் காட்டுகிறது, எனவே பதிவுகளும் ஒவ்வொரு கிளையண்டிற்கான கணக்கும் ஒரே முகவரியில் சரிந்துவிடுகின்றன. கிளையண்ட் உள்ளூர் ஹோஸ்ட்டாகக் கருதப்படுகிறது, எனவே யாராவது VPN வழியாகக் கோப்புகளை நகலெடுக்கிறார்களா என்ற கேள்விக்கு சேவையகத்தின் கோப்புப் பங்கீட்டுப் போக்குவரத்து அல்லது சேவையகத்தின் ஹோஸ்ட் தணிக்கை பதிலளிக்கிறது — சுரங்கப்பாதையைக் கவனிப்பது முனைகளையும் அளவையும் தருகிறது, கோப்புப் பெயர்களை அல்ல.
வடிவமைப்பு முடிவைக் கசிவிலிருந்து வேறுபடுத்துங்கள்
சுரங்கப்பாதைக்கு வெளியே உள்ள அனைத்தும் கசிவு அல்ல. இணைப்பு-உள்ளூர் மற்றும் ஒளிபரப்பு போக்குவரத்து வடிவமைப்பின்படி உள்ளூரிலேயே இருக்கும், multicast மூலம் கண்டறியப்பட்ட அச்சுப்பொறி LAN இல் அறிவிப்பைத் தொடர்கிறது, DHCP உள்ளூரில் வெளியேற வேண்டும். குறிப்பிட்ட இடைமுகத்தில் பிணைக்கப்பட்ட பயன்பாடு வேண்டுமென்றே வழித்தட அட்டவணையைத் தவிர்க்கிறது, அதை மாற்றுவது தீச்சுவர் விதி, பெயர்வெளி அல்லது கொள்கை வழி மட்டுமே.
IPv6 சரிபார்ப்புப் பட்டியலில் தனக்கென ஒரு வரிக்குத் தகுதியானது. IPv4 மட்டும் எடுத்துச் செல்லும் சுரங்கப்பாதை இரட்டை-அடுக்கு ஹோஸ்ட்டுக்கு இரண்டாவது பயன்படுத்தக்கூடிய பாதையை விட்டுச் செல்கிறது, இரட்டை-அடுக்கு இலக்கு அதை விரும்பும் — DNS உட்பட, தீர்ப்பான் IPv6 வழியாக அடையக்கூடியதாக இருந்தால். IPv4 முடிவை முழுமையானதாகக் கருதும் முன் அடாப்டரில் IPv6 ஐ முடக்கவும் அல்லது சுரங்கப்பாதை அதை எடுத்துச் செல்கிறது என்பதை உறுதிப்படுத்தவும்.
சரிபார்ப்புகள் பொருந்தாதபோது, வேறுபாடே பொதுவாகக் கோளாறைப் பெயரிடுகிறது:
| What you see | What it means | Next step |
|---|---|---|
| The route picks tun0 but the capture shows cleartext to 10.20.5.7 | Something bypassed the table: a bound app, a policy route or a session older than the tunnel | Reset the flow, check the app bind, check the ip rule list |
| The route picks eth0 for an internal name | The name resolves to a public address, or the route was never installed | Compare the resolved address with the routes the server pushes |
| The capture shows DNS to the LAN resolver | Resolver leak: data is tunneled, lookups are not | Point the resolver inside, or push it from the server |
| All four checks agree and one app still fails | Path selection is fine; suspect MTU, a per-app proxy or the far end | Test the same destination from a known-good client |
வேலை செய்யும் வரிசை: இணைவதற்கு முன்னும் பின்னும் வழித்தட அட்டவணையைச் சேமியுங்கள், ஒரு உள் மற்றும் ஒரு பொது பெயரைப் பின்தொடருங்கள், இயற்பியல் அடாப்டரில் DNS ஐப் பிடியுங்கள், குறிப்பிட்ட பயன்பாட்டிற்காக ஷெல்லிலிருந்து வெளியேறும் முகவரியைத் திருப்பித் தாருங்கள், பின்னர் அளவிற்காக சேவையகத்தைப் படியுங்கள். முதல் நான்கு பொருந்தினால், சுரங்கப்பாதை நீங்கள் நினைப்பதை எடுத்துச் செல்கிறது, மீதமுள்ள சிக்கல் அதற்கு மேலே உள்ளது. அவற்றில் இரண்டு பொருந்தவில்லை என்றால், பொருந்தாத இணையே கோளாறு, சின்னம் அல்ல.