VPN മാത്രമുള്ള iptables ഹോസ്റ്റ്: tun ഉപകരണത്തിന് പേരിടുക, tun+ അല്ല

-o tun+ എഴുതുന്നത് കൃത്യമായ നിർദ്ദേശം പോലെ തോന്നുമെങ്കിലും യഥാർത്ഥത്തിൽ കർണൽ ഉള്ള എല്ലാ ടണലിനും ബാധകമാകുന്ന ഒരു വൈൽഡ്കാർഡ് ആണ്. രണ്ടാമത്തെ VPN ക്ലയന്റ്, ഒരു കണ്ടെയ്നർ പാലം അല്ലെങ്കിൽ ക്രാഷ് ആയ സെഷൻ വിട്ടുപോയ ഇന്റർഫേസ് — എല്ലാം അതിനെ തൃപ്തിപ്പെടുത്തുന്നു, തുടർന്ന് ഹോസ്റ്റ് നയം തടയാൻ ഉദ്ദേശിച്ച ട്രാഫിക്കിന് അനുമതി നൽകുന്നു. താഴെയുള്ള നടപടിക്രമം ഒരു ഉപകരണ നാമം ഉറപ്പിക്കുന്നു, ടണൽ യഥാർത്ഥത്തിൽ രൂപപ്പെടുന്ന വിധത്തിൽ ഒഴിവുകൾ ക്രമീകരിക്കുന്നു, നിയമങ്ങൾ മോശമായി വീണാൽ തിരികെയുള്ള വഴി അവശേഷിപ്പിക്കുന്നു. ഓരോ ഘട്ടവും സ്വതന്ത്രമായി പിൻവലിക്കാവുന്നത്ര ചെറുതാണ്.

ഘട്ടം 1: ഇപ്പോഴുള്ള നിയമങ്ങൾ രേഖപ്പെടുത്തുക

ഡിഫോൾട്ട് നയം മാറ്റുന്നതിന് മുമ്പ് നിലവിലെ അവസ്ഥ സംരക്ഷിക്കുക, അങ്ങനെ റോൾബാക്ക് ഓർമയല്ല കമാൻഡ് ആകും. iptables-save > /root/iptables.pre ഓരോ പട്ടികയും നിങ്ങൾക്ക് പുനഃസ്ഥാപിക്കാവുന്ന ഫയലിലേക്ക് എഴുതുന്നു, കൂടാതെ നിങ്ങൾ സജ്ജീകരിക്കാൻ പോകുന്ന നയം അത് വഹിക്കുന്ന കണക്ഷൻ വീഴ്ത്തുമ്പോൾ തുറന്ന root സെഷനുള്ള രണ്ടാമത്തെ ടെർമിനൽ അമിതഭയമല്ല. നിങ്ങൾ വിദൂരത്തുനിന്ന് ജോലി ചെയ്യുന്നുവെങ്കിൽ, dead man switch ആയി flush-ഉം ഷെഡ്യൂൾ ചെയ്യുക.

തുടർന്ന് ഇന്റർഫേസുകൾ ലിസ്റ്റ് ചെയ്യുക, കാരണം നിങ്ങൾ അനുമാനിച്ച പേര് നിങ്ങൾ വായിക്കേണ്ടിയിരുന്ന പേരാണ്: ip -br link ഇപ്പോൾ എന്താണുള്ളതെന്ന് കാണിക്കുന്നു, ടണൽ ഉയരുന്നതുവരെ പ്രത്യക്ഷപ്പെടുകയുമില്ല. വായിക്കുമ്പോൾ തന്നെ ഉപകരണങ്ങളുടെ പേരുകൾ എഴുതിവയ്ക്കുക.

ഘട്ടം 2: ടണലിന് അതിന്റേതായ പേര് നൽകുക

