VPN പോർട്ട് തുറക്കുന്നത് ക്ലയന്റുകളെ LAN-ൽ എത്തിക്കുന്നില്ല

ടണൽ ഉയരുന്നു, ക്ലയന്റ് പ്രാമാണീകരിക്കുന്നു, പക്ഷേ ഗേറ്റ്‌വേയ്ക്ക് പിന്നിലെ LAN അദൃശ്യമായി തുടരുന്നു. ഇത് ശരിയാക്കേണ്ടിയിരുന്ന നിയമം VPN പോർട്ട് അനുവദിക്കുന്നു, എഴുതിയതുപോലെ തന്നെ പ്രവർത്തിക്കുന്നു; കാരണം ആ നിയമം ഗേറ്റ്‌വേയിലേക്കു തന്നെ അയച്ച പാക്കറ്റുകളെ നിയന്ത്രിക്കുന്നു. ഗേറ്റ്‌വേയ്ക്ക് പിന്നിലെ ഹോസ്റ്റിലേക്കുള്ള ക്ലയന്റ് ട്രാഫിക്കിന് മറ്റൊരു ലക്ഷ്യവും മറ്റൊരു ശൃംഖലയും ഉണ്ട്. വിജയകരമായ ലോഗിൻ കെർണൽ ഏത് ശൃംഖല നോക്കുന്നു എന്നത് മാറ്റുന്നില്ല.

രണ്ട് ശൃംഖലകൾ, രണ്ട് വ്യത്യസ്ത ലക്ഷ്യങ്ങൾ

പാക്കറ്റിന്റെ വിധി അത് എവിടേക്ക് പോകുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു, എങ്ങനെ വന്നു എന്നതിനെയല്ല. ഗേറ്റ്‌വേയിലെ വിലാസത്തിലേക്കുള്ള ട്രാഫിക് പ്രാദേശികമായി എത്തിക്കുകയും ഇൻപുട്ട് നിയമങ്ങൾ കൊണ്ട് വിലയിരുത്തുകയും ചെയ്യുന്നു. ഗേറ്റ്‌വേ മുന്നോട്ട് അയക്കുന്ന ട്രാഫിക് ഫോർവേഡിംഗ് നിയമങ്ങൾ കൊണ്ട് വിലയിരുത്തുന്നു. ഒരേ ടണൽ ഇന്റർഫേസിന് രണ്ടു തരം പാക്കറ്റുകളും ഉണ്ടാക്കാം, അതിനാൽ ഒരു നിയമത്തിന് രണ്ടു ജോലികളും ഉൾക്കൊള്ളാൻ കഴിയില്ല.

മുഴുവൻ കഥയും ഒരു വാക്യത്തിൽ: ശ്രോതാവിനെ അനുവദിക്കുന്നത് അതിന് പിന്നിലെ നെറ്റ്‌വർക്കിനെ അനുവദിക്കുന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഇവ വേറിട്ട തെളിവുകളുള്ള രണ്ടു വേറിട്ട തീരുമാനങ്ങളാണ്, രണ്ടിലും ഒരേ ഇന്റർഫേസ് പേരുണ്ടെന്നത് അവയെ ഒന്നാക്കുന്നില്ല.

ശ്രോതാവിന്റെ നിയമം യഥാർത്ഥത്തിൽ എന്ത് അനുവദിക്കുന്നു

ശ്രോതാവിന്റെ പാക്കറ്റുകൾ VPN പ്രക്രിയയിൽ അവസാനിക്കുന്നു, അതാണ് ടണൽ സ്ഥാപിക്കാൻ അനുവദിക്കുന്നത്. ഗേറ്റ്‌വേയുടെ ഭരണ പേജും പ്രാദേശിക രോഗനിർണയ മറുപടിയും ഹോസ്റ്റിന്റെ സ്വന്തം ഇൻപുട്ട് പാത ഉപയോഗിക്കുന്നു, അതിനാൽ ഗേറ്റ്‌വേയിലേക്കുള്ള പരിശോധന വിജയിക്കുന്നു, അതിന് പിന്നിലുള്ളതെല്ലാം പരാജയപ്പെടുന്നു. രണ്ടു ഫലങ്ങളും ശരിയാണ്, ഒന്നും LAN-നെക്കുറിച്ചല്ല.

