CGNAT പോർട്ടുകൾ തടയുമ്പോൾ VPS വഴി വീട്ടിലെ സെർവർ പ്രസിദ്ധീകരിക്കുന്നത്

ബ്രൗസറിൽ നിന്ന് വീട്ടിലെ യന്ത്രം വരെയുള്ള വഴി: ലൈൻ CGNAT-ന് പിന്നിലാണെന്ന് തെളിയിക്കുക, DNS VPS-ലേക്ക് ചൂണ്ടുക, ഒരു പോർട്ടിൽ DNAT ചെയ്യുക, മടങ്ങിവരുന്ന വഴി ശരിയാക്കുക, പുറത്തുനിന്ന് പരിശോധിക്കുക.

ഞാൻ പുറത്തുനിന്ന് തുടങ്ങി, ഒരു ഉപയോക്താവ് ചെയ്യുന്നതുപോലെ: പേര് മൊബൈൽ ഡാറ്റയിൽ ഫോണിന്റെ ബ്രൗസറിൽ ടൈപ്പ് ചെയ്ത്, കണക്ഷൻ സമയം തീരുന്നതുവരെ തൂങ്ങിക്കിടക്കുന്നത് കണ്ടു. പേര് പരിഹരിക്കപ്പെട്ടിരുന്നു, അതായത് DNS ശരിയായിരുന്നു. വീട്ടിലെ റൗട്ടറിന്റെ പോർട്ട്-ഫോർവേഡിംഗ് പേജും അവസാനിക്കുന്ന വഴിയായിരുന്നു, കാരണം അതിന്റെ WAN വിലാസം 100.64.31.42 കാണിച്ചു, ഇത് ഒരു ദാതാവ് എന്നെ ഇന്റർനെറ്റിൽ നിന്ന് അയക്കുന്ന വിലാസമല്ല. ഈ സംഖ്യ മുഴുവൻ തകരാറും വിശദീകരിക്കുന്നു: ലൈൻ carrier-grade NAT-ന്റെ പിന്നിലാണ്, അതിനാൽ തുരങ്കത്തിന്റെ എന്റെ വശത്തുള്ള പൊതു വിലാസം ദാതാവിന്റേതാണ്. ഇനി ഞാൻ ആ കുടുങ്ങിയ ടാബിൽ നിന്ന് മറുപടി നൽകുന്ന സേവനത്തിലേക്ക് നടന്ന വഴി വരുന്നു.

ക്ലൈന്റിൽ നിന്ന് തുടങ്ങി അകത്തേക്ക് പോകുക

ഏതെങ്കിലും നിയമം മാറ്റുന്നതിന് മുമ്പ് ശൃംഖല എവിടെ നിൽക്കുന്നു എന്ന് തെളിയിക്കുക. ലാപ്ടോപ്പിൽ ഞാൻ dig +short files.example.net പ്രവർത്തിപ്പിച്ച് VPS വിലാസം തിരികെ ലഭിച്ചു, ഇത് എന്റെ യന്ത്രത്തിലെ പഴയ DNS ഒഴിവാക്കി. തുടർന്ന് curl -v --connect-timeout 5 files.example.net:5022 നിരസിക്കപ്പെടുന്നതിന് പകരം സമയം തീർന്ന് നിന്നു. ഈ വ്യത്യാസം പ്രധാനമാണ്: സമയം തീരുന്നത് സാധാരണയായി പാക്കറ്റുകൾ വഴിയിൽ വലിച്ചെറിയപ്പെടുന്നു എന്നാണ് അർത്ഥം, അതേസമയം നിരസിക്കൽ എന്നാൽ എന്തോ മറുപടി നൽകി ഇല്ല എന്ന് പറഞ്ഞു.

അകത്തേക്കുള്ള അടുത്ത ചുവട് VPS തന്നെയായിരുന്നു. ss -ltnp 5022-ൽ കേൾക്കുന്ന ഒന്നും കാണിച്ചില്ല, ഇത് DNAT നിയമം ഉണ്ടാകുന്നതിന് മുമ്പ് പ്രതീക്ഷിച്ചതാണ്. അതേ യന്ത്രത്തിൽ wg show (അല്ലെങ്കിൽ OpenVPN-ന് ip -br a show tun0) വീട്ടിലെ peer പ്രവർത്തിക്കുന്നുണ്ടെന്നും പുതിയ handshake ഉണ്ടെന്നും സ്ഥിരീകരിച്ചു. peer പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ ഒരു NAT നിയമവും സഹായിക്കില്ല, വീട്ടിലെ റൗട്ടറിന്റെ VPN പേജിലെ പച്ച വെളിച്ചം ഒന്നും അർത്ഥമാക്കുന്നില്ല.