OpenVPN ക്ലയന്റ് കോൺഫിഗറേഷനിൽ dev tun_work സ്വീകരിക്കുന്നു, തുടർന്ന് Linux tun0 അനുവദിക്കുന്നതിന് പകരം അതേ പേരിൽ ഇന്റർഫേസ് സൃഷ്ടിക്കുന്നു. മറ്റൊന്നും അതിന് അവകാശം ഉന്നയിക്കാത്തിടത്തോളം പേര് വീണ്ടും കണക്ട് ചെയ്യുമ്പോഴും സ്ഥിരമായി നിൽക്കുന്നു, ഉപകരണത്തെ പേരിടുന്ന നിയമത്തെ അർത്ഥവത്താക്കുന്നത് അതാണ്.

പേര് നിയന്ത്രിക്കാൻ കഴിയാത്തിടത്ത്, പകരം ടണൽ വിലാസത്തിലോ പാക്കറ്റ് മാർക്കിലോ പൊരുത്തപ്പെടുക. രണ്ടും പ്രവർത്തിക്കുന്നു, രണ്ടും വായിക്കാൻ ബുദ്ധിമുട്ടാണ്, ടണൽ വീണ്ടും അക്കമിടുമ്പോൾ രണ്ടും കൂടുതൽ നിശ്ശബ്ദമായി പരാജയപ്പെടുന്നു. ഏതായാലും ഒരു കാര്യത്തിൽ മാത്രം പൊരുത്തപ്പെടുക, ഏതാണെന്ന് വ്യക്തമാക്കുക.

ഘട്ടം 3: endpoint ഒഴിവ് ആദ്യം വച്ച് നയം എഴുതുക

VPN മാത്രമുള്ള ഹോസ്റ്റ് എന്നത് ചെറിയ ഒഴിവുപട്ടികയുള്ള ഡിഫോൾട്ട്-നിരാകരണ ഹോസ്റ്റാണ്, ഏറ്റവും പ്രധാനമായ ഒഴിവ് ടണലിനെ നിലനിൽക്കാൻ അനുവദിക്കുന്നതാണ്. ടണൽ-ഉപകരണ നിയമത്തിന് മുമ്പ് endpoint നിയമം വച്ച് ഈ ക്രമത്തിൽ അത് നിർമ്മിക്കുക, അങ്ങനെ ഹാൻഡ്ഷേക്കിന് പോകാൻ ഒരിടം ലഭിക്കും:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

റൗട്ടറിൽ അതിന് പിന്നിലുള്ള ക്ലയന്റുകൾക്കായി അതേ രൂപം FORWARD ചെയിനിലേക്ക് പോകുന്നു, റൗട്ടറിന്റെ സ്വന്തം ട്രാഫിക്കിന് സ്വന്തം നിയമങ്ങൾ വേണം. ഫോർവേഡ് ചെയ്ത പാക്കറ്റുകൾ മാത്രം ഉൾക്കൊള്ളുന്ന നിയമക്കൂട്ടം SSH-ഉം DNS-ഉം പഴയ വഴിയിൽ വിടുന്നു, ടണൽ ഉയരുന്ന നിമിഷം റൗട്ടർ അപ്രാപ്യമാകുന്നത് അങ്ങനെയാണ്.

ഘട്ടം 4: സാന്നിധ്യം മാത്രമല്ല, ക്രമവും പരിശോധിക്കുക

നിയമങ്ങൾ ക്രമത്തിൽ വിലയിരുത്തപ്പെടുന്നു, അതിനാൽ നേരത്തെ വരുന്ന ACCEPT പിന്നീട് ചേർത്ത REJECT-നെ വെറുതെ മറയ്ക്കുന്നു. established, related പൊരുത്തമാണ് പൊതുവായ ഇൻബൗണ്ട് വഴി തുറക്കാതെ നിങ്ങളുടെ സ്വന്തം ഔട്ട്ബൗണ്ട് അഭ്യർത്ഥനകൾക്കുള്ള ഉത്തരങ്ങൾ തിരികെ വരാൻ അനുവദിക്കുന്നത്, ടണൽ സ്വീകാരത്തിന് ശേഷം അത് വയ്ക്കുന്നത് ടണൽ വീണാലും സ്വന്തം ഇന്റർഫേസിൽ തിരിച്ചുവരുന്ന ട്രാഫിക് കടത്തിവിടുന്നു എന്നാണ് അർത്ഥം.

