VPN സബ്നെറ്റിലേക്കുള്ള പോർട്ട് ഫോർവേഡിംഗിൽ SNAT പ്രയോഗിക്കണോ?

റൂട്ടറിന്റെ സ്വന്തം VPN ക്ലയന്റിന് പിന്നിലുള്ള ഒരു ഹോസ്റ്റിലേക്ക് പോർട്ട് ഫോർവേഡ് ചെയ്യുന്നത് ഫയർവാൾ പ്രശ്നമായി തോന്നിക്കുന്ന രീതിയിൽ പരാജയപ്പെടുന്നു, കാരണം അഭ്യർത്ഥന വ്യക്തമായി എത്തുന്നു. സേവനം കണക്ഷൻ രേഖപ്പെടുത്തുന്നു, ക്ലയന്റ് കാത്തിരിക്കുന്നു, ഒന്നും തിരികെ വരുന്നില്ല. ലക്ഷ്യ വിവർത്തനം അതിന്റെ ജോലി ചെയ്തു; തിരികെ വരുന്ന പാക്കറ്റാണ് നഷ്ടപ്പെട്ട ഭാഗം. റൂട്ടറിലെ ഒരു തിരഞ്ഞെടുത്ത സ്രോതസ്സ്-NAT നിയമം ഇത് ശരിയാക്കുന്നു, ആസക്‌തിപ്പെടുത്തുന്ന ഭാഗം ആ നിയമം എത്ര ഇടുങ്ങിയതാകാം എന്ന് തീരുമാനിക്കുകയാണ്.

മറുപടി എന്തുകൊണ്ട് മറ്റൊരു വഴി തിരഞ്ഞെടുക്കുന്നു

പോർട്ട് ഫോർവേഡിംഗ് ഒരു പാക്കറ്റ് എവിടേക്ക് പോകുന്നു എന്ന് വീണ്ടും എഴുതുന്നു, എവിടെ നിന്ന് വന്നു എന്ന് ഒരിക്കലും എഴുതുന്നില്ല. ഇന്റർനെറ്റ് ക്ലയന്റിന്റെ വിലാസം ടണലിലൂടെയുള്ള മുഴുവൻ വഴിയും സ്രോതസ്സ് ഫീൽഡിൽ തുടരുന്നു, അതിനാൽ ദൂര സേവനം ഒരു അപരിചിതനെ കാണുകയും തനിക്ക് അറിയാവുന്ന ഏക മാർഗത്തിലൂടെ മറുപടി നൽകുകയും ചെയ്യുന്നു: സ്വന്തം ഡിഫോൾട്ട് ഗേറ്റ്‌വേ വഴി. ആ ഗേറ്റ്‌വേ എതിർവശത്തെ VPN കോൺസെൻട്രേറ്റർ ആണ്, അതിന് ഏകപക്ഷീയമായ പൊതു വിലാസത്തിലേക്ക് തിരികെയുള്ള റൂട്ടില്ല.

ടണൽ ഇന്റർഫേസിൽ ഒരു ക്യാപ്ചർ നോക്കുക, അസമത്വം വ്യക്തമാണ്: അഭ്യർത്ഥന പാക്കറ്റുകൾ പുറത്തേക്ക്, അകത്തേക്ക് ഒന്നുമില്ല. ഫോർവേഡ് ചെയിൻ ഫ്ലോ അനുവദിച്ചു, ടണൽ അത് വഹിച്ചു, അതിനാൽ വീഴ്ച സംഭവിക്കുന്നത് ദൂര ഹോസ്റ്റ് ഇതിനകം ഒരു മടക്കപ്പാത തിരഞ്ഞെടുത്തതിന് ശേഷമാണ്.

വിശ്വസിക്കാൻ മതിയായ ഇടുങ്ങിയ സ്രോതസ്സ് നിയമം

ദൂര ഹോസ്റ്റ് മറുപടി നൽകുന്ന സ്രോതസ്സാക്കി റൂട്ടറിനെ മാറ്റുക. ഈ ക്രമീകരണത്തിൽ WAN വിലാസം 203.0.113.24 ആണ്, LAN 192.168.88.0/24 ആണ്, റൂട്ടറിന്റെ ടണൽ വിലാസം 172.20.5.1 ആണ്, സേവനം 172.20.5.40:8443 ൽ മറുപടി നൽകുന്നു. താഴെയുള്ള നിയമം ലക്ഷ്യ വിവർത്തനത്തിന് ശേഷമുള്ള പാക്കറ്റുമായി പൊരുത്തപ്പെടുന്നു, അതുകൊണ്ടാണ് അത് പൊതു വിലാസത്തിന് പകരം വിവർത്തനം ചെയ്ത വിലാസം പേരിടുന്നത്. അതിൽ ഒന്നും ക്ലയന്റിന്റെ വിലാസത്തെ ആശ്രയിക്കുന്നില്ല, അതാണ് കൃത്യമായ കാര്യം.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

