શું ટ્રાફિક ખરેખર 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 કેપ્ચર કરો, ચોક્કસ એપ્લિકેશન માટે શેલમાંથી એક્ઝિટ સરનામું પરત મેળવો, પછી વોલ્યુમ માટે સર્વર વાંચો. જો પ્રથમ ચાર મળે, તો ટનલ તમે જે માનો છો તે વહન કરે છે અને બાકીની સમસ્યા તેની ઉપર છે. જો તેમાંથી બે ન મળે, તો અસંમત જોડી જ ખામી છે, આયકન નહીં.