പൊതു ഗേറ്റ്‌വേ ഇപ്പോൾ തന്നെ UDP 51820 ൽ WireGuard, 22 ൽ SSH, ഇന്റർനെറ്റിൽ നിന്ന് എത്തിച്ചേരേണ്ട ഒരു അപ്ലിക്കേഷൻ എന്നിവ പ്രവർത്തിപ്പിക്കുന്നു. പ്രലോഭിപ്പിക്കുന്ന നിയമം എല്ലാ പോർട്ടും പിയറിലേക്ക് കൈമാറി കാര്യം തീർന്നു എന്ന് പറയുന്നു. WireGuard ഗേറ്റ്‌വേയിൽ അത്തരം ഒരു നിയമം ടണലിന്റെ സ്വന്തം ഗതാഗതം പിടിച്ചെടുത്ത് അത് അവസാനിപ്പിക്കുന്ന യന്ത്രത്തിൽ നിന്ന് നിങ്ങളെ പുറത്താക്കാം. പ്രസിദ്ധീകരണം എന്നത് കൺട്രോൾ പ്ലെയിൻ ഒഴിവാക്കലുള്ള റൂട്ടിംഗ് തീരുമാനമാണ്, ഒരു DNAT വരിയല്ല.

പൊതു പ്രവേശനമോ ടണൽ പ്രവേശനമോ: ഒന്ന് തിരഞ്ഞെടുക്കുക

ഒരു സേവനം പ്രസിദ്ധീകരിക്കുന്നത് ഇന്റർനെറ്റിലേക്ക് പുതിയൊരു പ്രവേശന കേന്ദ്രം സൃഷ്ടിക്കുന്നു. ഒരു പിയറിന് VPN അംഗത്വം നൽകുന്നതിന് സമാനമല്ല ഇത്, കാരണം സന്ദർശകൻ ഒരിക്കലും ടണലിൽ പ്രവേശിക്കുന്നില്ല, ഗേറ്റ്‌വേ ബാക്കെൻഡിന്റെ പൊതുമുഖമായി മാറുന്നു. ആ വ്യത്യാസമാണ് നിയമത്തിന്റെ പ്രേക്ഷകരെയും അതിന്റെ സർട്ടിഫിക്കറ്റിനെയും നിർണ്ണയിക്കുന്നത്.

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

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

ഒരു പോർട്ട് അകത്തേക്ക്, ഒരു ബാക്കെൻഡ് പുറത്തേക്ക്

ഒരു പൊതു പോർട്ടും ഒരു ബാക്കെൻഡ് സേവനവും ഉപയോഗിക്കുക. ഈ ഉദാഹരണത്തിൽ eth0 പൊതു വിലാസം 198.51.100.20 വഹിക്കുന്നു, ഗേറ്റ്‌വേയുടെ ടണൽ വിലാസം 10.200.0.1 ആണ്, പിയർ അപ്ലിക്കേഷൻ 10.200.0.7 ൽ പ്രവർത്തിപ്പിക്കുന്നു. പൊതു TCP 9443 പിയറിന്റെ TCP 8443 ലേക്ക് മാപ്പ് ചെയ്യുന്നു:

iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1

SNAT നിയമം വിവർത്തനം ചെയ്ത ബാക്കെൻഡിനും യഥാർത്ഥ പൊതു ലക്ഷ്യത്തിനും ഒത്തുപോകുന്നു, അതിനാൽ അതേ ബാക്കെൻഡ് സേവനത്തിലേക്കുള്ള മറ്റൊരു കണക്ഷൻ ഈ മാപ്പിംഗിന് പുറത്ത് തുടരുന്നു. ഇത് സന്ദർശകന്റെ വിലാസം പിയറിൽ നിന്ന് മറയ്ക്കുന്നു, ഉറവിടം സംരക്ഷിക്കുന്ന റൂട്ട് ചെയ്ത മടക്കത്തെ പ്രത്യേക രൂപകൽപ്പനയാക്കുന്ന ആ കൈമാറ്റമാണ് അത്. iptables വിപുലീകരണങ്ങളുടെ റഫറൻസ് രണ്ട് ലക്ഷ്യങ്ങളെയും അവയുടെ പൊരുത്തപ്പെടുത്തൽ ഓപ്ഷനുകളെയും വിവരിക്കുന്നു.

ഫോർവേഡിംഗ് ഇപ്പോഴും സജീവമാക്കണം, ഫിൽട്ടർ ചെയിനിന് വിവർത്തനം ചെയ്ത ലക്ഷ്യത്തിനും പോർട്ടിനും സ്ഥാപിത മറുപടികൾക്കും അനുമതി വേണം. DNAT-ന് ശേഷം FORWARD ചെയിൻ വിവർത്തനം ചെയ്ത ലക്ഷ്യം കാണുന്നു, അതിനാൽ പൊതു വിലാസത്തിനെതിരെ എഴുതിയ നിയമം ഫോർവേഡ് ചെയ്ത പാക്കറ്റുമായി ഒത്തുപോകുന്നില്ല. അനുമതി ബാക്കെൻഡ് ട്യൂപ്പിളിനെതിരെ എഴുതുക, പൊതുവിനെതിരെയല്ല.

