લીલું આઇકન, એ જ જાહેર IP: VPNએ કયો રૂટ છોડ્યો

કનેક્ટેડ, લીલું ટ્રે આઇકન, અને સરનામું પ્રતિબિંબિત કરતું પૃષ્ઠ હજી પણ પ્રદાતાનું સરનામું બતાવે છે, તેનો અર્થ આપોઆપ ખામી નથી. ક્લાયન્ટ બે અલગ કામ કરે છે: તે ટનલ બનાવે છે, અને તે રૂટિંગ કોષ્ટક સંપાદિત કરે છે. દરેક બીજા વિના થઈ શકે છે, અને પસંદગીનું રૂટિંગ એ રૂપરેખાંકન છે જેમાં બીજું જાણી જોઈને છોડી દેવાય છે.

ક્લાયન્ટે ખરેખર શું સ્થાપિત કર્યું

ટનલ ઉપર છે કે નહીં તે પૂછવાને બદલે પૂછો કે કઈ ઇન્ટરફેસ પેકેટને વાસ્તવિક ગંતવ્ય સુધી લઈ જશે. તે ગંતવ્ય માટે રૂટ વગરની ટનલ એ ખાનગી રસ્તો છે જેનો કોઈ ઉપયોગ કરતું નથી.

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

પ્રથમ આદેશ Linux અને macOS પર જવાબ આપે છે, અને બાકીના બે Windowsના સમકક્ષ છે જ્યાં એક પૂરતો છે. જો જવાબ ભૌતિક એડાપ્ટરનું નામ આપે, તો ટનલ ઉપર છે અને ડિફોલ્ટ રૂટ કદી ખસ્યો નથી. જે ગંતવ્યે ટનલ વાપરવી જોઈએ તેના માટે ચકાસણી પુનરાવર્તિત કરો, કારણ કે બે ચકાસણી, એક દૂરની અને એક સામાન્ય, કહે છે કે કઈ રચના લાગુ છે.

પસંદગીના રૂટિંગના ત્રણ સ્વરૂપ

પૂર્ણ ટનલ પ્રોફાઇલ સામાન્ય રીતે ઇન્ટરફેસ તરફનો ડિફોલ્ટ રૂટ લખે છે, અથવા અડધા-શ્રેણીના ઉપસર્ગની જોડી લખે છે જે ઉપસર્ગ લંબાઈએ જીતે છે જ્યારે મૂળ ડિફોલ્ટ કોષ્ટકમાં રહે છે. પસંદગીનું રૂટિંગ બીજો વિકલ્પ છે, અને તે ઘણા સ્વરૂપોમાં આવે છે. એક પ્રોફાઇલ RDP સર્વર જેવા એક જ યજમાનને રૂટ કરે છે, બીજું જાહેર શ્રેણીને રૂટ કરે છે જ્યાં ચોક્કસ સ્થળેથી પહોંચવું પડે, અને ત્રીજું એક એપ્લિકેશનને જાણી જોઈને બાકાત રાખે છે. ત્રણેય વૈધ છે, અને એક પણ સામાન્ય વેબસાઇટ જે સરનામું જુએ છે તેને બદલતું નથી.

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

જે નિર્દેશ નક્કી કરે તે માટે પ્રોફાઇલ વાંચો, પછી તે શું ઉત્પન્ન કર્યું તે માટે કોષ્ટક વાંચો. ધકેલાયેલ નિર્દેશ ક્લાયન્ટ પર દબાવી પણ શકાય, તેથી સર્વરને દોષ આપતાં પહેલાં પ્રોફાઇલ અને કોષ્ટક મળવા જોઈએ.

સામેની બાજુએ સ્રોત સરનામું ફરી લખવું પડશે

બીજી નિષ્ફળતા છે જે બ્રાઉઝરથી એકસરખી લાગે છે. રૂટ ટનલમાં જાય છે, સર્વર પેકેટ મેળવે છે અને પછી તેમને ક્લાયન્ટના ખાનગી સરનામા સાથે અકબંધ ફોરવર્ડ કરે છે. આગલા હોપ પાસે તે સરનામા માટે પરત માર્ગ નથી, તેથી જવાબો અદૃશ્ય થાય છે અને પૃષ્ઠો લટકે છે. સર્વરે બિલકુલ ફોરવર્ડ કરવું પડે, અને સ્રોતને એવી વસ્તુમાં અનુવાદિત કરવો પડે જે ઇન્ટરનેટ પાછું રૂટ કરી શકે.

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

જે ઇન્ટરફેસ ખરેખર ઇન્ટરનેટ તરફ જુએ છે તેનું નામ આપો, જે આધુનિક ડિસ્ટ્રિબ્યુશનમાં હંમેશા eth0 નથી. સ્થિર સરનામા સાથેનો હોસ્ટેડ સર્વર masquerade વાપરવાને બદલે સીધું તે સરનામે અનુવાદ કરી શકે છે. બંને અર્ધ ફાયદો કરે છે, કારણ કે અનુવાદ વગરનું ફોરવર્ડિંગ રૂટ ન થઈ શકે તેવા સ્રોત લીક કરે છે, જ્યારે ફોરવર્ડિંગ વગરનું અનુવાદ પેકેટ કદી જોતું નથી.

નામ ઉકેલ સ્વતંત્ર માર્ગ લે છે

ટ્રાફિક ટનલ દ્વારા બહાર જઈ શકે છે જ્યારે નામ શોધનાર ચકાસણી સ્થાનિક નેટવર્કના રિઝોલ્વર પર ગઈ હોય. દૃશ્યમાન સરનામું એ જ રહે છે, પ્રશ્નો નહીં, અને તે જ અંતર છે જે વિભાજિત DNS રચના પસંદ કરે છે.

resolvectl status | head -20
resolvectl query example.org

નોંધો કે કયા સર્વરે જવાબ આપ્યો અને તે ટનલ પહેલાંના આધારરેખાથી અલગ છે કે નહીં. વિભાજિત ટનલમાં આ સામાન્ય રીતે તે સેટિંગ હોય છે જે લોકો સરનામા વિશે ફરિયાદ કરતી વખતે બદલવા માગતા હતા, અને તે જ જે તેઓએ કદી જોયું નહીં.

ચાર અવલોકન જે બાબત નક્કી કરે છે

ટનલ બંધ હોય ત્યારે એક્ઝિટ સરનામું કેપ્ચર કરો, પછી ચાલુ હોય ત્યારે. બંને સ્થિતિમાં ગંતવ્ય ચકાસણી ચલાવો અને દર વખતે ઇન્ટરફેસ નોંધો.

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

જ્યારે ચકાસણી ટનલની અંદર પડે અને પ્રતિબિંબ હજી પ્રદાતાનું સરનામું બતાવે, ત્યારે એક્ઝિટ પર અનુવાદ ખૂટે છે. જ્યારે ચકાસણી ભૌતિક એડાપ્ટર પર પડે, ત્યારે પ્રોફાઇલ પસંદગીનું છે અને જાહેર સરનામું કદી દાયરામાં નહોતું. તમે વિશ્વાસ કરો તેવી પ્રતિબિંબ સેવા સાથે બદલો અને ચાર અવલોકન સાથે નોંધો, કારણ કે અલગ અલગ તે કિસ્સાઓ છે. સાથે તેઓ ઓળખે છે કે ક્લાયન્ટે બેમાંથી કયું કામ ખરેખર કર્યું.