VPN-ന് പുറത്തേക്ക് ഒരു പ്രാദേശിക വെബ് സേവനം മാത്രം, പോർട്ട് അനുസരിച്ച് റൂട്ട് ചെയ്യുക
സ്രോതസ്സ്-പോർട്ട് നിയമത്തിന് ഒരു ഹോസ്റ്റ് സേവനം WAN വഴി പുറത്തയക്കാമോ, ബാക്കി ഹോസ്റ്റ് VPN തുടർന്നും ഉപയോഗിക്കുമോ, അതിന്റെ ചെലവ് എന്താണെന്നും തീരുമാനിക്കുക.
ഒരു ഹോസ്റ്റ് സേവനം ഭൗതിക അപ്ലിങ്കിലൂടെ ഇന്റർനെറ്റിനോട് പ്രതികരിക്കണം, യന്ത്രത്തിലെ മറ്റെല്ലാം ടണൽ ഉപയോഗിച്ചുകൊണ്ടിരിക്കണം. നയാധിഷ്ഠിത റൂട്ടിംഗിന് ആ ഭാരം വഹിക്കാനാകുമോ എന്ന് മൂന്ന് വ്യവസ്ഥകൾ തീരുമാനിക്കുന്നു, ഓരോന്നും ഒരു നിയമം എഴുതുന്നതിന് മുമ്പ് പരിശോധിക്കാൻ വിലകുറവാണ്. സേവനം DNAT-ന്റെയോ ഫോർവേഡ് ചെയ്ത പോർട്ടിന്റെയോ പിന്നിലല്ല, ഈ ഹോസ്റ്റിൽ തന്നെ അവസാനിക്കണം, VPN-ന്റെ സ്വന്തം നിയമങ്ങൾ ഈ ഒഴിവാക്കൽ അനുവദിക്കണം, നിങ്ങൾ അഭ്യർത്ഥനയല്ല, പ്രതികരണമാണ് ഒത്തുനോക്കേണ്ടത്. മൂന്നിൽ ഏതെങ്കിലും പരാജയപ്പെട്ടാൽ താഴെയുള്ള കമാൻഡുകൾ പിശകില്ലാതെ ലോഡ് ചെയ്യും, പക്ഷേ ഉപകാരപ്രദമായി ഒന്നും ചെയ്യില്ല.
ഒരു നിയമം എഴുതുന്നതിന് മുമ്പ് മൂന്ന് വ്യവസ്ഥകൾ പരിശോധിക്കുക
DNAT വഴി ഒരു പോർട്ട് പ്രസിദ്ധീകരിക്കുന്ന കണ്ടെയ്നറോ, പോർട്ട് ഫോർവേഡിംഗിന് പിന്നിലിരിക്കുന്ന സെർവറോ ഈ ഹോസ്റ്റിൽ ഉണ്ടാകാത്ത പാക്കറ്റുകൾ സൃഷ്ടിക്കുന്നു. ആ പാക്കറ്റുകൾ ഫോർവേഡ് ചെയ്യപ്പെടുന്നു, അതിനാൽ ഹോസ്റ്റ്-ലോക്കൽ ഇൻപുട്ടിൽ അധിഷ്ഠിതമായ നിയമം അവയെ ഒരിക്കലും കാണുന്നില്ല കൂടാതെ ട്രാഫിക് സ്ഥിരസ്ഥിതി റൂട്ട് തുടർന്നും എടുക്കുന്നു. തുടരുന്നതിന് മുമ്പ് സേവനം യഥാർത്ഥത്തിൽ എവിടെ പ്രവർത്തിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക, കാരണം ആളുകൾ ഏറ്റവും കൂടുതൽ തെറ്റിക്കുന്ന വ്യവസ്ഥ ഇതാണ്.
രണ്ടാമത്തെ വ്യവസ്ഥ യന്ത്രശാസ്ത്രമല്ല, നയമാണ്. ടണലിനെ ഒഴിവാക്കുന്ന ഏത് റൂട്ടും ടണലിന്റെ ലക്ഷ്യത്തിനുള്ള ഒഴിവാക്കലാണ്, നിയന്ത്രിത ഹോസ്റ്റിൽ ആ തീരുമാനം നയത്തിന്റെ ഉടമയുടേതാണ്, ടൈംഔട്ട് ഡീബഗ് ചെയ്യുന്ന ആളുടേതല്ല.
പ്രതികരണം ഒത്തുനോക്കുക, ക്ലയന്റിന്റെ ലക്ഷ്യ പോർട്ടല്ല
TCP 443-ൽ കേൾക്കുന്ന സെർവറിന്റെ പ്രതികരണം സ്രോതസ്സ് പോർട്ട് 443-മായി ഹോസ്റ്റ് വിടുന്നു. അതേ ഹോസ്റ്റിലെ ബ്രൗസർ വിദൂര HTTPS സൈറ്റിലേക്ക് ബന്ധിപ്പിക്കുമ്പോൾ താൽക്കാലിക സ്രോതസ്സ് പോർട്ടും ലക്ഷ്യ പോർട്ട് 443-ഉം അയക്കുന്നു. രണ്ടും പോർട്ട് 443 ട്രാഫിക്കാണ്, അവയിൽ ഒന്ന് മാത്രമേ WAN പട്ടിക എടുക്കാവൂ, അതിനാലാണ് ലക്ഷ്യ-പോർട്ട് ഒത്തുനോക്കൽ തെറ്റായ പകുതി പിടിക്കുന്നത്.
പ്രതികരണത്തിന്റെ ദിശയാണ് നിങ്ങൾക്ക് വേർതിരിക്കാനാകുന്നത്. സ്രോതസ്സ് പോർട്ട് ഒത്തുനോക്കുക, നിയമം ലോക്കലായി സൃഷ്ടിച്ച പാക്കറ്റുകളിൽ മാത്രം പരിമിതപ്പെടുത്തുക, എങ്കിൽ നിയമം ബ്രൗസറിന്റെ അഭ്യർത്ഥനകളെ തൊടാതെ സേവനത്തിന്റെ സ്വന്തം പ്രതികരണങ്ങൾ ഉൾക്കൊള്ളുന്നു.
നിയമം അതിലേക്ക് ചൂണ്ടുന്നതിന് മുമ്പ് പൂർണ്ണമായ റിട്ടേൺ പട്ടിക നിർമ്മിക്കുക
ശൂന്യമായ പട്ടിക എന്നാൽ റൂട്ട് ഇല്ല, അത് തകർന്ന നയത്തെക്കാൾ തകർന്ന സേവനമായി കാണപ്പെടുന്നു. ആദ്യം അത് നിറയ്ക്കുക, ഹോസ്റ്റിൽ മറ്റൊന്നും അവകാശപ്പെടാത്ത പട്ടിക നമ്പറും മുൻഗണനയും ഉപയോഗിച്ച്:
ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100
സംഖ്യകൾ പകർത്തുന്നതിന് പകരം ജീവനുള്ള ഹോസ്റ്റിൽ നിന്ന് വായിക്കുക. ip -4 rule show ഏത് മുൻഗണനകൾ എടുത്തിട്ടുണ്ടെന്ന് പറയുന്നു, ഇപ്പോൾത്തന്നെയുള്ള ഒരു മുൻഗണനയിൽ നിയമം ചേർക്കുന്നത് വെവ്വേറെ ശരിയായി തോന്നുന്ന രണ്ട് നിയമങ്ങളുടെ ക്രമം നിശ്ശബ്ദമായി മാറ്റുന്നു.
ഇവിടെ യഥാർത്ഥ ജോലി ചെയ്യുന്നത് രണ്ട് സെലക്ടറുകളാണ്. iif lo എന്നത് ഹോസ്റ്റ് സ്വയം സൃഷ്ടിച്ച പാക്കറ്റുകൾ കെർണൽ എങ്ങനെ റിപ്പോർട്ട് ചെയ്യുന്നു എന്നതാണ്, അതിനാൽ നിയമത്തിന് പുറത്തുനിന്ന് വരുന്ന ഫോർവേഡ് ചെയ്ത ട്രാഫിക് അബദ്ധത്തിൽ പിടിക്കാനാവില്ല. ipproto tcp sport 443 അതിനെ ഒരു ട്രാൻസ്പോർട്ടിലും ഒരു പോർട്ടിലും ഒതുക്കുന്നു, അത് ആവശ്യകത അനുവദിക്കുന്നത്ര കർശനമാണ്. പ്രോട്ടോക്കോൾ സെലക്ടർ ഒഴിവാക്കിയാൽ നിയമം UDP 443-ഉം പിടിക്കും, അത് വ്യത്യസ്ത സ്വഭാവമുള്ള മറ്റൊരു സേവനമാണ്.
സ്വകാര്യ പ്രതികരണങ്ങൾ ടണലിനുള്ളിൽ തന്നെ സൂക്ഷിക്കുക
അതേ ശ്രോതാവ് സ്വകാര്യ വശത്തെ ക്ലയന്റുകൾക്കും പ്രതികരിക്കുന്നുവെങ്കിൽ, പട്ടിക 100-ൽ എല്ലാം പിടിക്കുന്ന WAN സ്ഥിരസ്ഥിതി ആ പ്രതികരണങ്ങൾ അപ്ലിങ്കിലൂടെ തിരികെ അയക്കാൻ ശ്രമിക്കും. WAN സ്ഥിരസ്ഥിതി പിന്തുടരാനാകാത്ത സ്വകാര്യ പ്രിഫിക്സുകൾ ചേർക്കുക, അല്ലെങ്കിൽ അവ അടുത്ത നയ-നിയമത്തിലേക്ക് വീഴാൻ അനുവദിക്കുക:
ip -4 route add table 100 throw 10.90.0.0/24
throw റൂട്ട് ഈ പട്ടികയിലെ തിരച്ചിൽ അവസാനിപ്പിച്ച് പാക്കറ്റ് നിയമങ്ങളുടെ പട്ടികയിലേക്ക് തിരികെ നൽകുന്നു, അതിനാൽ പിന്നീട് വരുന്ന VPN നയത്തിന് അവസരം ലഭിക്കുന്നു. അത് സ്വയം ടണലിലേക്ക് ഒന്നും റൂട്ട് ചെയ്യുന്നില്ല, പിന്നീട് വരുന്ന ഒരു നിയമത്തിനും ഒത്തുപോകുന്ന റൂട്ട് ഇല്ലെങ്കിൽ പാക്കറ്റ് എങ്ങനെയും പരാജയപ്പെടും; throw പരിഹാരമാണെന്ന് കരുതാതെ അടുത്ത നയം പരിശോധിക്കുക.
റിവേഴ്സ്-പാത്ത് ഫിൽട്ടറിംഗും ഹോസ്റ്റ് ഫയർവാൾ നിയമങ്ങളും വരുന്ന അഭ്യർത്ഥനയ്ക്ക് ഇപ്പോഴും ബാധകമാണ്. പരിശോധന ലഘൂകരിക്കുന്നതിന് മുമ്പ് അവയുടെ യഥാർത്ഥ വിധികൾ നോക്കുക, കാരണം റൂട്ടിംഗ് ഒഴിവാക്കൽ rp_filter അസാധ്യമെന്ന് കരുതുന്ന ഒരു തിരിച്ചുവരവ് പാത സ്വീകരിക്കാൻ പ്രേരിപ്പിക്കുന്നില്ല.
TCP, തുടർന്ന് QUIC, തുടർന്ന് റീബൂട്ട് പരീക്ഷിക്കുക
അംഗീകൃത ബാഹ്യ ക്ലയന്റിൽ നിന്ന് ഒരു കണക്ഷനും സ്വകാര്യ വശത്തുനിന്ന് ഒരു കണക്ഷനും തുറക്കുക, തുടർന്ന് യഥാർത്ഥ വിലാസങ്ങളും പോർട്ടുകളും ഉപയോഗിച്ച് പ്രതികരണ തിരച്ചിൽ പരിശോധിക്കുക. ബാഹ്യ പ്രതികരണം പട്ടിക 100 എടുക്കുകയും സ്വകാര്യ പ്രതികരണം എടുക്കാതിരിക്കുകയും ചെയ്താൽ, നയം നിങ്ങൾ ആവശ്യപ്പെട്ടത് തന്നെ ചെയ്യുന്നു.
HTTP/3 UDP വഴി നൽകുന്നു, TCP നിയമവുമായി ഒത്തുപോകില്ല, അതിനാൽ QUIC ശ്രോതാവിന് സ്വന്തം സെലക്ടർ വേണം, അല്ലെങ്കിൽ HTTPS പ്രവർത്തിക്കുമ്പോഴും അത് ടണൽ തുടർന്നും ഉപയോഗിക്കും. നിങ്ങൾ തീരുമാനിക്കുന്ന നിയമങ്ങൾ ഇന്റർഫേസിന്റെ ഉടമയായ ഘടകത്തിൽ സംരക്ഷിക്കുക, വീണ്ടും ബന്ധിപ്പിച്ചതിനോ DHCP പുതുക്കലിനോ ശേഷം അവ സ്ഥിരീകരിക്കുക. റീബൂട്ടിന് ശേഷം എതിരാളിയായ മാനേജർ റൺടൈം റൂട്ട് നീക്കം ചെയ്താൽ, അത് ഉറവിടത്തിൽ തന്നെ പരിഹരിക്കേണ്ട ഉടമസ്ഥതാ പ്രശ്നമാണ്, മുകളിൽ കൂടുതൽ വിശാലമായ NAT നിയമങ്ങൾ ചേർക്കാനുള്ള കാരണമല്ല.