ట్రాఫిక్ నిజంగా 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 ద్వారా ఫైళ్లను కాపీ చేస్తున్నారా అన్న ప్రశ్నకు సర్వర్‌పై ఫైల్ షేరింగ్ ట్రాఫిక్ లేదా సర్వర్‌పై హోస్ట్ ఆడిట్ సమాధానం ఇస్తుంది — సొరంగాన్ని గమనించడం చివరలను మరియు పరిమాణాన్ని ఇస్తుంది, ఫైల్ పేర్లను కాదు.
డిజైన్ నిర్ణయాన్ని లీక్ నుండి వేరు చేయండి
సొరంగం వెలుపల ఉన్నదల్లా లీక్ కాదు. లింక్-స్థానిక మరియు ప్రసార ట్రాఫిక్ డిజైన్ ప్రకారం స్థానికంగానే ఉంటుంది, మల్టీకాస్ట్ ద్వారా కనుగొన్న ప్రింటర్ 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 క్యాప్చర్ చేయండి, నిర్దిష్ట అప్లికేషన్ కోసం షెల్ నుండి నిష్క్రమణ చిరునామాను తిరిగి ఇవ్వండి, తర్వాత పరిమాణం కోసం సర్వర్‌ను చదవండి. మొదటి నాలుగు సరిపోలితే, సొరంగం మీరు అనుకున్నదాన్ని మోస్తోంది మరియు మిగిలిన సమస్య దాని పైన ఉంది. వాటిలో రెండు సరిపోలకపోతే, సరిపోలని జతయే లోపం, చిహ్నం కాదు.