റൗട്ടറിലെ VPN അല്ലെങ്കിൽ പോർട്ട് ഫോർവേഡിംഗ്: ഏതാണ് ജയിക്കുന്നത്?

റൗട്ടർ തന്നെ VPN അവസാനിപ്പിക്കുന്നു, പഴയ ഫോർവേഡിംഗ് നിയമം ഇപ്പോഴും അതേ UDP പോർട്ട് LAN-ലെ ഒരു യന്ത്രത്തിലേക്ക് അയയ്ക്കുന്നു. അവയിൽ ഒന്ന് മാത്രമേ യഥാർത്ഥ അന്തിമ പോയിന്റ് ആകാൻ കഴിയൂ, കെർണൽ അവയ്ക്കിടയിൽ തീരുമാനിക്കുന്നില്ല. ലക്ഷ്യ വിവർത്തനം ലോക്കൽ സേവനത്തോട് ചോദിക്കുന്നതിന് മുമ്പ് പാക്കറ്റ് വീണ്ടും എഴുതുന്നു, അതിനാൽ VPN പ്രോസസ് മറ്റൊരിടത്തേക്ക് അയച്ച കടന്നുപോകലിനായി കാത്തിരിക്കുന്നു. ചുമതല പോർട്ട് ആരുടേതാണെന്ന് തീരുമാനിക്കുക എന്നതാണ്, തുടർന്ന് നിയമങ്ങൾ ഒത്തുപോകാൻ വയ്ക്കുക.

ഒരു പോർട്ട്, രണ്ട് അവകാശവാദികൾ

റൗട്ടറിനുള്ളിൽ പ്രവർത്തിക്കുന്ന VPN സെർവറിന് സ്വന്തം സോക്കറ്റിലേക്ക് നയിക്കുന്ന ഇൻബൗണ്ട് അനുമതി വേണം. അതേ പോർട്ടിലേക്കുള്ള ലക്ഷ്യ-NAT എൻട്രി തികച്ചും മറ്റൊരിടത്തേക്ക് നയിക്കുന്നു: LAN വിലാസവും ഫോർവേഡിംഗ് തീരുമാനവും. ഇവ വ്യത്യസ്ത ലോഗുകളും വ്യത്യസ്ത പരാജയ രീതികളുമുള്ള വ്യത്യസ്ത അന്തിമ പോയിന്റുകളാണ്. സാധാരണ സൂചന ഒരു വിലാസ കുടുംബം പ്രവർത്തിക്കുന്നു, മറ്റൊന്ന് പ്രവർത്തിക്കുന്നില്ല എന്നതാണ്, കാരണം ശേഷിച്ച എൻട്രി ഒരു കുടുംബത്തിനായി എഴുതിയതും ഒരിക്കലും പുനഃപരിശോധിച്ചിട്ടില്ലാത്തതുമാണ്.

തിരുത്തുന്നതിന് മുമ്പ് അവകാശവാദം എഴുതുക: കുടുംബം, ബാഹ്യ വിലാസം, ഗതാഗതം, പോർട്ട്, വിവർത്തനം ചെയ്ത ലക്ഷ്യം.

പ്രാദേശിക പരിശോധനയ്ക്ക് മുമ്പ് വിവർത്തനം നടക്കുന്നു

ലക്ഷ്യ NAT കർണൽ ലോക്കൽ ഡെലിവറിയും ഫോർവേഡിംഗും തമ്മിൽ തിരഞ്ഞെടുക്കുന്നതിന് മുമ്പ്, പ്രീറൗട്ടിംഗ് ഘട്ടത്തിൽ പാക്കറ്റിന്റെ ലക്ഷ്യം മാറ്റുന്നു. ലക്ഷ്യം LAN ഹോസ്റ്റ് ആയാൽ പാക്കറ്റ് ഫോർവേഡിംഗ് പാത സ്വീകരിക്കുന്നു. റൗട്ടറിന്റെ സ്വന്തം സോക്കറ്റിനുള്ള ഇൻപുട്ട് നിയമങ്ങൾ ഒരിക്കലും പരിശോധിക്കപ്പെടുന്നില്ല, അതിനാൽ ക്ലയന്റ് കാത്തിരിക്കുമ്പോൾ VPN ലോഗ് ശൂന്യമായി തുടരുന്നു.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

ഈ ക്രമമാണ് മുഴുവൻ സംവിധാനവും, ഉപകരണ ഇന്റർഫേസുകൾ അത് മാറ്റാതെ ചെക്ക്ബോക്സുകൾക്ക് പിന്നിൽ ഒളിപ്പിക്കുന്നു. പാക്കറ്റ് ഏത് പാത സ്വീകരിക്കണമെന്ന് ഇപ്പോഴും ലക്ഷ്യസ്ഥാനത്തിന്റെ ഉടമ തീരുമാനിക്കുന്നു.

LAN ഹോസ്റ്റ് ഉദ്ദേശിച്ച അന്തിമ പോയിന്റ് ആണെങ്കിൽ, ഫോർവേഡിംഗ് ശരിയാണ്, റൗട്ടർ അതേ പോർട്ടിൽ കൂടി കേൾക്കരുത്.