വീട്ടിലെ ലൈൻ യഥാർത്ഥത്തിൽ CGNAT-ന് പിന്നിലാണെന്ന് സ്ഥിരീകരിക്കുക

റൗട്ടർ തന്റെ WAN ഇന്റർഫേസിൽ റിപ്പോർട്ട് ചെയ്യുന്ന വിലാസം പുറത്തുള്ള ഒരു സേവനം കാണുന്നതുമായി താരതമ്യം ചെയ്യുക. 100.64.0.0/10-ൽ ഉള്ളതെല്ലാം, അതായത് 100.64.x.x മുതൽ 100.127.x.x വരെ, RFC 6598-ലെ പങ്കിട്ട വിലാസ ശ്രേണിയാണ്, ഇന്റർനെറ്റിൽ നിന്ന് എത്തിച്ചേരാൻ കഴിയില്ല. റൗട്ടർ സാധാരണ സ്വകാര്യ വിലാസം ഉണ്ടെന്ന് അവകാശപ്പെടുകയും പൊതു തിരയൽ അപ്രസക്തമായ എന്തെങ്കിലും തിരികെ നൽകുകയും ചെയ്യുമ്പോഴും നിങ്ങൾ അതേ നിഗമനത്തിൽ എത്തും. CGNAT ലൈനിൽ അടുത്ത lease വരെ മാത്രം നിലനിൽക്കുന്ന പൊതു വിലാസവും ഉണ്ടാകാം, അതിനാൽ പോർട്ട് ഫോർവേഡിംഗ് ഒരു മണിക്കൂർ പ്രവർത്തിക്കുന്നതുപോലെ തോന്നി പിന്നീട് നിശ്ശബ്ദമായി മരിക്കുന്നു.

ചില ദാതാക്കൾ യഥാർത്ഥ പൊതു വിലാസം നൽകുന്നു, പക്ഷേ താമസ ഹിസ്റ്റങ്ങളിൽ വരുന്ന 80, 443 പോർട്ടുകൾ തടയുന്നു. നിങ്ങളുടെ സേവനം വെബ് മാത്രമാണെങ്കിൽ, WAN വിലാസം യഥാർത്ഥത്തിൽ പൊതുവാണെങ്കിൽ, relay നിർമ്മിക്കുന്നതിന് മുമ്പ് പിന്തുണയോട് ചോദിക്കുക. അല്ലെങ്കിൽ, താഴെയുള്ള രൂപകൽപ്പന ഓരോ പോർട്ടിനും തുല്യമായി ബാധകമാണ്, പരീക്ഷണം റൗട്ടർ ഭാഗത്ത് നിർത്തുന്നത് മൂല്യവത്താണ്: ദാതാവിന്റെ നെറ്റ്വർക്കിലെ വിവർത്തകൻ കണക്ഷൻ നിങ്ങളുടെ WAN ഇന്റർഫേസിൽ എത്തുന്നതിന് മുമ്പ് തന്നെ അത് അവസാനിപ്പിക്കുന്നു.

പേര് VPS വിലാസത്തിലേക്ക് ചൂണ്ടുക

DNS ട്രാഫിക് മുന്നോട്ട് അയക്കുന്നില്ല, അതിനാൽ സേവനത്തിന്റെ A റെക്കോർഡിൽ VPS-ന്റെ പൊതു വിലാസം ഉണ്ടായിരിക്കണം. 192.168.1.20-ലേക്കുള്ള A റെക്കോർഡ് ഇതിനകം VPN-നുള്ളിൽ ഉള്ള ക്ലൈന്റുകൾക്ക് മാത്രം ഉപയോഗപ്രദമായി പരിഹരിക്കപ്പെടുന്നു; ഇന്റർനെറ്റിൽ നിന്ന് അത് ആർക്കും റൂട്ട് ചെയ്യാൻ കഴിയാത്ത വിലാസത്തിലേക്ക് പരിഹരിക്കപ്പെടുന്നു. VPS-ന്റെ സ്വന്തം ഭരണ പ്രവേശനത്തിന് ഞാൻ പ്രത്യേക പേര് സൂക്ഷിക്കുന്നു, ഒരു റെക്കോർഡ് ഏത് ഹോസ്റ്റുമായി ബന്ധപ്പെട്ടതാണെന്ന് ഒരിക്കലും ആശയക്കുഴപ്പത്തിലാകാതിരിക്കാൻ.

