റൗട്ടറിൽ 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 റിഫ്ലെക്ടറിൽ നിന്ന് വ്യത്യസ്ത പ്രോട്ടോക്കോളും പലപ്പോഴും വ്യത്യസ്ത ലക്ഷ്യവും ഉപയോഗിക്കുന്നതുകൊണ്ടാണ്, രണ്ടും തമ്മിലുള്ള വിയോജിപ്പ് സാധാരണയായി ബഗ് അല്ല, റൂട്ടിംഗ് നിയമത്തിലേക്കാണ് സൂചിപ്പിക്കുന്നത്.
നയം തീരുമാനിക്കുക, പിന്നീട് ഉത്തരം വായിക്കുക
പരിശോധനയ്ക്ക് മുമ്പ് ഉദ്ദേശ്യം എഴുതിവയ്ക്കുക: ഏത് ട്രാഫിക് ടണൽ ഉപയോഗിക്കണം, ഏതിന് നേരിട്ട് പുറത്തുപോകാം, ഏത് വിലാസ കുടുംബങ്ങൾ പരിധിയിൽ ഉണ്ട്, ടണൽ തകരുമ്പോൾ എന്ത് സംഭവിക്കണം. ആ അടിസ്ഥാന രേഖ ഇല്ലാതെ ഓരോ നിരീക്ഷണവും അവ്യക്തമാണ്, കാരണം ബോധപൂർവം അനുവദിച്ച പാതയിൽ നിന്ന് ചോർച്ചയെ വേർതിരിക്കാൻ കഴിയില്ല.
പിന്നീട് ഒരു സമയത്ത് ഒരു ചോദ്യം ചോദിക്കുക. ഈ ലക്ഷ്യം ഏത് പാതയാണ് എടുക്കുന്നത്. ഈ റിഫ്ലെക്ടർ ഏത് വിലാസമാണ് റിപ്പോർട്ട് ചെയ്യുന്നത്. സെഷൻ ഏത് സ്ഥാനാർത്ഥി ജോടിയാണ് തിരഞ്ഞെടുത്തത്. ഉത്തരങ്ങൾ നയത്തിനരികിൽ സൂക്ഷിച്ച് തീയതി ചേർക്കുക, കാരണം ഫേംവെയർ അപ്ഡേറ്റ് കഴിഞ്ഞ വർഷത്തെ നിഗമനം നിശബ്ദമായി അസാധുവാക്കുന്ന രീതിയിൽ സ്വതേയുള്ള പെരുമാറ്റം മാറ്റിയേക്കാം.
റൗട്ടർ ഇപ്പോഴും ശക്തമായ നിർവ്വഹണ പോയിന്റാണ്, കാരണം സ്വയം പുനർനിർമ്മിക്കാതെ ക്ലയന്റിന് ഒഴിവാക്കാൻ കഴിയാത്ത ട്രാഫിക് അത് കാണുന്നു. ഓരോ ആപ്ലിക്കേഷൻ പ്രോട്ടോക്കോളിലെ ഓരോ ഫീൽഡും ഒന്നും വെളിപ്പെടുത്തുന്നില്ല എന്ന വാഗ്ദാനമല്ല അത്, അനുവദിക്കാൻ തിരഞ്ഞെടുത്ത പാതകൾ എഴുതിവയ്ക്കുന്നതിന് പകരവുമല്ല.