ഒരു മാപ്പിംഗ് നിലനിർത്തി മറ്റൊന്ന് നീക്കുക

ആ പോർട്ടിനും കുടുംബത്തിനുമുള്ള NAT എൻട്രികൾ ലിസ്റ്റ് ചെയ്ത് അതിജീവിക്കുന്നത് തിരഞ്ഞെടുക്കുക:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

അതേ നമ്പറുള്ള TCP എൻട്രി UDP പരാജയത്തിന് പ്രസക്തമല്ല, അവയെ ഒരു വസ്തുവായി കണക്കാക്കുന്നത് തെറ്റായ നിയമം മായ്ക്കാൻ ഇടയാക്കുന്നു. ലോക്കൽ സോക്കറ്റ് വിജയിക്കേണ്ടതുണ്ടെങ്കിൽ, കൂട്ടിയിടിക്കുന്ന മാപ്പിംഗിന്റെ ഉടമ ആ എൻട്രി നീക്കുകയോ വീണ്ടും എഴുതുകയോ ചെയ്യുന്നു, റൗട്ടറിന്റെ സ്വന്തം പോർട്ടിനുള്ള ഇൻബൗണ്ട് അനുമതി അതിന്റെ സ്ഥാനത്ത് തുടരുന്നു. ബന്ധമില്ലാത്ത ഫോർവേഡിംഗുകൾ, മാനേജ്മെന്റ് പാത, നിയമങ്ങളുടെ ഒരു പകർപ്പ്—എല്ലാം ഈ മാറ്റത്തെ അതിജീവിക്കണം.

VPN വേറെ ഹോസ്റ്റിൽ കഴിയുന്നുവെങ്കിൽ, ഫോർവേഡിംഗ് ആണ് ശരിയായ വസ്തു. കണ്ടെയ്നറിലോ വെർച്വൽ മെഷീനിലോ ഉള്ള സേവനത്തിന്, ബോക്സിനെ റൗട്ടർ എന്ന് വിളിച്ചാലും പ്രസിദ്ധീകരിച്ച പോർട്ട് വേണ്ടിവന്നേക്കാം, അതിനാൽ കേസിലെ ലേബലല്ല, സോക്കറ്റും അതിന്റെ നെയിംസ്പെയ്സും പിന്തുടരുക.

പുറത്തുനിന്ന് ഉടമയെ സ്ഥിരീകരിക്കുക

ഓരോ കുടുംബവും വെവ്വേറെ പരിശോധിക്കുക, കാരണം റൗട്ടറിൽ അവസാനിക്കുന്ന IPv6 കണക്ഷൻ പഴയ നിയമം റീഡയറക്ട് ചെയ്യുന്ന IPv4 കണക്ഷനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഏത് അന്തിമ പോയിന്റ് ഉത്തരം നൽകി എന്ന് കാണാൻ സ്വീകരിക്കുന്ന സേവനത്തിന്റെ ലോഗ് വായിക്കുക, ക്ലയന്റിന്റെ വിജയ സന്ദേശം ദുർബല തെളിവായി കാണുക. അർത്ഥവത്തായ പരിശോധനയ്ക്ക് പുതിയ ഫ്ലോ ആവശ്യമാണ്. പുറത്തുള്ള ഹോസ്റ്റിൽ നിന്ന് nc -zvu 203.0.113.7 1194 ഉപയോഗിച്ച് പ്രോബ് അയയ്ക്കുക, വിജയിയുടെ ലോഗ് journalctl -u openvpn@server -n 20 ഉപയോഗിച്ച് വായിക്കുക. റൗട്ടറിന്റെ ശ്രോതാവ് കണക്ഷൻ സ്വയം രേഖപ്പെടുത്തുന്നു, LAN ഹോസ്റ്റ് അത് സ്വന്തം സേവനത്തിൽ രേഖപ്പെടുത്തുന്നു.

കണക്ഷൻ ട്രാക്കിംഗ് നിലവിലുള്ള ഫ്ലോകളെ അവയുടെ യഥാർത്ഥ മാപ്പിംഗിൽ നിലനിർത്തുന്നു, അതിനാൽ സ്ഥാപിത സെഷൻ നിങ്ങൾ ഇപ്പോൾ തിരുത്തിയ നിയമത്തെക്കാൾ കൂടുതൽ കാലം നിലനിൽക്കാം.

ഉദ്ദേശിച്ച അന്തിമ പോയിന്റ് അതിന്റെ സാധാരണ ഐഡന്റിറ്റി പരിശോധനകളോടെ ഉത്തരം നൽകിയാൽ, ടണലിന് പിന്നിലെ സ്വകാര്യ വിഭവം പരിശോധിക്കുക. പുറം ശ്രോതാവിൽ എത്തുന്നത് ആദ്യ ചുവട് മാത്രമാണ്; ആന്തരിക റൂട്ടിംഗും അപ്ലിക്കേഷൻ അനുമതിയും വെവ്വേറെ ഫലങ്ങളാണ്.