പ്രക്രിയ മറ്റൊരു ലക്ഷ്യത്തിനായി ക്ലയന്റ് ട്രാഫിക് ഡീകാപ്സുലേറ്റ് ചെയ്യുമ്പോൾ പാക്കറ്റ് ഫോർവേഡിംഗ് പാതയിൽ പ്രവേശിക്കുന്നു, അവിടെ അനുമതി വേണം. വിജയകരമായ പ്രാമാണീകരണം ക്ലയന്റ് ആരെന്ന് തീരുമാനിക്കുന്നു; എവിടേക്ക് പോകാമെന്ന് തീരുമാനിക്കുന്നില്ല. രണ്ടു ചോദ്യങ്ങൾക്ക് വ്യത്യസ്ത ഉടമകളും ലോഗുകളും പിശക് സന്ദേശങ്ങളും ഉണ്ട്.

ക്ലയന്റിൽ നിന്ന് പരിശോധിക്കുക, ഗേറ്റ്‌വേയിൽ നിന്ന് ഒരിക്കലുമരുത്

ഗേറ്റ്‌വേയിൽ ഉണ്ടാക്കുന്ന പരിശോധന ഹോസ്റ്റിന്റെ സ്വന്തം ഔട്ട്പുട്ട് പാത പിന്തുടരുന്നു, ഫോർവേഡിംഗ് പാത അടച്ചിരിക്കുമ്പോഴും വിജയിക്കാം. പരിശോധന ക്ലയന്റിൽ നിന്ന് ആരംഭിച്ച് പ്രവാഹത്തിന്റെ രണ്ടറ്റവും നോക്കുക.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

അഭ്യർത്ഥന tun0-ൽ പ്രത്യക്ഷപ്പെടുകയും ലക്ഷ്യത്തിലേക്ക് ഒന്നും എത്താതിരിക്കുകയും ചെയ്താൽ പാക്കറ്റ് എത്തിയ ശേഷം ഉപേക്ഷിക്കുന്നു, ഇത് ഫോർവേഡിംഗ് നിയമങ്ങളെയോ ലക്ഷ്യത്തിന്റെ സ്വന്തം ഫിൽട്ടറിംഗിനെയോ സൂചിപ്പിക്കുന്നു. tun0-ൽ ഒന്നും പ്രത്യക്ഷപ്പെടുന്നില്ലെങ്കിൽ ക്ലയന്റ് അത് ടണലിലേക്കുപോലും അയക്കുന്നില്ല, പ്രശ്നം ഗേറ്റ്‌വേ നയത്തിലല്ല, ക്ലയന്റിലെ റൂട്ടിംഗിലാണ്. ശരിയായി പുറത്തുപോയി ഒന്നും തിരികെ വരാത്ത അഭ്യർത്ഥനയുമായി ഇത് താരതമ്യം ചെയ്യുക; അതാണ് തിരിച്ചുവരവ് പാതയുടെ കാര്യം.

ഫോർവേഡിംഗിന് ഒന്നല്ല, മൂന്ന് കാര്യങ്ങൾ വേണം

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

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

മൂന്ന് ഔട്ട്പുട്ടുകളും ഒരുമിച്ച് വായിക്കുക. ആദ്യത്തേതിൽ പൂജ്യമുണ്ടെങ്കിൽ ബാക്കി രണ്ടും അപ്രസക്തമാണ്; രണ്ടാമത്തേതിൽ സ്വതേ ഉപേക്ഷിക്കുന്ന നയമുണ്ടെങ്കിൽ ക്ലയന്റിന്റെ പാക്കറ്റുകൾ ഉപേക്ഷിക്കപ്പെടും, ഗേറ്റ്‌വേയുടെ സ്വന്തം ട്രാഫിക് പ്രവർത്തിക്കും. മൂന്നാമത്തെ ഔട്ട്പുട്ട് ശ്രോതാവ് നിയമം ഒരിക്കലും പ്രശ്നമല്ലായിരുന്നു എന്ന് കാണിക്കുന്നു.

രേഖകളിൽ രണ്ട് നിയമ കൂട്ടങ്ങളും വേറിട്ട് സൂക്ഷിക്കുക

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

ഓരോ പ്രാമാണീകരിച്ച പങ്കാളിയെയും വിശ്വസ്ത LAN അംഗമായി കാണുന്നതിനുപകരം, ആവശ്യമുള്ള ക്ലയന്റ് ശ്രേണികൾക്കും സേവനങ്ങൾക്കും ഇടുങ്ങിയ നിയമങ്ങൾ ഉപയോഗിക്കുക. StrongSwan-ന്റെ ഫോർവേഡിംഗ് കുറിപ്പുകൾ അതേ അതിർത്തിയുടെ തിരിച്ചുവരവ് പാതയുടെയും വിവർത്തനത്തിന്റെയും വശം വിവരിക്കുന്നു, അതും വീണ്ടും മൂന്നാമത്തെ തീരുമാനമാണ്.

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