nginx തകരുന്നതിന് മുമ്പ് OpenVPN SNAT നിയമം പരിധിവത്കരിക്കുക

ഒരേ തരം ഹോസ്റ്റിൽ നിന്ന് രണ്ട് പരാജയങ്ങൾ വീണ്ടും വീണ്ടും വരുന്നു. ആദ്യത്തേതിൽ ക്ലയന്റുകൾ പ്രാമാണീകരിക്കുന്നു, പിന്നീട് ടണലിന് പുറത്ത് ഒന്നും എത്തുന്നില്ല. രണ്ടാമത്തേതിൽ VPN ഉയരുന്നു, സർവറിന്റെ സ്വന്തം വെബ്സൈറ്റ് പ്രതികരിക്കുന്നത് നിർത്തുന്നു, ഇത് കൂടുതൽ ആശങ്കാജനകമാണ് കാരണം അത് പാർശ്വ നാശമായി തോന്നുന്നു. കണ്ടെയ്നർ അടിസ്ഥാനമാക്കിയ VPS-ൽ രണ്ടും സാധാരണയായി ഒരേ ചെറിയ പരിശോധനാ പട്ടികയിലേക്ക് മടങ്ങുന്നു, ക്രമം പ്രധാനമാണ്: ആദ്യം ഉപകരണം, രണ്ടാമത് വിവർത്തനം, മൂന്നാമത് പരിധി.

കണ്ടെയ്നറിന് tun ഉപകരണം സൃഷ്ടിക്കാൻ കഴിയുമെന്ന് ഉറപ്പാക്കുക

ടണൽ ഇന്റർഫേസ് നിലനിൽക്കാൻ കഴിയില്ലെങ്കിൽ മറ്റൊന്നും പ്രധാനമല്ല. /dev/net/tun ഉണ്ടെന്നും ടെസ്റ്റ് ഉപകരണം സൃഷ്ടിക്കുന്നത് വിജയിക്കുന്നുവെന്നും പരിശോധിക്കുക, കാരണം പല ദാതാക്കളും കണ്ടെയ്നറുകൾക്കുള്ളിൽ tun സ്വതവേ അപ്രാപ്തമാക്കുന്നു. ഒരിക്കലും സൃഷ്ടിക്കപ്പെടാത്ത ഉപകരണത്തിന് ഒരു firewall ജോലിയും പകരമാകുന്നില്ല.

ഉപകരണം ഇല്ലെങ്കിൽ ഹോസ്റ്റിനോ ദാതാവിനോ മാത്രമേ അത് പ്രവർത്തനക്ഷമമാക്കാൻ കഴിയൂ. ഒരു ആഴ്ച നീളുന്ന തുറന്ന പിന്തുണ ത്രെഡിനേക്കാൾ മറ്റൊരു പ്ലാൻ പലപ്പോഴും വിലകുറഞ്ഞതാണ്. OpenVPN ലോഗിന്റെ ഒരു വരി പോലും വായിക്കുന്നതിന് മുമ്പ് ഇത് സ്ഥിരീകരിക്കുക. അല്ലെങ്കിൽ ഒരിക്കലും പാക്കറ്റ് കാണാത്ത നിയമങ്ങൾ ക്രമീകരിച്ച് വൈകുന്നേരം ചെലവഴിക്കും.

ഈ ഇന്റർഫേസിൽ MASQUERADE എന്ത് ചെയ്യുന്നുവെന്ന് തീരുമാനിക്കുക

സാധാരണ വെർച്വൽ മെഷീനിൽ സാധാരണ ഔട്ട്ഗോയിംഗ് നിയമം പ്രധാന ഇന്റർഫേസിൽ നിന്ന് POSTROUTING MASQUERADE ആണ്. OpenVZ കണ്ടെയ്നറിൽ കാണുന്ന ഉപകരണം പലപ്പോഴും venet0 ആണ്, അതായത് ഹോസ്റ്റ് നിയന്ത്രിക്കുന്ന വെർച്വൽ ഇന്റർഫേസ്, റൂട്ട് ചെയ്ത NIC അല്ല, MASQUERADE അവിടെ ട്യൂട്ടോറിയലുകൾ കരുതുന്നതുപോലെ എപ്പോഴും പ്രവർത്തിക്കുന്നില്ല.

പ്രവർത്തനക്ഷമമായ രൂപം ക്ലയന്റുകൾ ഇതിനകം എത്തുന്ന വിലാസത്തിലേക്കുള്ള വ്യക്തമായ വിവർത്തനമാണ്, ഇരു ദിശകളിലും ഫോർവേഡിംഗ് അനുവദിച്ചിരിക്കുന്നു. സർവർ കോൺഫിഗറേഷനിൽ നിന്ന് പൂൾ മാറ്റുന്നത് വിലാസം മാറ്റുന്നത്ര തന്നെ പ്രധാനമാണ്. ഒട്ടിക്കുന്നതിന് മുമ്പ് ഓരോ വരിയും വായിക്കുക.

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

ഫോർവേഡിംഗ് നിയമങ്ങളില്ലാതെ വിവർത്തനം ഇപ്പോഴും സംഭവിക്കുന്നു, കെർണൽ ഇപ്പോഴും ഫോർവേഡ് ചെയ്യാൻ വിസമ്മതിക്കുന്നു. ഈ സംയോജനം NAT നിയമത്തിന്റെ കൗണ്ടറുകൾ ഉയരുമ്പോൾ ക്ലയന്റിന് ഒന്നും ലഭിക്കാത്ത ആശയക്കുഴപ്പമുള്ള അവസ്ഥ സൃഷ്ടിക്കുന്നു. രണ്ട് FORWARD വരികളും ഒരേ ചെയിനിലെ ഏതെങ്കിലും വിശാലമായ drop നിയമത്തിന് മുമ്പ് നിൽക്കണം. ക്രമം കോൺഫിഗറേഷന്റെ ഭാഗമാണ്, നടപ്പാക്കലിന്റെ വിശദാംശമല്ല.