VPS-ഉം വീട്ടിലെ യന്ത്രവും HTTP നൽകുന്നുവെങ്കിൽ, ഓരോന്നിനും അതിന്റേതായ പേര് നൽകുക, ആരാണ് മറുപടി നൽകുന്നതെന്ന് VPS തീരുമാനിക്കട്ടെ. രണ്ടിനെയും ഒരു പേരിൽ ചേർത്ത്, പ്രോക്സി ശരിയായ backend തിരഞ്ഞെടുക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നത്, തെറ്റായ ഹോസ്റ്റിൽ പകുതി ദിവസം പിശക് തിരയാനുള്ള കൃത്യമായ വഴിയാണ്.

ഒരു പോർട്ട് DNAT-ൽ, SSH 22-ൽ നിൽക്കട്ടെ

നേരിട്ടുള്ള ഓപ്ഷൻ VPS-ൽ ലക്ഷ്യ NAT ആണ്. പ്രവർത്തിക്കുന്ന കെർണലിന് forwarding പ്രവർത്തനക്ഷമമാക്കി, നിയമത്തിൽ വീട്ടിലെ സെർവറിന്റെ തുരങ്ക വിലാസം സൂക്ഷിക്കുക, അതിന്റെ LAN വിലാസമല്ല:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp -d 198.51.100.10 --dport 5022 -j DNAT --to-destination 10.8.0.2

VPS-ലേക്കുള്ള SSH 22-ൽ വിടുക, മറ്റൊരു പോർട്ട്, ഉദാഹരണത്തിന് 5022, വീട്ടിലെ യന്ത്രത്തിലേക്ക് അയക്കുക. 22 ഓഫ് ആയ യന്ത്രത്തിലേക്ക് അയച്ചാൽ അത് ശരിയാക്കാൻ കഴിയുമായിരുന്ന ഏക വഴി നഷ്ടപ്പെടും. അതേ യുക്തി പ്രോക്സിക്കും ബാധകമാണ്: VPS-ന്റെ ഭരണ പോർട്ട് relay നിയമങ്ങൾക്ക് പുറത്ത് സൂക്ഷിക്കുക.

നിയമങ്ങൾ പ്രവർത്തിക്കാൻ തുടങ്ങിയാൽ അവ സ്ഥിരമാക്കുക. Debian അല്ലെങ്കിൽ Ubuntu-യിൽ apt install iptables-persistent ഉം തുടർന്ന് netfilter-persistent save ഉം അവ /etc/iptables/rules.v4-ൽ എഴുതുന്നു. firewalld ഉള്ള ഹോസ്റ്റിൽ അതിന് തുല്യമായത് സോണിലെ സ്ഥിരമായ പോർട്ട് ഫോർവേഡിംഗ് ആണ്, അത് പ്രാബല്യത്തിൽ വരുന്നതിന് മുമ്പ് firewall-cmd --reload ആവശ്യമാണ്. മെമ്മറിയിൽ മാത്രം ജീവിക്കുന്ന നിയമങ്ങൾ ദാതാവിന്റെ ആദ്യ അറ്റകുറ്റപ്പണി റീബൂട്ടിൽ അപ്രത്യക്ഷമാകുന്നു, സാധാരണയായി മോശം സമയത്ത്.

തിരികെ വരുന്ന വഴി ശരിയാക്കുക അല്ലെങ്കിൽ അതിന്റെ ആവശ്യകത ഒഴിവാക്കുക

DNAT ലക്ഷ്യം മാത്രമേ വീണ്ടും എഴുതുന്നുള്ളൂ. വീട്ടിലെ സെർവർ കണക്ഷൻ യഥാർത്ഥ ക്ലൈന്റ് വിലാസത്തിൽ നിന്ന് കാണുന്നു, അതിന്റെ സ്ഥിര മാർഗം വീട്ടിലെ റൗട്ടറിലേക്കാണെങ്കിൽ മറുപടി വീട്ടിലെ WAN വഴി പുറത്തുപോകുന്നു, അവിടെ ദാതാവിന്റെ വിവർത്തകൻ അത് വലിച്ചെറിയുന്നു. ഈ അസമത്വമാണ് ഞാൻ നേരിട്ട രണ്ടാമത്തെ തകരാർ, DNAT നിയമം പൂർണ്ണമായും ശരിയായി തോന്നിയ ശേഷം.