ആ വരിയിലെ ഓരോ പൊരുത്തവും ഒരു ടണലിലെ ഒരു സേവനത്തിന് വീണ്ടും എഴുത്ത് പ്രാദേശികമായി നിർത്താൻ ഉള്ളതാണ്. ഇന്റർഫേസോ പോർട്ടോ നീക്കം ചെയ്യുക, പ്രശ്നത്തിന് ആവശ്യമുള്ളതിലധികം ട്രാഫിക് വീണ്ടും എഴുതും, അങ്ങനെ ലക്ഷ്യമിട്ട പരിഹാരം അടുത്ത വ്യക്തിക്ക് ഒരു കടങ്കഥയായി മാറുന്നു.

എപ്പോഴാണ് സർവവ്യാപിയായ മാസ്കറേഡ് സത്യസന്ധമായ തിരഞ്ഞെടുപ്പ്

റൂട്ടർ ഒരേ VPN സബ്നെറ്റിലേക്ക് നിരവധി സേവനങ്ങൾ ഫോർവേഡ് ചെയ്യുന്നുവെങ്കിൽ, ഓരോ സേവനത്തിനുമുള്ള നിയമം ആരും പരിപാലിക്കാത്ത ഒരു പട്ടികയാകുന്നു. ടണൽ ഇന്റർഫേസ് വിടുന്ന എല്ലാം മാസ്ക് ചെയ്യുന്നത് ലളിതവും പ്രവചിക്കാവുന്നതുമാണ്, അതിന്റെ വില എതിർവശത്തെ ഓരോ ഹോസ്റ്റിൽ നിന്നും യഥാർത്ഥ ക്ലയന്റിനെ മറയ്ക്കുന്നതാണ്. അവിടത്തെ ലോഗുകൾ ആരോപണത്തിന് ഉപയോഗിക്കുന്നില്ലെങ്കിൽ അത് തിരഞ്ഞെടുക്കുക; ഉപയോഗിക്കുന്നുവെങ്കിൽ ഇടുങ്ങിയ നിയമം നിലനിർത്തുക.

രണ്ട് ഓപ്ഷനുകളും വ്യത്യസ്തമായി പരാജയപ്പെടുന്നു. കാണാത്ത ഇടുങ്ങിയ നിയമം ഒരു സേവനം തകർക്കുന്നു; വളരെയധികം പൊരുത്തപ്പെടുന്ന വിശാലമായ മാസ്കറേഡ് ഇതിനകം പ്രവർത്തിച്ചിരുന്ന ട്രാഫിക്, റൂട്ടറിന്റെ സ്വന്തം ഔട്ട്ഗോയിംഗ് കണക്ഷനുകൾ ഉൾപ്പെടെ, നിശബ്ദമായി വീണ്ടും എഴുതാം.

പ്രസിദ്ധീകരിക്കുന്നതിന് മുമ്പ് കൗണ്ടറുകൾ പരിശോധിക്കുക

ഒരിക്കലും പൊരുത്തപ്പെടാത്ത നിയമങ്ങൾ പാക്കറ്റുകൾ എണ്ണുന്നതുവരെ പ്രവർത്തിക്കുന്ന നിയമങ്ങളെപ്പോലെ തന്നെ തോന്നും. ഏതെങ്കിലും ക്ലയന്റ് കണക്ട് ചെയ്യുന്നതിന് മുമ്പ് ബൈറ്റ് കൗണ്ടറുകളോടെ പട്ടിക വീണ്ടും വായിക്കുക, തുടർന്ന് LAN അല്ലാത്ത നെറ്റ്‌വർക്കിൽ നിന്ന് കണക്ട് ചെയ്ത് വീണ്ടും വായിക്കുക. ഊഹത്തെ വസ്തുതയാക്കി മാറ്റുന്നത് ഈ രണ്ട് വായനകളാണ്. രണ്ടാമത്തേത് നീങ്ങിയതിന് ശേഷം മാത്രം ഫോർവേഡ് പ്രസിദ്ധീകരിക്കുക.

iptables -t nat -L POSTROUTING -v -n --line-numbers

യഥാർത്ഥ കണക്ഷന് ശേഷം സ്രോതസ്സ് നിയമത്തിൽ പൂജ്യം കൗണ്ടർ എന്നാൽ പൊരുത്തം തെറ്റാണ്, സാധാരണയായി ലക്ഷ്യമോ പോർട്ടോ വിവർത്തനത്തിന് ശേഷമുള്ള പാക്കറ്റുമായി പൊരുത്തപ്പെടുന്നില്ല. കൗണ്ടർ ഉയരുന്നുവെങ്കിലും ക്ലയന്റ് ഇപ്പോഴും സമയപരിധി കഴിയുന്നുവെങ്കിൽ, മടക്കപ്പാത ശരിയായി, മറ്റെന്തോ മറുപടി വീഴ്ത്തുന്നു, അതിനാൽ അടുത്തതായി എതിർവശത്തെ ഫോർവേഡ് നയം നോക്കുക. LAN-നുള്ളിൽ നിന്നുള്ള ഹെയർപിൻ ആക്സസ് വേറിട്ട പ്രശ്നമാണ്, അതിന് സ്വന്തം നിയമം വേണം, ഇതിന്റെ കൂടുതൽ വിശാലമായ പതിപ്പല്ല.