શા માટે એક સબનેટ હજુ પણ તમારા VPN ડિફોલ્ટ રૂટને બાયપાસ કરે છે
પૂર્ણ ટનલ હેઠળ એક સબનેટ સીધું જાય તો સામાન્ય રીતે લાંબો પ્રિફિક્સ જીતે છે, લીક નહીં. અડધા-ડિફોલ્ટ, નીતિ નિયમો અને પ્રોફાઇલ અપવાદો તપાસો.
તમે VPN ને પૂર્ણ ટનલમાં બદલો છો, મોટાભાગનો ટ્રાફિક આજ્ઞા પાળે છે, અને પછી એક સરનામું સીધું જવાબ આપે છે — એક પ્રિન્ટર, NAS, 10.x પરનો જમ્પ હોસ્ટ. સ્પષ્ટ વાચન એ છે કે ટનલ લીક થાય છે, તેથી તમે ડિફોલ્ટ રૂટ પરનું મેટ્રિક ઘટાડો છો અને કંઈ બદલાતું નથી. એ નિષ્ફળ પ્રયાસ જ સૂત્ર છે: ડિફોલ્ટ રૂટ એ બેકઅપ છે, ચુકાદો નહીં. રૂટ શોધ મેટ્રિકની સરખામણી કરતાં પહેલાં જ સૌથી લાંબું મેળ ખાતું પ્રિફિક્સ લે છે, તેથી /24 એ /0 સામે જીતવાનું ચાલુ રાખે છે, ભલે તમે બંનેમાંથી કોઈપણ પર કોઈ પણ આંકડો લગાવો. એ ક્રમ સ્પષ્ટ થયા પછી, લીક સામાન્ય રીતે કોઈએ જાણી જોઈને સ્થાપેલો રૂટ હોય છે, અથવા એવું પ્રિફિક્સ જે ક્લાયન્ટે કદી આવરી લેવાનું વિચાર્યું ન હતું.
ડિફોલ્ટ રૂટ ખરેખર શું વચન આપે છે
0.0.0.0/0 દરેક IPv4 ગંતવ્ય સાથે શૂન્ય બિટ વિશિષ્ટતા સાથે મેળ ખાય છે. તે એટલા માટે છે કે હોસ્ટ પોતાના ટેબલ કરતાં વધુ સારી રીતે વર્ણવે નહીં તેવી કોઈપણ વસ્તુ સુધી પહોંચી શકે. 192.168.1.0/24 તરફનો રૂટ 24 મેળ ખાતા બિટ ધરાવે છે, તેથી 192.168.1.40 માટે તે કોઈ મેટ્રિક, વહીવટી અંતર અથવા ક્લાયન્ટ તેના પ્રાયોરિટી ક્ષેત્રને જે પણ કહે તેની સરખામણી કરે તે પહેલાં જીતે છે. એ જ નિયમ Linux FIB, Windows રૂટિંગ ટેબલ અને macOS પાછળના BSD સ્ટેકમાં લાગુ પડે છે.
સામાન્ય LAN માં એ વર્તન એક લક્ષણ છે. સ્થાનિક સબનેટ સીધું જોડાયેલું છે, ટનલ તમારું બ્રાઉઝિંગ લઈ જાય ત્યારે પ્રિન્ટર કામ કરતું રહે છે, અને કંઈ ખોટું ગોઠવાયેલું નથી. પૂછવા લાયક પ્રશ્ન એ નથી કે એ સરનામું સીધું કેમ જાય છે, પણ એ છે કે કયા ટેબલમાં કયું પ્રિફિક્સ તેની સાથે મેળ ખાય છે, અને તેને ત્યાં કોણે મૂક્યું.
અડધા-ડિફોલ્ટ, અથવા ડિફોલ્ટ એન્ટ્રી અસ્પૃષ્ટ કેમ દેખાઈ શકે
સૌથી સ્વચ્છ ઉદાહરણ redirect-gateway def1 OpenVPN માં છે. તમારો ડિફોલ્ટ ડિલીટ કરીને બદલવાને બદલે, તે 0.0.0.0/1 અને 128.0.0.0/1 ઉમેરે છે. સાથે મળીને જોડી આખું IPv4 આવરી લે છે, દરેક પ્રિફિક્સ /0 કરતાં લાંબું છે, અને બંને રાઉટરના ડિફોલ્ટને તેની જગ્યાએ રાખીને તેને હરાવે છે. પછી રૂટ લિસ્ટિંગ ચલાવો અને મૂળ ડિફોલ્ટ હજુ ત્યાં છે, હજુ તમારા ગેટવે તરફ ઇશારો કરે છે; ફક્ત તે ઇન્ટરનેટ ગંતવ્યો માટે કદી પસંદ થતું નથી.
WireGuard નું wg-quick નીતિ આધારિત રૂટિંગ દ્વારા એ જ પરિણામ સુધી પહોંચે છે. AllowedIPs 0.0.0.0/0 આવરી લે ત્યારે તે પોતાનું ટેબલ બનાવે છે, ચિહ્નિત પેકેટ ત્યાં મોકલે છે, અને એવો નિયમ ઉમેરે છે જે મુખ્ય ટેબલના શૂન્ય લંબાઈના પ્રિફિક્સને અવગણે છે. મુખ્ય ટેબલ તેની ડિફોલ્ટ એન્ટ્રી રાખે છે, અને નિયમો નક્કી કરે છે કે ઇન્ટરફેસ ધરાવતા ટ્રાફિક માટે પહેલા ટનલ ટેબલની સલાહ લેવાય છે.
બંને ડિઝાઇનને ટનલની બહાર બરાબર એક રૂટની જરૂર છે: મૂળ ગેટવે દ્વારા VPN સર્વરના પોતાના સરનામા સુધીનો હોસ્ટ રૂટ. તેના વિના ક્લાયન્ટ ટનલ બનાવતા પેકેટને ટનલની અંદર લઈ જવાનો પ્રયાસ કરશે, અને કનેક્શન કદી પૂર્ણ નહીં થાય. તેથી તમારા ટેબલમાં ટનલ-રહિત રૂટ કડક પૂર્ણ-ટનલ પ્રોફાઇલમાં પણ સામાન્ય છે. પ્રશ્ન કરવા લાયક રૂટ એ છે જે તમને ખરેખર મહત્વના ગંતવ્યોને આવરી લે છે.
મેટ્રિક ટાઈ નક્કી કરે છે, પ્રિફિક્સ વિજેતા નક્કી કરે છે
મેટ્રિકની સરખામણી ફક્ત એવા ઉમેદવારો વચ્ચે થાય છે જે ગંતવ્ય સાથે સમાન રીતે મેળ ખાય છે. Linux પર, ip route get 10.20.5.9 વિજેતાને તેના ટેબલ સાથે પ્રિન્ટ કરે છે, અને ip route show table all ઉમેદવારોની સૂચિ આપે છે, જેમાં કોઈપણ અડધા-ડિફોલ્ટ અને નિયમ જે ટેબલ તરફ ઇશારો કરે તેનો સમાવેશ થાય છે. Windows પર, Find-NetRoute -RemoteIPAddress 10.20.5.9 પસંદ કરેલ રૂટ અને સ્રોત સરનામું પરત કરે છે, જ્યારે Get-NetRoute કાચું ટેબલ બતાવે છે — પરંતુ અસરકારક ખર્ચ રૂટ મેટ્રિક ઉપરાંત ઇન્ટરફેસ મેટ્રિક છે, તેથી ધીમું એડેપ્ટર જીતતું દેખાતું ટાઈ ગુમાવી શકે છે.
તમે જે જોશો તેમાંથી મોટાભાગના ત્રણ કિસ્સાઓ આવરી લે છે:
- એ જ ગંતવ્ય, /24 સામે /0: પ્રિફિક્સ લંબાઈ પર /24 જીતે છે, મેટ્રિક ભલે ગમે તે કહે.
- એ જ ગંતવ્ય, જુદા જુદા મેટ્રિક સાથે બે /24: નીચું અસરકારક મેટ્રિક જીતે છે.
- એ જ ગંતવ્ય, બે ટેબલ, એક નીતિ નિયમ દ્વારા પસંદ: નિયમ પહેલા ટેબલ પસંદ કરે છે, અને પ્રિફિક્સ સરખામણી તેની અંદર થાય છે.
ત્રીજો કિસ્સો એ છે જ્યાં આમાંનો મોટાભાગનો અહેવાલ પૂરો થાય છે. Linux નું ip rule અથવા Windows VPN ટ્રાફિક ફિલ્ટર ટ્રાફિકને એવા ટેબલમાં મોકલી શકે છે જ્યાં કદી ટનલ ડિફોલ્ટ ન હતું, અને મુખ્ય ટેબલ આખો સમય સંપૂર્ણ દેખાય છે.
સામાન્ય રીતે આ બાયપાસનો માલિક કોણ હોય
ટેબલથી નહીં, પ્રોફાઇલથી શરૂ કરો. Split-tunnel રૂપરેખાંકનો અને એપ દીઠ VPN સેટિંગ્સ જાણી જોઈને નામવાળા પ્રિફિક્સને ટનલની બહાર રાખે છે; એક ખાનગી સબનેટનું રક્ષણ કરતું અને સામાન્ય બ્રાઉઝિંગને સીધું જવા દેતું કાર્ય પ્રોફાઇલ ડિઝાઇન પ્રમાણે વર્તે છે, અને તેને ઓવરરાઇડ કરવાથી તે જે નીતિ લાગુ કરવા બન્યું હતું તે તૂટે છે. Microsoft ની VPN રૂટિંગ માર્ગદર્શિકા ફરજિયાત ટનલ ટ્રાફિક અને સ્પષ્ટ અપવાદો વચ્ચે એ જ રેખા દોરે છે, જે કંઈપણ સંપાદિત કરતાં પહેલાં તેને ઉપયોગી ક્રોસ-ચેક બનાવે છે.
પછી બાકી રહેલ વસ્તુઓ શોધો. એવા ઇન્ટરફેસ તરફ ઇશારો કરતો રૂટ જે હવે નથી, અથવા અગાઉના નેટવર્કના સરનામા તરફ, ડોકિંગ સ્ટેશન, USB એડેપ્ટર અને કન્ટેનર બ્રિજ આવ-જા કર્યા પછી દેખાય છે. તેને એક વાર ડિલીટ કરવું અંત નથી: NetworkManager કનેક્શન પ્રોફાઇલ, netplan ફાઇલો અને Windows ના કાયમી રૂટ આગલી કનેક્શન અથવા બૂટ પર તેને ફરી ઇન્સ્ટોલ કરે છે, તેથી કંઈપણ સંપાદિત કરતાં પહેલાં તેનો માલિક એવી ફાઇલ કે પ્રોફાઇલ શોધો.
પછી IPv6 અલગથી તપાસો. ip -6 route અને Get-NetRoute -AddressFamily IPv6 અલગ સ્થિતિ, અલગ ડિફોલ્ટ અને અલગ ક્લાયન્ટ વર્તન ધરાવે છે. ફક્ત IPv4 નું ઓડિટ ડ્યુઅલ-સ્ટેક હોસ્ટ વિશે કંઈ કહેતું નથી જે શાંતિથી મૂળ IPv6 માર્ગને પ્રાધાન્ય આપે છે, અને એકલું તે ક્લાયન્ટને split-tunnel જેવું દેખાડી શકે છે.
એપ્લિકેશનના પોતાના પ્રવાહ સાથે પુષ્ટિ કરો
એપ્લિકેશન ખરેખર જે ગંતવ્ય વાપરે છે તે નોંધો, પછી સિસ્ટમને પૂછો કે તે એપ્લિકેશન જે સ્રોત સરનામું બાંધે છે ત્યાંથી કયો માર્ગ લેશે. ip route get 10.20.5.9 from 192.168.1.40 Linux પર તેનો જવાબ આપે છે; Find-NetRoute -RemoteIPAddress 10.20.5.9 વત્તા સ્થાનિક સરનામું Windows પર તે કરે છે. પરિણામને પ્રોફાઇલ જે દાવો કરે છે તેની સાથે સરખાવો. બ્રાઉઝરનું જાહેર-IP પૃષ્ઠ એક પ્રોટોકોલ પર એક ગંતવ્ય ચકાસે છે અને ફરિયાદ શરૂ કરનારા ખાનગી સરનામા વિશે કંઈ કહેતું નથી.
ફરક સમજાવતી સૌથી સાંકડી વસ્તુ સુધારો. જો અપવાદ મંજૂર હોય, તો પ્રિફિક્સ લખી લો અને તેને રહેવા દો; જો ન હોય, તો રૂટ દૂર કરો અથવા ડિફોલ્ટનું મેટ્રિક ઘટાડવાને બદલે ટનલ દ્વારા સ્પષ્ટ સાંકડો રૂટ ઉમેરો. મેટ્રિક ઘટાડવાથી લાંબા પ્રિફિક્સને પાછળ નાખી શકાતું નથી, અને બે /1 રૂટ ઇન્ટરનેટ માર્ગના માલિક હોય ત્યારે ડિફોલ્ટ સંપાદિત કરવાથી પણ કંઈ બદલાતું નથી.
પછી ટનલ ફરી જોડો અને એ જ ક્વેરી ફરીથી કરો. ક્લાયન્ટ દરેક કનેક્શન પર રૂટ ફરી ઇન્સ્ટોલ કરે છે, તેથી ફક્ત આગલા હેન્ડશેક સુધી ટકતો ફેરફાર ચકાસાયેલો નથી. જો માર્ગ હજુ પણ અલગ પડે, તો બાકીના શંકાસ્પદો નીતિ નિયમ, બીજું ટેબલ કે ક્લાયન્ટ-બાજુનું ફિલ્ટર છે — ડિફોલ્ટ રૂટ નહીં.
- એપ ખરેખર જે ગંતવ્ય અને સ્રોત સરનામું વાપરે છે તેના નામ આપો.
- જીતતો રૂટ
ip route getઅથવાFind-NetRouteવડે પ્રિન્ટ કરો. - ઇન્ટરનેટ માર્ગનો માલિક /1 જોડી છે કે નીતિ ટેબલ, તે તપાસો.
- /0 કરતાં લાંબું અને ગંતવ્ય સાથે મેળ ખાતું દરેક પ્રિફિક્સ સૂચિબદ્ધ કરો.
- IPv6 તપાસ અલગથી ફરીથી કરો.
- ટકી રહેલા રૂટને તેને ઇન્સ્ટોલ કરતી ફાઇલ, પ્રોફાઇલ કે ફિલ્ટર સુધી ટ્રેસ કરો.
- સુધરેલું કહેતાં પહેલાં ફરી જોડાઈને ક્વેરી ફરી ચલાવો.
જો સાતેય પ્રોફાઇલ સાથે સંમત હોય, તો ટનલ બરાબર એ જ કરે છે જે માટે તેને ગોઠવવામાં આવી હતી, અને સુધારો મેટ્રિકમાં નહીં, પ્રોફાઇલમાં આવે છે.