നിയമം ഒരു പൂളിലേക്കും ഒരു ഇന്റർഫേസിലേക്കും പരിമിതപ്പെടുത്തുക

രണ്ടാമത്തെ ലക്ഷണത്തിന് മറ്റൊരു കാരണമുണ്ട്: ഉറവിടമോ ഔട്ട്പുട്ടോ നിയന്ത്രണമില്ലാത്ത ഒരു POSTROUTING നിയമം. അത്തരം ഒരു നിയമം ഹോസ്റ്റ് വിടുന്ന ഓരോ പാക്കറ്റും വീണ്ടും എഴുതുന്നു.

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

പരിഹാരം എന്നത് പൊരുത്തം ടണൽ പൂളിലേക്കും ഔട്ട്ഗോയിംഗ് ഇന്റർഫേസിലേക്കും ചുരുക്കി, പിന്നീട് പലത് ഉൾക്കൊള്ളാൻ ഒരു നിയമം വിശാലമാക്കുന്നതിന് പകരം ഓരോ പൂളിനും ഒരു നിയമം ചേർക്കുക എന്നതാണ്.

നിയമങ്ങൾ സ്ഥിരമാക്കുക, അവ ഇനി ആർക്കൊക്കെ സ്വന്തമാണെന്ന് കണ്ടെത്തുക

കൈകൊണ്ട് ചേർത്ത നിയമങ്ങൾ റീബൂട്ടിൽ അപ്രത്യക്ഷമാകുന്നു, അതിനാൽ iptables-save ഉപയോഗിച്ച് സേവ് ചെയ്യുക അല്ലെങ്കിൽ ഇൻസ്റ്റാൾ ചെയ്തിടത്ത് netfilter-persistent വഴി നിയന്ത്രിക്കുക. OpenVPN ആരംഭിക്കുന്നതിന് മുമ്പ് പുനഃസ്ഥാപനം പ്രവർത്തിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. തുടർന്ന് സംഭവത്തിനിടയിൽ വിടവ് കണ്ടെത്തുന്നതിന് പകരം ഒരിക്കൽ ബോധപൂർവ്വം റീബൂട്ട് ചെയ്യുക.

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

കൗണ്ടറുകളും പകർത്തിയ ഒരു ഫ്ലോയും ഉപയോഗിച്ച് സ്ഥിരീകരിക്കുക

കണക്ട് ചെയ്ത ക്ലയന്റിൽ നിന്ന്, ബാഹ്യ സേവനം റിപ്പോർട്ട് ചെയ്യുന്ന പൊതു വിലാസം പരിശോധിക്കുക. അത് സർവറിന്റെ വിലാസവുമായി പൊരുത്തപ്പെടുന്നുവെങ്കിൽ വിവർത്തനം പ്രവർത്തിക്കുന്നു; ഇല്ലെങ്കിൽ പാക്കറ്റ് മറ്റൊരു വഴിയിലൂടെ പുറത്തുപോകുന്നു അല്ലെങ്കിൽ പുറത്തുപോകുന്നില്ല. തുടർന്ന് സർവറിൽ ഹോസ്റ്റ് ചെയ്ത സേവനവും പൊതു ഇന്റർനെറ്റിലെ ഒരു സേവനവും പരീക്ഷിക്കുക, കാരണം അവ ഒരേ നിയമ സമുച്ചയത്തിലൂടെ വ്യത്യസ്ത വഴികളിലൂടെ പോകുന്നു.

സർവറിൽ iptables -t nat -L -v -n ഉപയോഗിച്ച് NAT, FORWARD നിയമങ്ങളിലെ പാക്കറ്റ് കൗണ്ടറുകൾ വായിക്കുക, ഒരു ക്യാപ്ചറിൽ ഒരു ഫ്ലോ നിരീക്ഷിക്കുക. ക്യാപ്ചറിൽ ക്ലയന്റിന്റെ വിലാസം കാണുകയും പ്രതികരണം പിന്തുടരാതിരിക്കുകയും ചെയ്താൽ, വിടവ് മടങ്ങിവരുന്ന വഴിയിലോ ദാതാവിന്റെ ഫിൽട്ടറിംഗിലോ ആണ്, ക്ലയന്റ് പ്രൊഫൈലിൽ അല്ല. പകർത്തിയ ഉറവിടം നിയമം വിവർത്തനം ചെയ്യുന്ന വിലാസവുമായി താരതമ്യം ചെയ്യുക, കാരണം പൊരുത്തക്കേട് എന്നാൽ മറ്റൊരു നിയമം ആദ്യം പൊരുത്തപ്പെട്ടു എന്നാണ്. നിരീക്ഷിച്ച ഒരു ഫ്ലോ ഒരു പേജ് കോൺഫിഗറേഷൻ വായനയേക്കാൾ കൂടുതൽ തീർപ്പാക്കുന്നു.

പൂൾ, വിവർത്തനം ചെയ്ത വിലാസം, ഇന്റർഫേസിന്റെ പേര് എന്നിവ മാറ്റ രേഖയിൽ ഒരുമിച്ച് സൂക്ഷിക്കുക. ഒരു പൂളിന് ശരിയായ നിയമം അടുത്തതിനെ തെറ്റായി വിവർത്തനം ചെയ്യുന്നു.