പിയർ സേവന കണക്ഷൻ ഗേറ്റ്‌വേയുടെ ടണൽ വിലാസത്തിൽ നിന്ന് സ്വീകരിച്ച് മറുപടി ടണലിലൂടെ തിരികെ അയയ്ക്കണം. അതിന്റെ AllowedIPs യഥാർത്ഥത്തിൽ ലഭിക്കുന്ന ഉറവിടത്തിന് അനുമതി നൽകണം, ഉറവിട വിവർത്തനത്തിൽ അത് ഗേറ്റ്‌വേയുടെ ടണൽ വിലാസമാണ്, കൂടാതെ ഓരോ പിയറിലും വിശാലമായ 0.0.0.0/0 എൻട്രി ഈ രൂപകൽപ്പനയ്ക്ക് ആവശ്യമില്ല. മടക്ക ട്രാഫിക് വീഴ്ത്തുന്നത് ആ വിലാസം തന്റെ പട്ടികയിൽ നിന്ന് വിട്ടുപോകുന്ന പിയർ, അല്ലെങ്കിൽ സന്ദർശകന്റെ സ്വന്തം വിലാസം പകരം അയയ്ക്കുന്ന ഉറവിട-സംരക്ഷക രൂപകൽപ്പനയാണ്, അതിനാൽ നിങ്ങളുടെ നിയമത്തിലുള്ളതല്ല, പിയർ യഥാർത്ഥത്തിൽ കാണുന്ന ഉറവിടം പരിശോധിക്കുക.

ഗേറ്റ്‌വേയുടെ സ്വന്തം ലിസണറുകളെ നിയമത്തിന് പുറത്ത് നിർത്തുക

പാക്കറ്റ് പ്രാദേശികമാണോ എന്ന് യന്ത്രം തീരുമാനിക്കുന്നതിന് മുമ്പ് ലക്ഷ്യ വിവർത്തനം നടക്കുന്നു, അതിനാൽ UDP 51820 എല്ലാ പിയർ കണക്ഷനുകളും പിടിച്ചിരിക്കുന്ന പ്രോസസ്സിലല്ല, പിയറിൽ എത്തിച്ചേരാം. നിയമം വിജയകരമായി ലോഡ് ചെയ്യപ്പെടുന്നു, ടണൽ മരിക്കുന്നു, ഇത് പിയർ വശത്തുനിന്ന് വായിക്കാൻ പ്രയാസമുള്ള ഒരു പരാജയമാണ്.

SSH, മോണിറ്ററിംഗ് ഏജന്റുകൾ, ഗേറ്റ്‌വേയിലുള്ള മറ്റേതൊരു സേവനവും ഇതേ വിധേയത്വം പങ്കിടുന്നു. എല്ലാം കൈമാറുന്ന നിയമം കൺട്രോൾ പ്ലെയിനെ പ്രസിദ്ധീകരിച്ച അപ്ലിക്കേഷനിൽ നിന്ന് വേർതിരിക്കുന്നില്ല, മാറ്റത്തിന് ശേഷമുള്ള ആദ്യ റീബൂട്ടാണ് പുറത്താക്കൽ വ്യക്തമാകുന്ന നിമിഷം. എല്ലാം ഉൾക്കൊള്ളുന്ന നിയമം താൻ നിശബ്ദമായി ഏറ്റെടുക്കുന്ന സേവനത്തെക്കുറിച്ച് മുന്നറിയിപ്പ് നൽകുന്നില്ല. അടുത്ത കണക്ഷൻ പരാജയപ്പെടുമ്പോഴാണ് നിങ്ങൾ അത് കണ്ടെത്തുന്നത്.

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

വിശാലമായ TCP, UDP ഫോർവേഡിംഗും എല്ലാ പ്രോട്ടോക്കോളുകളുമല്ല. ICMP, IPv6, പാത്ത് MTU ഫീഡ്ബാക്ക്, VPN-ന്റെ പുറം ഗതാഗതം എന്നിവയ്ക്ക് സ്വന്തം നയം വേണം, TCP യും UDP യും ഉൾക്കൊള്ളുന്ന നിയമം ആ കേസുകളെ സ്വതവേയുള്ള ചെയിനിന് വിടുന്നു.

നിയമങ്ങൾ എഴുതുന്നതിന് മുമ്പ് മാതൃക തിരഞ്ഞെടുക്കുക

നാല് രൂപങ്ങൾ മിക്ക ഗേറ്റ്‌വേ പ്രസിദ്ധീകരണങ്ങളെയും ഉൾക്കൊള്ളുന്നു, നിങ്ങൾ എത്ര സേവനങ്ങൾ നടത്തുന്നു, എത്ര കൺട്രോൾ പ്ലെയിൻ അപകടസാധ്യത സഹിക്കാം എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു തിരഞ്ഞെടുപ്പ്. താഴെയുള്ള പട്ടിക അവയെ ഏറ്റവും ഇടുങ്ങിയതിൽ നിന്ന് ഏറ്റവും വിശാലമായതിലേക്ക് ക്രമീകരിക്കുന്നു.