നിയമങ്ങളുടെ എണ്ണം ഒരു സ്ക്രീനിൽ വായിക്കാവുന്നത്ര ചെറുതായി നിർത്തുക. നിങ്ങൾക്ക് ഓഡിറ്റ് ചെയ്യാൻ കഴിയാത്ത നിയമക്കൂട്ടമാണ് മുകളിൽ ഒഴിവുകൾ ചേർത്ത് നിങ്ങൾ പരിഹരിക്കുക, ഡിഫോൾട്ട്-നിരാകരണ നയങ്ങൾ പതിയെ ഡിഫോൾട്ട്-അനുമതിയുടെ അരിക് നേടുന്നത് അങ്ങനെയാണ്. മാറ്റത്തിന് മുമ്പും ശേഷവും ACCEPT എണ്ണുക.

ഘട്ടം 5: ബൂട്ടും വിലാസ കുടുംബവും അതിജീവിക്കാൻ ചെയ്യുക

കൈകൊണ്ട് നൽകിയ നിയമങ്ങൾ റീബൂട്ടിൽ അപ്രത്യക്ഷമാകുന്നു, അതിനാൽ ഡിസ്ട്രിബ്യൂഷന്റെ ഫയർവാൾ സേവനത്തിൽ നിന്നോ ടണൽ ഇന്റർഫേസ് നിലവിൽ വന്ന ശേഷം പ്രവർത്തിക്കുന്ന unit-ൽ നിന്നോ അവ ലോഡ് ചെയ്യുക. OpenVPN തുടങ്ങുന്നതിന് മുമ്പ് പ്രവർത്തിക്കുന്ന സ്ക്രിപ്റ്റിൽ tun_work പരാമർശിക്കുന്നത് വീണ ട്രാഫിക്കിന്റെ ബൂട്ട് ലൂപ്പ് ഉണ്ടാക്കുന്ന പതിവ് വഴിയാണ്.

തുടർന്ന് IPv6 വെവ്വേറെ പരിശോധിക്കുക, കാരണം IPv4-നുള്ള നല്ല ഡിഫോൾട്ട്-നിരാകരണ നയം മറ്റേ കുടുംബത്തെപ്പറ്റി ഒന്നും പറയുന്നില്ല. IPv4 മാത്രം കൈകാര്യം ചെയ്യുന്ന ടണലിനെ ചുറ്റിപ്പോകാൻ ട്രാഫിക് കൊണ്ടുപോകാവുന്ന റൂട്ട് ഹോസ്റ്റിനുണ്ടോ എന്ന് ip -6 route പറയും, ip6tables-നോ nftables-നോ സ്വന്തം തുല്യമായ നിയമങ്ങൾ വേണം. നിയമക്കൂട്ടത്തിന്റെ സമമിതിയിൽ വിശ്വസിക്കുന്നതിന് പകരം IPv6-only ലക്ഷ്യത്തോടെ പരീക്ഷിക്കുക.

ഘട്ടം 6: പരിശോധിച്ച് പുനഃസ്ഥാപിക്കാൻ തയ്യാറാകുക

ടണൽ ഉയർത്തുക, ഉദ്ദേശിച്ച സേവനം പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കുക, തുടർന്ന് നയം നിരസിക്കേണ്ട എന്തെങ്കിലും പരീക്ഷിക്കുക. ഉത്തരം നിങ്ങളെ അത്ഭുതപ്പെടുത്തിയാൽ iptables-restore < /root/iptables.pre ഉപയോഗിച്ച് പുനഃസ്ഥാപിക്കുക, അതിനുശേഷം മാത്രം നിയമങ്ങൾ തിരുത്താൻ തുടങ്ങുക. സ്ഥിരതയും പരീക്ഷിച്ച പുനഃസ്ഥാപന വഴിയും ചേർന്നാൽ മാത്രമാണ് ഇത് രണ്ടുതവണ ചെയ്യാവുന്ന മാറ്റമാകുന്നത്.