VPN ഒഴുക്കിൽ ക്ലയന്റിന്റെ ഉറവിട പോർട്ടും സെർവറിന്റെ ശ്രവണ പോർട്ടും
ഒരു ടണലിലെ രണ്ട് പോർട്ട് നമ്പറുകൾ താരതമ്യം ചെയ്യുക: സെർവറിന്റെ സ്ഥിരമായ ശ്രവണവും ക്ലയന്റിന്റെ താൽക്കാലിക ഉറവിടവും, അവയ്ക്കിടയിൽ റൗട്ടറിന്റെ വിവർത്തനം എവിടെ നിൽക്കുന്നു.
ഒരേ സംഭാഷണത്തിൽ രണ്ട് സംഖ്യകൾ പ്രത്യക്ഷപ്പെടുന്നു, രണ്ടും തെറ്റല്ല. സേവനം നൽകുന്ന ശ്രവണം സെർവർ ലോഗ് കാണിക്കുന്നു, ഡാറ്റാഗ്രാം അയച്ച സോക്കറ്റ് ലാപ്ടോപ്പ് കാണിക്കുന്നു, ഇടയിലുള്ള റൗട്ടർ പുറത്തേക്ക് പോകുമ്പോൾ രണ്ടാമത്തേത് വീണ്ടും എഴുതാം. അക്കങ്ങൾ താരതമ്യം ചെയ്യുന്നതിനേക്കാൾ സംഭാഷണത്തിന്റെ രണ്ട് അറ്റങ്ങൾ താരതമ്യം ചെയ്യുന്നതാണ് ഉപയോഗപ്രദം. താഴെയുള്ള താരതമ്യം ശ്രവണം, ക്ലയന്റ് സോക്കറ്റ്, വിവർത്തനം ചെയ്ത ഉറവിടം എന്നിവ വേർതിരിച്ച് നിർത്തുന്നു, കാരണം അവ വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു.
വിപരീത അറ്റങ്ങളെ വിവരിക്കുന്ന രണ്ട് സംഖ്യകൾ
സെർവറിന്റെ കോൺഫിഗർ ചെയ്ത പോർട്ട് ക്ലയന്റ് ഡയൽ ചെയ്യുന്ന ലക്ഷ്യമാണ്. അത് നയം നിശ്ചയിക്കുന്നു, പ്രൊഫൈലിൽ കാണുന്നു, സെർവർ ഭാഗത്ത് തുറന്നിരിക്കണം. ക്ലയന്റിന്റെ ഉറവിട പോർട്ട് പ്രാദേശികമായി, സാധാരണയായി താൽക്കാലിക ശ്രേണിയിൽ നിന്ന് തിരഞ്ഞെടുക്കുന്നു, മറുപടിക്ക് ഇറങ്ങാൻ ഇടം ഉണ്ടാകാൻ വേണ്ടിയാണ് അതിന്റെ നിലനിൽപ്പ്. ഓരോ പുനഃസംയോജനത്തിലും അത് മാറാം, രൂപകൽപ്പനയിൽ ഒന്നും അതിന്റെ സ്ഥിരതയെ ആശ്രയിക്കുന്നില്ല.
ഇടയിലുള്ള റൗട്ടർ ആ ഉറവിടം തന്റെ സ്വന്തം 'NAT' മാപ്പിംഗിലേക്ക് വീണ്ടും എഴുതാം. അതുകൊണ്ടാണ് സെർവറിൽ കാണുന്ന സംഖ്യയ്ക്ക് ലാപ്ടോപ്പ് തിരഞ്ഞെടുത്ത സംഖ്യയുമായി പലപ്പോഴും ബന്ധമില്ലാത്തത്.
പുറത്തേക്ക് പോകുമ്പോൾ ഉറവിട സംഖ്യ എവിടെ മാറുന്നു
ഒരു സാങ്കൽപ്പിക IPv4 ഉദാഹരണം എടുക്കുക: വിവർത്തനം ചെയ്യുന്ന റൗട്ടറിന് പിന്നിലെ ക്ലയന്റ്, ഒരു 'UDP' ശ്രവണമുള്ള സെർവർ, രണ്ടിനെയും കടക്കുന്ന ഒരു ഡാറ്റാഗ്രാം. പാക്കറ്റ് മൂന്ന് നിരീക്ഷണ പോയിന്റുകളിൽ വീണ്ടും പ്ലേ ചെയ്യുന്നതിനുപകരം ഓരോ അറ്റത്തെയും അതിനോട് എന്ത് സംഭവിക്കുന്നു എന്നതിനെയും പട്ടിക പേരിടുന്നു.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
ലക്ഷ്യം ഓരോ വരിയിലും സ്ഥിരമാണ്, മാറുന്നത് ഉറവിടത്തിന്റെ അടയാളം മാത്രമാണ്. UDP NAT ആവശ്യകതകൾ ആന്തരിക വിലാസവും പോർട്ടും ബാഹ്യ മാപ്പിംഗിൽ നിന്ന് വേർതിരിക്കുന്നു, അതാണ് രണ്ടാമത്തെയും മൂന്നാമത്തെയും വരികൾ തമ്മിലുള്ള വ്യത്യാസം. റൗട്ടറിന് ക്ലയന്റിന്റെ ഉറവിട പോർട്ട് നിലനിർത്താം അല്ലെങ്കിൽ മറ്റൊന്ന് തിരഞ്ഞെടുക്കാം; നിലനിർത്തുന്നു എന്ന് അപ്ലിക്കേഷൻ അനുമാനിക്കരുത്.
മൂന്ന് അറ്റങ്ങളും ഹോസ്റ്റുകളിൽ നിന്നുതന്നെ വായിക്കുക
താഴെയുള്ള പട്ടികകൾ മൂന്ന് വ്യത്യസ്ത യന്ത്രങ്ങളിൽ നിന്നുള്ളതാണ്, ഒരുമിച്ച് മുഴുവൻ സംഭാഷണവും കാണിക്കുന്നു. ആദ്യത്തേത് സെർവറിലും രണ്ടാമത്തേത് ക്ലയന്റിലും മൂന്നാമത്തേത് മാപ്പിംഗ് ഉള്ളിടത്തും പ്രവർത്തിപ്പിക്കുക. ഒരു ലോഗ് വരി ഒരിക്കലും മൂന്നും കാണിക്കുന്നില്ല.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194ആദ്യ പട്ടിക സെർവർ സേവന പോർട്ടിൽ ബന്ധിതമാണെന്ന് തെളിയിക്കുന്നു, ഏത് പ്രോസസ് അത് കൈവശം വയ്ക്കുന്നു എന്ന് കാണിക്കുന്നു. രണ്ടാമത്തേത് ക്ലയന്റിന്റെ പ്രാദേശിക സോക്കറ്റും അത് ഡയൽ ചെയ്ത ലക്ഷ്യവും കാണിക്കുന്നു. മൂന്നാമത്തേത് റൗട്ടർ സൃഷ്ടിച്ച മാപ്പിംഗ് കാണിക്കുന്നു, വിവർത്തനം ചെയ്ത ഉറവിടം പ്രത്യക്ഷപ്പെടുന്ന ഏക സ്ഥലം അതാണ്. ആ ക്രമത്തിൽ വായിക്കുക, രണ്ട് സംഖ്യകളും വൈരുദ്ധ്യമായി തോന്നുന്നത് നിർത്തും.
പുനഃസംയോജനം എന്ത് മാറ്റുന്നു, എന്ത് മാറ്റുന്നില്ല
ചില റൗട്ടറുകൾ ഉറവിട പോർട്ട് ഒഴിവുള്ളപ്പോൾ നിലനിർത്തുന്നു, മറ്റുള്ളവ ഓരോ തവണയും വേറൊന്ന് അനുവദിക്കുന്നു. രണ്ട് സ്വഭാവങ്ങളും സാധാരണമാണ്, ആദ്യത്തേത് നിർബന്ധമാക്കുന്ന അപ്ലിക്കേഷൻ രണ്ടാമത്തേതിൽ തകരും. പുനഃസംയോജനത്തിനോ നെറ്റ്വർക്ക് മാറ്റത്തിനോ ശേഷം മാപ്പിംഗ് മാറുന്നത് സെർവർ തകരാറല്ല: ക്ലയന്റ് പുതിയ സോക്കറ്റ് തുറക്കുന്നു, റൗട്ടർ തന്നിലുള്ളത് നൽകുന്നു, സെർവർ അതേ ശ്രവണത്തിൽ പുതിയ ഉറവിടം കാണുന്നു. ഏതെങ്കിലും ക്ലയന്റ് പോർട്ടിലേക്ക് അയച്ച ട്രാഫിക് സെർവർ സ്വീകരിക്കും എന്ന് പ്രതീക്ഷിക്കുന്നതാണ് തകരാറ്.
സമൂഹത്തിലെ OpenVPN ക്ലയന്റുകൾ ഈ സ്വഭാവം nobind വഴി നേടുന്നു, അത് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന് പ്രാദേശിക പോർട്ട് തിരഞ്ഞെടുക്കാൻ അനുവദിക്കുന്നു; ദൂര പോർട്ട് ഇപ്പോഴും പ്രൊഫൈലിൽ നിന്നാണ് വരുന്നത്. വ്യക്തമായി ബൈൻഡ് ചെയ്യുന്നത് ബോധപൂർവമായ തിരഞ്ഞെടുപ്പാണ്, പ്രോട്ടോക്കോൾ ആവശ്യകതയല്ല. സെർവർ ഒരു അറ്റം നൽകിക്കൊണ്ടിരിക്കുന്നു, ക്ലയന്റുകൾ സ്വന്തം പ്രാദേശിക ഐഡന്റിറ്റികൾ തിരഞ്ഞെടുക്കുന്നു.
റെക്കോർഡിൽ പാളികൾ വെവ്വേറെ ലേബൽ ചെയ്യുക
ടണലിനുള്ളിൽ സ്വന്തം പോർട്ടുകളുള്ള രണ്ടാമത്തെ സംഭാഷണമുണ്ട്. ടണൽ വഹിക്കുന്ന HTTPS അഭ്യർത്ഥനയുടെ ലക്ഷ്യം TCP 443 ആണ്, പുറം എൻക്രിപ്റ്റ് ചെയ്ത കണക്ഷൻ UDP 1194 ഉപയോഗിക്കുന്നു, അതിനാൽ പുറം ഉറവിട പോർട്ട് മാറ്റുന്നത് ആന്തരിക സേവനത്തിൽ ഒന്നും മാറ്റുന്നില്ല.
പുറം പാളിയിലും പ്രോട്ടോക്കോൾ പ്രധാനമാണ്. UDP 1194 ഉം TCP 1194 ഉം വ്യത്യസ്ത അറ്റങ്ങളാണ്, സംഖ്യ ഒത്തുപോകുന്നതുകൊണ്ട് മാത്രം 'TCP' ശ്രവണം ഒരിക്കലും UDP ഡാറ്റാഗ്രാം സ്വീകരിക്കില്ല. വിന്യാസം രേഖപ്പെടുത്തുമ്പോൾ സെർവർ ശ്രവണം, ക്ലയന്റ് സോക്കറ്റ്, വിവർത്തനം ചെയ്ത ഉറവിടം എന്നിവ മൂന്ന് വേറിട്ട കാര്യങ്ങളായി ലേബൽ ചെയ്യുക, ഓരോന്നിനും ഗതാഗതം ചേർക്കുക.
പിന്നെ നയം റോളുകളെ പിന്തുടരട്ടെ. സെർവർ ഉദ്ദേശിച്ച ഗതാഗതം തന്റെ ശ്രവണത്തിൽ തുറക്കുന്നു, ഇപ്പോഴും പങ്കാളിയെ പ്രാമാണീകരിക്കുന്നു; ക്ലയന്റിന്റെ ഫയർവാൾ ഇൻബൗണ്ട് സേവനം പ്രസിദ്ധീകരിക്കാതെ സ്വന്തം ഔട്ട്ബൗണ്ട് കൈമാറ്റത്തിനുള്ള മറുപടികൾ അനുവദിക്കുന്നു. സ്റ്റേറ്റ്ലെസ് ഫിൽട്ടറിന് മടക്കദിശ വ്യക്തമായി എഴുതേണ്ടതുണ്ട്, വൃത്തിയുള്ള ഡയഗ്രമുകൾക്കപ്പുറവും ഈ വ്യത്യാസം പ്രധാനമാകാനുള്ള പ്രായോഗിക കാരണം അതാണ്.