ModelWhat it protectsCostUse when
Narrow port forwardEvery other listener, including the VPNOne rule per serviceFew services, stable ports
Catch-all with reserved portsPorts named in the exception listRule order becomes criticalMany services and disciplined review
Separate public addressControl address fully isolatedProvider must supply the addressHigh-value publication
VPN-only accessNo public entry at allVisitors need the tunnelAdmin interfaces and internal tools

പിന്നീട് കൂടുതൽ സേവനങ്ങൾ പ്രതീക്ഷിച്ചാലും ഇടുങ്ങിയ മാതൃകയിൽ തുടങ്ങുക. അത് ഓഡിറ്റ് ചെയ്യാൻ ഏറ്റവും എളുപ്പമാണ്, ഇടുങ്ങിയ നിയമങ്ങളുടെ ഒരു കൂട്ടത്തെ പരിശോധിച്ച എല്ലാം ഉൾക്കൊള്ളുന്ന നിയമമാക്കി മാറ്റുന്നത് വിശാലമായ നിയമം ഏത് ലിസണറെ പിടിച്ചു എന്ന് കണ്ടെത്തുന്നതിനേക്കാൾ ലളിതമാണ്. ഏത് മാതൃക തിരഞ്ഞെടുത്താലും നിയമങ്ങൾ ഫയർവാൾ ഉടമയുടെ പക്കൽ സൂക്ഷിക്കുക. അതേ ചെയിനുകൾ കൈകാര്യം ചെയ്യുന്ന UFW അല്ലെങ്കിൽ nftables കോൺഫിഗറേഷന് അരികിൽ iptables വരികൾ പ്രയോഗിക്കുന്നത് ബൂട്ട് ക്രമത്തിനനുസരിച്ച് മാറുന്ന നയം സൃഷ്ടിക്കുന്നു.

പ്രസിദ്ധീകരണവും കൺട്രോൾ പാത്തും രണ്ടും തെളിയിക്കുക

അംഗീകൃത ഹോസ്റ്റ്നാമും അതിന് സാധുവായ സർട്ടിഫിക്കറ്റും ഉപയോഗിച്ച് അംഗീകൃത ബാഹ്യ ക്ലയന്റിൽ നിന്ന് പരിശോധിക്കുക. ഏത് ബാക്കെൻഡാണ് ഉത്തരം നൽകിയതെന്ന് സ്ഥിരീകരിച്ച്, ബന്ധമില്ലാത്ത പൊതു പോർട്ടുകൾ നിഷേധിക്കപ്പെട്ടിരിക്കുന്നുവെന്ന് പരിശോധിക്കുക. അപ്രാപ്തമാക്കിയ സർട്ടിഫിക്കറ്റ് പരിശോധന വിജയകരമായ HTTPS പരീക്ഷയല്ല, തെറ്റായ ബാക്കെൻഡിൽ എത്തുന്ന കണക്ഷൻ പരാജയപ്പെട്ടതിനേക്കാൾ മോശമാണ്.

അതിന് ശേഷം ഗേറ്റ്‌വേ തന്നെ പരിശോധിക്കുക: ഒരു WireGuard പിയർ ബന്ധിപ്പിക്കുക, SSH സെഷൻ തുറക്കുക, മോണിറ്ററിംഗ് ഇപ്പോഴും റിപ്പോർട്ട് ചെയ്യുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. കൺട്രോൾ പ്ലെയിൻ തകർന്നിരിക്കുമ്പോൾ പ്രസിദ്ധീകരിച്ച സേവനം പ്രവർത്തിച്ചേക്കാം, അതിനാൽ രണ്ട് പരിശോധനകളും ഒരേ മാറ്റ വിൻഡോയിൽ വേണം. നിയമങ്ങൾ പ്രതീക്ഷിത ക്രമത്തിൽ വീണ്ടും പ്രയോഗിക്കുന്നുവെന്ന് തെളിയിക്കാൻ ഒരിക്കൽ റീബൂട്ട് ചെയ്യുക, തുടർന്ന് പ്രസിദ്ധീകരണം നീക്കി നീക്കം ചേർക്കലുമായി യഥാർത്ഥത്തിൽ ഒത്തുപോകുന്നുവെന്ന് സ്ഥിരീകരിക്കുക. തുടക്കത്തിൽ ധാരാളം കൂട്ടിച്ചേർക്കലുകളും അപൂർണ്ണമായ നീക്കലും, അങ്ങനെയാണ് താൽക്കാലിക പരീക്ഷണം സ്ഥിരമായ തുറവിയാകുന്നത്.

അനുബന്ധ ലേഖനങ്ങൾ