രണ്ട് തിരുത്തലുകൾ പ്രവർത്തിക്കുന്നു. വീട്ടിലെ യന്ത്രത്തിന് നയ-മാർഗം നൽകുക, തുരങ്കത്തിൽ നിന്ന് വരുന്ന ട്രാഫിക് തുരങ്കത്തിലൂടെ തന്നെ തിരികെ പോകട്ടെ:

ip rule add from 10.8.0.2 table 100
ip route add default dev wg0 table 100

അല്ലെങ്കിൽ VPS ഉറവിടം വീണ്ടും എഴുതട്ടെ, മറുപടിക്ക് അത് എത്താൻ കഴിയുന്ന വിലാസം ഉണ്ടാകട്ടെ, conntrack അതിനെ പുറത്തുപോകുമ്പോൾ തിരിച്ചിടട്ടെ:

iptables -t nat -A POSTROUTING -d 10.8.0.2 -p tcp --dport 5022 -j SNAT --to-source 10.8.0.1

SNAT പതിപ്പ് യഥാർത്ഥ ക്ലൈന്റ് വിലാസം വീട്ടിലെ സെർവറിൽ നിന്ന് മറയ്ക്കുന്നു, അതിനാൽ ആപ്ലിക്കേഷൻ ലോഗുകൾ peer ആയി 10.8.0.1 കാണിക്കുന്നു. യഥാർത്ഥ വിലാസം ആപ്ലിക്കേഷൻ പാളിയിൽ കൈമാറുക, അല്ലെങ്കിൽ ഓരോ ക്ലൈന്റിനുമുള്ള ലോഗിംഗ് നഷ്ടം സ്വീകരിക്കുക, പക്ഷേ ഒരു സംഭവത്തിനിടയിൽ കണ്ടെത്തുന്നതിന് പകരം ബോധപൂർവം തീരുമാനിക്കുക.

മുഴുവൻ വഴിയും പുറത്തുനിന്ന് പരിശോധിക്കുക

VPS അല്ലാത്ത, വീടുമല്ലാത്ത നെറ്റ്വർക്കിൽ നിന്ന് സ്ഥിരീകരിക്കുക: മൊബൈൽ ഡാറ്റയിലെ ഫോൺ, അല്ലെങ്കിൽ മറ്റെവിടെയെങ്കിലും വിലകുറഞ്ഞ shell. nc -vz files.example.net 5022 വിജയകരമായ കണക്ഷൻ റിപ്പോർട്ട് ചെയ്യണം, openssl s_client -connect files.example.net:443 -servername files.example.net പൊതു പേരിനുള്ള സർട്ടിഫിക്കറ്റ് കാണിക്കണം. തുടർന്ന് ദാതാവിന്റെ സുരക്ഷാ ഗ്രൂപ്പ് അല്ലെങ്കിൽ ക്ലൗഡ് ഫയർവാൾ പരിശോധിക്കുക. ഒരിക്കലും പാക്കറ്റ് കാണാത്ത DNAT നിയമം സാധാരണയായി ഹോസ്റ്റിന് ഒരു പാളി മുകളിൽ തടയപ്പെടുന്നു.

അവസാനമായി, തുരങ്കം വീഴുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് തീരുമാനിക്കുക. DNAT നിയമം കണക്ഷനുകൾ സ്വീകരിച്ചുകൊണ്ടിരിക്കും, അവയെ നിശ്ശബ്ദമായി മരിച്ച തുരങ്കത്തിലേക്ക് അയക്കും, ഇത് കേടായ സേവനത്തെപ്പോലെ തന്നെ തോന്നും. VPS-ൽ peer പ്രവർത്തിക്കുന്നതുവരെ പോർട്ട് നിരസിക്കുന്ന ആരോഗ്യ പരിശോധന ഏതാനും വരികളുടെ ചെലവാണ്, ഒരു മണിക്കൂർ ഊഹം ലാഭിക്കുന്നു. അതിനുശേഷം നിയമങ്ങൾ തിരുത്തുന്നത് നിർത്തി, അതിനെ വിശ്വിക്കുന്നതിന് മുമ്പ് ഒരു ദിവസം നിരീക്ഷിക്കുക.

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