റൗട്ടറിൽ VPN ഉള്ളപ്പോൾ STUN ഏത് സ്രോതസ്സ് വിലാസമാണ് കാണുന്നത്?
പാത, സ്രോതസ്സ് തിരഞ്ഞെടുപ്പ്, വിവർത്തനം എന്നിവ പ്രതിഫലനി റിപ്പോർട്ട് ചെയ്യുന്ന വിലാസം നിർണ്ണയിക്കുന്നു. എഴുതാൻ മൂന്ന് വസ്തുതകൾ, പിന്നെ ഏത് പാത വിജയിക്കുന്നു എന്ന് ഉറപ്പാക്കാൻ ഒരു ചോദ്യം.
ചോദ്യം ഒരു തിരയലായി തോന്നുന്നു, യഥാർത്ഥത്തിൽ മൂന്ന് തീരുമാനങ്ങളാണ്. binding request ഏത് പാതയിലൂടെ പോകുന്നു, കർണ്ണൽ ആ പാതയ്ക്ക് ഏത് സ്രോതസ്സ് തിരഞ്ഞെടുക്കുന്നു, വഴിയിൽ എന്തെങ്കിലും ആ സ്രോതസ്സ് വീണ്ടും എഴുതുന്നുണ്ടോ. ഇവയിൽ ഏതെങ്കിലും മാറ്റിയാൽ STUN സെർവർ റിപ്പോർട്ട് ചെയ്യുന്ന വിലാസവും അതിനൊപ്പം മാറും. അതുകൊണ്ടാണ് VPN റൗട്ടറിലുണ്ട് എന്ന പ്രസ്താവന സ്വയം ഏതാണ്ട് ഒന്നും പറയാത്തത്.
തീരുമാനം മൂന്ന് വസ്തുതകളിൽ നിൽക്കുന്നു
ആദ്യം പാത: നയ നിയമങ്ങളും റൂട്ടിംഗ് പട്ടികയും അഭ്യർത്ഥന ടണലിലൂടെയോ സാധാരണ WAN-ലൂടെയോ പുറത്തുപോകുന്നു എന്ന് തീരുമാനിക്കുന്നു, ഒഴിവാക്കിയ ലക്ഷ്യസ്ഥാനം ടണൽ സജീവമായിരുന്നാലും രണ്ടാം പാത സ്വീകരിക്കുന്നു. പിന്നെ സ്രോതസ്സ്: കർണ്ണൽ തിരഞ്ഞെടുത്ത പാതയ്ക്ക് ഒരു സ്രോതസ്സ് തിരഞ്ഞെടുക്കുന്നു, ആ തിരഞ്ഞെടുപ്പ് പാതയുടെ മുൻഗണനാ സ്രോതസ്സിനെയും പൊരുത്തപ്പെട്ട ഏതെങ്കിലും നിയമത്തെയും ആശ്രയിച്ചിരിക്കുന്നു. അവസാനം വിവർത്തനം: വഴിയിൽ NAT തിരഞ്ഞെടുത്ത സ്രോതസ്സ് മാറ്റിസ്ഥാപിക്കുന്നു. പ്രതിഫലിത വിലാസം മൂന്നിന്റെയും ഗുണനഫലമാണ്, ടണലിന്റെ സ്വഭാവമല്ല.
മൂന്നിൽ ഒന്ന് മാറ്റിയാൽ ഉത്തരം മാറും, എന്നാൽ ഓരോ ഘടകവും അതിന്റെ സ്വന്തം ലോഗിൽ ഇപ്പോഴും ആരോഗ്യകരമായി കാണപ്പെടുന്നു. ഇതാണ് ഈ രോഗനിർണ്ണയം കുടുങ്ങുന്നതിന്റെ സാധാരണ കാരണം.
തുടങ്ങുന്നതിന് മുമ്പ് നിങ്ങൾ പരീക്ഷിക്കുന്ന പ്രവാഹത്തിന് മൂന്ന് വസ്തുതകൾ എഴുതുക. ഇന്റർഫേസ്, പാത, വിവർത്തന നിയമം എന്നിവ ഫലം പ്രവചിക്കാൻ മതി, ആ പ്രവചനമാണ് ഒരു അത്ഭുതത്തെ വിവരപൂർണ്ണമാക്കുന്നത്. മൂന്നിൽ ഒന്നുപോലും പൂരിപ്പിക്കാൻ കഴിയില്ലെങ്കിൽ, ആ വിടവാണ് യഥാർത്ഥ കണ്ടെത്തൽ.
ഒരു binding request പാതയിലൂടെ പിന്തുടരുക
STUN-ന്റെ binding request ഒരു സെർവറിനോട് നിരീക്ഷിച്ച സ്രോതസ്സ് ഗതാഗത വിലാസം റിപ്പോർട്ട് ചെയ്യാൻ ആവശ്യപ്പെടുന്നു. ഉത്തരം അഭ്യർത്ഥന സ്വീകരിച്ച പാത വിവരിക്കുന്നു, ക്ലയന്റ് യന്ത്രത്തിലെ ഇന്റർഫേസുകളുടെ പട്ടികയല്ല. രണ്ട് പാതകളിലൂടെയുള്ള രണ്ട് അഭ്യർത്ഥനകൾ സത്യസന്ധമായി രണ്ട് വ്യത്യസ്ത വിലാസങ്ങൾ റിപ്പോർട്ട് ചെയ്യും.
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
ഈ പട്ടിക വ്യവസ്ഥകളുടെ കൂട്ടമായി വായിക്കുക, ദാതാക്കളുടെ പട്ടികയായി അല്ല. മധ്യ വരി സ്വകാര്യ പ്രതിഫലനി ടണലിന്റെ സ്വന്തം റൂട്ടിംഗിനും സഹപ്രവർത്തക നയത്തിനും കീഴിൽ എത്താവുന്നതായിരിക്കണം എന്ന് ആവശ്യപ്പെടുന്നു; ഇത് പരിശോധിക്കാവുന്ന കോൺഫിഗറേഷൻ വസ്തുതയാണ്, അക്കൗണ്ട് നില സൂചിപ്പിക്കുന്ന കാര്യമല്ല. താഴെ വരി സാധാരണയായി നയത്തിന് പ്രധാനമാണ്, കാരണം ആ ട്രാഫിക് ടണലിനുള്ളിൽ തന്നെ നിൽക്കേണ്ടതായിരുന്നു. ഇവയ്ക്കിടയിൽ സാധാരണ അവസ്ഥ, അതിൽ പുറത്തേക്കുള്ള ഭാഗം വിവർത്തനം ചെയ്യുന്നു, പ്രതിഫലനി പുറത്തേക്കുള്ള ഭാഗം മാത്രം കാണുന്നു.
ഹോസ്റ്റ് സ്ഥാനാർത്ഥികളും സെർവർ-പ്രതിഫലന സ്ഥാനാർത്ഥികളും വ്യത്യസ്ത സംവിധാനങ്ങളിൽ നിന്ന് വരുന്നു, അതിനാൽ സ്ഥാനാർത്ഥി പട്ടിക മീഡിയ യഥാർത്ഥത്തിൽ ഏത് പാത ഉപയോഗിച്ചു എന്ന് പറയുന്നില്ല. സെഷൻ എവിടേക്ക് പോയി എന്ന് അറിയാൻ തിരഞ്ഞെടുത്ത ജോഡി വായിക്കുക, ശേഖരണ ലോഗ് അല്ല.
റൗട്ടറിന്റെ ടണൽ വിലാസം എന്തല്ല
റൗട്ടറിന് നൽകിയ ടണൽ വിലാസം റൗട്ടറിലെ ഒരു ഇന്റർഫേസിനുള്ളതാണ്. LAN ഹോസ്റ്റിലെ ബ്രൗസറിന് അതിന്റെ സ്വന്തം ഇന്റർഫേസ് വിലാസങ്ങളുണ്ട്, റൗട്ടറിന്റെ ടണൽ ഇന്റർഫേസ് നേരിട്ട് കാണുന്നില്ല. രണ്ടിനെയും പരസ്പരം മാറ്റാവുന്നതായി കണക്കാക്കിയാൽ ഒരു വെബ് പേജിന് എന്ത് പഠിക്കാം എന്നതിനെക്കുറിച്ച് ആത്മവിശ്വാസമുള്ള തെറ്റായ ഉത്തരങ്ങൾ ഉണ്ടാകുന്നു.
ഫോർവേഡിംഗാണ് രണ്ടിനെയും ബന്ധിപ്പിക്കുന്നത്. അഭ്യർത്ഥന റൗട്ടറിലൂടെ റൂട്ട് ചെയ്ത ട്രാഫിക്കായി കടന്നുപോകുന്നു, അതിന്റെ സ്രോതസ്സ് റൂട്ടിംഗും വിവർത്തനവും സൃഷ്ടിച്ചതാണ്.
ടണൽ പാത LAN സ്രോതസ്സ് സംരക്ഷിച്ചാൽ, സ്വകാര്യ പ്രതിഫലനിക്ക് ആ LAN വിലാസം അറിയാം, ഇത് യഥാർത്ഥ വെളിപ്പെടുത്തലാണ്, ടണൽ വിലാസത്തിൽ നിന്ന് വ്യത്യസ്തമാണ്. പാത ടണൽ വിലാസത്തിലേക്ക് വിവർത്തനം ചെയ്താൽ, പ്രതിഫലനി പകരം ടണൽ വിലാസം അറിയുന്നു. രണ്ട് ഫലങ്ങളും ഒരേ ഹോസ്റ്റിലെ ഒരേ ബ്രൗസറുമായി യോജിക്കുന്നു, അതിനാൽ നിരീക്ഷണം ഒരു നിർദ്ദിഷ്ട പ്രവാഹവുമായി ബന്ധിപ്പിക്കണം. അപ്ലിക്കേഷനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് കർണ്ണലിനോട് ഏത് സ്രോതസ്സ് ഉപയോഗിക്കും എന്ന് ചോദിക്കുക.
വെളിപ്പെടുത്തൽ വേഴ്സസ് ബൈപാസ്: രണ്ട് കണ്ടെത്തലുകൾ, രണ്ട് അറ്റകുറ്റപ്പണികൾ
പ്രതിഫലിത ടണൽ വിലാസം നിങ്ങൾ അനുവദിച്ച പാതയിൽ ആന്തരിക ഐഡന്റിഫയർ വെളിപ്പെടുത്തുന്നു. WAN-ലൂടെയുള്ള നേരിട്ടുള്ള അഭ്യർത്ഥന നിങ്ങൾ ആവശ്യപ്പെടാൻ ഉദ്ദേശിച്ച പാതയെ ബൈപാസ് ചെയ്യുന്നു. ആദ്യത്തേത് വിവരത്തിന്റെ ചോദ്യമാണ്, രണ്ടാമത്തേത് നിർവ്വഹണത്തിന്റെ, രണ്ടും വ്യത്യസ്ത സ്ഥലങ്ങളിൽ തിരുത്തപ്പെടുന്നു. രണ്ടിനെയും ഒരു വാക്കിൽ ചേർത്താൽ ഒന്നിനെയും പരിഹരിക്കാത്ത അറ്റകുറ്റപ്പണി ഉണ്ടാകുന്നു.
WebRTC ഇത് തെറ്റാക്കാതെ കൂടുതൽ ദൃശ്യമാക്കുന്നു, കാരണം സ്ഥാനാർത്ഥിയെ ശേഖരിക്കുന്നത് അത് തിരഞ്ഞെടുക്കുന്നതിന് തുല്യമല്ല.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showനിങ്ങൾ അനുവദിക്കുന്ന ഓരോ പ്രതിഫലനി വിലാസത്തിനും പാത ചോദ്യം ഈ പ്രവാഹം വഹിക്കും എന്ന് നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന സ്രോതസ്സിനൊപ്പം പ്രവർത്തിപ്പിക്കുക, പിന്നെ ഒഴിവാക്കിയ ശ്രേണികൾക്കായി വീണ്ടും പ്രവർത്തിപ്പിച്ച് ബദൽ എന്ത് തിരഞ്ഞെടുക്കുന്നു എന്ന് കാണുക. രണ്ട് ഉത്തരങ്ങളും നിങ്ങൾ എഴുതിയ നയവുമായി താരതമ്യം ചെയ്യുക. അവ നിങ്ങൾ ഉദ്ദേശിക്കാത്ത രീതിയിൽ വ്യത്യാസപ്പെട്ടാൽ, ബ്രൗസറിന്റെ സ്ഥാനാർത്ഥി പട്ടിക വ്യാഖ്യാനിക്കേണ്ടതില്ലാതെ തന്നെ അറ്റകുറ്റപ്പണിയുടെ ബിന്ദു കണ്ടെത്തി.