રાઉટર પર VPN ચાલે ત્યારે STUN જવાબ શું ખુલાસો કરે છે
રાઉટરનું ટનલ સરનામું બ્રાઉઝરનું સ્થાનિક સરનામું નથી. રિફ્લેક્ટર શું જણાવે છે તે વાંચતા પહેલાં દરેક વિનંતી કેવી રીતે રૂટ અને અનુવાદિત થાય છે તે અનુસરો.
જ્યારે ટનલ રાઉટર પર રહે છે, ત્યારે બ્રાઉઝર ચલાવતા મશીનમાં કોઈ ટનલ ઇન્ટરફેસ હોતું જ નથી. તે મશીનને તેનાં સ્થાનિક સરનામાં પૂછો અને તમને ખાનગી LAN સરનામું અને લૂપબેક મળે, VPN સરનામા જેવું કંઈ નહીં. તોપણ બીજી બાજુનું STUN સર્વર હજી પણ માર્ગ વિશે કંઈક અર્થપૂર્ણ જણાવી શકે છે, અને તે શું જણાવે છે તે સંપૂર્ણપણે એના પર આધાર રાખે છે કે તે ચોક્કસ વિનંતી કેવી રીતે રૂટ થઈ અને અનુવાદિત થઈ.
આ એ ભાગ છે જેના પર ધીમે થવા જેવું છે. “બ્રાઉઝર VPN સરનામાનું માલિક નથી” એ ઇન્ટરફેસ વિશેના પ્રશ્નનો જવાબ આપે છે, જ્યારે પ્રતિબિંબિત સરનામું અનુવાદમાંથી પસાર થતા માર્ગ વિશેનો જવાબ છે. બંનેને ભેળવવાથી જાહેરાત વિશે આત્મવિશ્વાસપૂર્ણ નિષ્કર્ષ નીકળે છે જે પુરાવા ટેકો આપતા નથી.
બે ઉપકરણો, ઇન્ટરફેસની બે શ્રેણીઓ
રાઉટર-આધારિત ગોઠવણમાં ટનલ રાઉટર પર પૂરી થાય છે અને LAN ક્લાયન્ટ સામાન્ય ટ્રાફિક તેના ડિફોલ્ટ ગેટવે પર મોકલે છે. ક્લાયન્ટની ઇન્ટરફેસ યાદી ટૂંકી જ રહે છે: એક ખાનગી સરનામું, કદાચ બીજા નેટવર્ક માટે બીજું, અને લૂપબેક. જોખમ એ નથી કે તેમાંથી એક કદાચ ટનલ સરનામું હોય; જોખમ એ છે કે વિનંતી એવા માર્ગે નીકળે જે તમે પસંદ ન કર્યો હોય.
ક્લાયન્ટને પૂછો ચોક્કસ લક્ષ્ય કયો માર્ગ લેશે, એ પૂછવાને બદલે કે કયા ઇન્ટરફેસ અસ્તિત્વમાં છે. જવાબ એક ગેટવે અને કર્નલ જે સ્રોત સરનામું વાપરશે તેનું નામ આપે છે, જે કોઈપણ સરનામાંની યાદી કરતાં વધુ જાણકારીપૂર્ણ છે.
ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips
દસ્તાવેજીકરણ શ્રેણીઓ પરીક્ષણ માટે સારાં લક્ષ્યો છે કારણ કે તે ક્યારેય વાસ્તવિક સેવામાં ઉકેલાતાં નથી. ક્લાયન્ટ શું કહે છે તેની રાઉટર શું કહે છે તેની સાથે સરખામણી કરો, અને કોઈપણ અસંતુલનને એ પુરાવા તરીકે લો કે નીતિ રૂટિંગ, સ્પ્લિટ-ટનલ નિયમ કે બીજું ડિફોલ્ટ રૂટ એવું કંઈક કરી રહ્યું છે જે તમે ધ્યાનમાં લીધું નથી.
Binding જવાબ શું કહી શકે
RFC 8489 Binding વિનંતી અને પ્રતિસાદ વ્યાખ્યાયિત કરે છે, જેમાં સર્વર તે વિનંતી માટે જોયેલું સ્રોત પરિવહન સરનામું જણાવે છે. તે એક ક્ષણે એક પંચક વિશેનું નિવેદન છે, ક્લાયન્ટના ઇન્ટરફેસની ગણતરી નહીં. તેથી રસપ્રદ બધું ક્લાયન્ટ અને અવલોકન બિંદુ વચ્ચે જ બને છે.
તે અંતર રૂટિંગ અને અનુવાદ ભરે છે. જે રાઉટર બહાર જતા ટ્રાફિક પર સ્રોત NAT કરે છે તે ક્લાયન્ટના ખાનગી સ્રોતને બહાર જતા ઇન્ટરફેસ પર તેના પોતાના સરનામાથી બદલે છે. જો તે ઇન્ટરફેસ ટનલ હોય, તો રિફ્લેક્ટર ટનલ સરનામું જુએ છે. જો પેકેટ ટનલમાંથી બહાર રાખવામાં આવ્યું હોય, તો રિફ્લેક્ટર WAN અનુવાદે જે ઉત્પન્ન કર્યું તે જુએ છે. એક જ ક્લાયન્ટ, એક જ રિફ્લેક્ટર, અલગ જવાબ.
એકસરખા દેખાતા પણ ન હોય એવા ત્રણ કિસ્સા
ઉપયોગી ભેદ જાહેર વિરુદ્ધ ખાનગી નથી, પણ એ છે કે કયા અમલબિંદુએ પેકેટ સંભાળ્યું. રાઉટરની પોતાની કોષ્ટકો ખુલ્લી રાખીને કિસ્સા કરો, કારણ કે એક જ બ્રાઉઝર ત્રણેય પેદા કરી શકે છે, તમે લખવાનું ભૂલી ગયેલા નિયમ પ્રમાણે.
| Where the request leaves | What rewrites the source | What the reflector reports |
|---|---|---|
| Tunnel interface on the router | Router NAT towards the tunnel address | The tunnel address as seen on that path |
| WAN interface, excluded by policy | Ordinary WAN translation | The public WAN address |
| Private reflector reached through the tunnel route | Router NAT towards the tunnel address | An internal identifier valid only inside that path |
ફક્ત બીજો કિસ્સો જ એ શરત તોડે છે કે અમુક ટ્રાફિક ક્યારેય સીધો ન નીકળે, અને ફક્ત પહેલો અને ત્રીજો જ ટનલ બાજુનું ઓળખકર્તા જાહેર કરે છે. ત્રણમાંથી કોઈ પણ હરોળ ચોક્કસ પ્રદાતાના વર્તન વિશે દાવો નથી: ખાનગી રિફ્લેક્ટર સુધી પહોંચી શકાય છે કે નહીં તે રૂટિંગ, સામેની બાજુના માન્ય IP સરનામાં અને બંને છેડેની ફાયરવોલ નીતિ પર આધાર રાખે છે.
એ જ પ્રદાતા પાસે ખાતું હોવાથી એમાંથી કંઈ સાબિત થતું નથી. એ પણ યાદ રાખવા જેવું છે કે રૂટ થયેલી વિનંતી ક્લાયન્ટનું LAN સ્રોત જાળવી શકે છે જો કંઈ તેનું અનુવાદ ન કરે, તેથી સ્રોત ક્ષેત્ર ટોપોલોજી આકૃતિ પરથી ધારવાને બદલે શોધવું પડે.
એકઠું કરવું એ પસંદ કરવું નથી
WebRTC પ્રયત્ન માટે ઉમેદવાર સરનામાં એકઠાં કરે છે, અને નિદાન યાદીમાં દેખાતો ઉમેદવાર ક્યારેય મીડિયા ન પણ વહન કરે. યાદીને “સામેની બાજુએ આ શીખ્યું” તરીકે વાંચવું પુરાવાને વધારે પડતો મહત્ત્વ આપે છે. પસંદ કરેલી જોડી જ તે છે જેણે ખરેખર સત્ર વહન કર્યું, અને તે બીજા ક્ષેત્રમાં રહે છે.
HTTPS એક્ઝિટ ચેકર બીજા પ્રશ્નનો જવાબ આપે છે: વેબ સર્વરે તે વિનંતી માટે જોયેલું સ્રોત સરનામું. તે ઉપયોગી ક્રોસ-ચેક છે કારણ કે તે UDP રિફ્લેક્ટર કરતાં અલગ પ્રોટોકોલ અને ઘણી વાર અલગ લક્ષ્ય વાપરે છે, અને બંને વચ્ચેનું અસંતુલન સામાન્ય રીતે બગ નહીં પણ રૂટિંગ નિયમ તરફ ઇશારો કરે છે.
નીતિ નક્કી કરો, પછી જવાબ વાંચો
પરીક્ષણ પહેલાં ઉદ્દેશ લખો: કયો ટ્રાફિક ટનલ વાપરવો જોઈએ, કયો સીધો નીકળી શકે, કયા સરનામા-કુટુંબો અવકાશમાં છે, અને ટનલ બંધ હોય ત્યારે શું થવું જોઈએ. તે આધારરેખા વિના દરેક અવલોકન અસ્પષ્ટ છે, કારણ કે તમે ઇરાદાપૂર્વક મંજૂર કરેલા માર્ગથી લીકને અલગ કરી શકતા નથી.
પછી એક વખતે એક પ્રશ્ન પૂછો. આ લક્ષ્ય કયો માર્ગ લે છે. આ રિફ્લેક્ટર કયું સરનામું જણાવે છે. સત્રે કઈ ઉમેદવાર જોડી પસંદ કરી. જવાબો નીતિની બાજુમાં રાખો અને તારીખ નાખો, કારણ કે ફર્મવેર અપડેટ ડિફોલ્ટ વર્તન એવી રીતે બદલી શકે જે ગયા વર્ષના નિષ્કર્ષને શાંતિથી અમાન્ય બનાવે.
રાઉટર હજી પણ મજબૂત અમલબિંદુ છે, કારણ કે તે એવો ટ્રાફિક જુએ છે જે ક્લાયન્ટ પોતાને ફરી ગોઠવ્યા વિના ટાળી શકતો નથી. તે એ વચન નથી કે દરેક એપ્લિકેશન પ્રોટોકોલનું દરેક ક્ષેત્ર કંઈ જાહેર કરતું નથી, અને તમે મંજૂર કરવાનું પસંદ કરેલા માર્ગો લખવાનો તે વિકલ્પ પણ નથી.