രണ്ട് സൈറ്റ്, ഒരു സബ്‌നെറ്റ്, ഒരു WireGuard ഹബ്ബ്: ഇത് പ്രവർത്തിപ്പിക്കുക

രണ്ട് സൈറ്റുകളും ഒരേ LAN ശ്രേണി ഉപയോഗിക്കുന്നു, ഡിസൈൻ യഥാർത്ഥത്തിൽ തകർക്കുന്നത് ഓവർലാപ്പ് അല്ല. ഹബ്ബ് ലക്ഷ്യ വിലാസം മാത്രം ഉപയോഗിച്ച് സൈറ്റ് തിരഞ്ഞെടുക്കണം, രണ്ട് സമാന ലക്ഷ്യങ്ങൾ അതിന് തിരഞ്ഞെടുക്കാൻ ഒന്നും നൽകുന്നില്ല. ടണലിന് അനുയോജ്യമാക്കാൻ പ്രവർത്തിക്കുന്ന ഓഫീസ് പുനർനമ്പർ ചെയ്യുന്നത് സാധാരണയായി ഓരോ പ്രസിദ്ധീകരിച്ച സേവനത്തിനും ടണലിന് വഹിക്കാവുന്ന വേറിട്ട വിലാസം നൽകുന്നതിനേക്കാൾ മോശം ഇടപാടാണ്. താഴെയുള്ള ഡിസൈൻ ഓരോ സൈറ്റിൽ നിന്നും ഒരു HTTPS സേവനം മാത്രം പ്രസിദ്ധീകരിക്കുന്നു, മറ്റൊന്നുമില്ല.

ഓവർലാപ്പ് യഥാർത്ഥ പ്രശ്നമല്ലാത്തത് എന്തുകൊണ്ട്

WireGuard ലക്ഷ്യത്തിന്റെ അടിസ്ഥാനത്തിൽ കൈമാറ്റം ചെയ്യുന്നു: ഒരു peer ന്റെ AllowedIPs ഏത് peer ന് പാക്കറ്റ് ലഭിക്കുമെന്ന് തീരുമാനിക്കുന്നു. രണ്ട് peer ഒരുമിച്ച് 10.10.7.0/24 പ്രഖ്യാപിക്കാൻ കഴിയില്ല, അവയിലൊന്ന് ഓരോ അന്വേഷണവും നേടുന്നില്ലെങ്കിൽ. ഇത് peer പട്ടികയുടെ സ്വഭാവമാണ്, ടണലിന്റേതല്ല, അതിനാൽ ഇവിടെ പരിഹാരം വിലാസ പദ്ധതിയാണ്, റൂട്ടിംഗ് തന്ത്രമല്ല.

പദ്ധതി എന്നത് LAN പ്രഖ്യാപിക്കുന്നത് പൂർണ്ണമായി നിർത്തുകയാണ്. പകരം ഓരോ സേവനത്തിനും alias പ്രഖ്യാപിക്കുക, ഓരോ സൈറ്റിനും ഒരു വിലാസം, ഓരോ സൈറ്റിന്റെയും ഗേറ്റ്‌വേ ആ alias അതിന്റെ യഥാർത്ഥ ആപ്ലിക്കേഷനിലേക്ക് വിവർത്തനം ചെയ്യട്ടെ.

ഉപയോക്താവ് രണ്ട് അദ്വിതീയ വിലാസങ്ങൾ റൂട്ട് ചെയ്യുന്നു, അവ്യക്തമായ പ്രിഫിക്സ് ഒരിക്കലും കാണുന്നില്ല, രണ്ട് ഓഫീസുകളിലും ഒന്നും മാറുന്നില്ല. ഇത് അതിർത്തിയും സത്യസന്ധമായി പറയുന്നു: നിങ്ങൾ ഓരോ സൈറ്റിൽ നിന്നും ഒരു HTTPS സേവനം പ്രസിദ്ധീകരിക്കുകയാണ്, രണ്ട് നെറ്റ്‌വർക്കുകൾ ലയിപ്പിക്കുകയല്ല. തുടർന്നുള്ള നിയമങ്ങൾ ചെറുതായി തുടരുന്നു കാരണം പ്രസ്താവന സങ്കുചിതമാണ്. വിശാലമായ പ്രസ്താവനയ്ക്ക് വിശാലമായ നിയമങ്ങൾ വേണ്ടിവരും, ഈ ഡിസൈനുകൾ സങ്കീർണ്ണമാകുന്നത് അങ്ങനെയാണ്.

ഓരോ സൈറ്റിനും ഉപയോക്താവിന് റൂട്ട് ചെയ്യാവുന്ന alias നൽകുക

ഉപയോക്താവിന്റെ മെഷീനിൽ, ഹബ്ബിൽ അല്ലെങ്കിൽ രണ്ട് LAN-കളിൽ ഏതെങ്കിലും ഒന്നുമായി കൂട്ടിയിടിക്കാത്ത ശ്രേണിയിൽ നിന്ന് വിലാസങ്ങൾ തിരഞ്ഞെടുക്കുക. ഇവിടെ ഹബ്ബ് 10.66.0.1, ഉപയോക്താവ് 10.66.0.10, ഗേറ്റ്‌വേകൾ 10.66.0.21 ഉം 10.66.0.22 ഉം, രണ്ട് alias 10.77.1.20 ഉം 10.77.2.20 ഉം ആണ്. ഹബ്ബ് ഓരോ alias-ഉം അത് ഉടമസ്ഥതയിലുള്ള peer വഴി പ്രസിദ്ധീകരിക്കുന്നു, അതിനാൽ ഒരു alias-ലേക്ക് അയച്ച പുറത്തേക്കുള്ള പാക്കറ്റ് ബന്ധപ്പെട്ട സൈറ്റ് വഴി മാത്രമേ പുറത്തുവരൂ:

[Interface]
Address = 10.66.0.1/32
ListenPort = 51820
PrivateKey = HUB_KEY

[Peer]
PublicKey = USER_PUBLIC_KEY
AllowedIPs = 10.66.0.10/32

[Peer]
PublicKey = SITE_A_PUBLIC_KEY
AllowedIPs = 10.66.0.21/32, 10.77.1.20/32

[Peer]
PublicKey = SITE_B_PUBLIC_KEY
AllowedIPs = 10.66.0.22/32, 10.77.2.20/32

ഉപയോക്തൃ ഭാഗത്തിന് രണ്ട് alias മാത്രം മതി, ഇത് ക്ലയന്റ് കോൺഫിഗറേഷനെ രണ്ട് LAN പ്രിഫിക്സുകളിൽ നിന്നും മുക്തമാക്കുന്നു. ആ കോൺഫിഗറേഷനിൽ ഒരു യഥാർത്ഥ LAN-നെക്കുറിച്ചും പരാമർശമില്ല:

[Interface]
Address = 10.66.0.10/32
PrivateKey = USER_KEY

[Peer]
PublicKey = HUB_PUBLIC_KEY
Endpoint = hub.example.net:51820
AllowedIPs = 10.77.1.20/32, 10.77.2.20/32
PersistentKeepalive = 25

ഓരോ ഗേറ്റ്‌വേയും ഹബ്ബും ഉപയോക്തൃ ഉറവിടവും പ്രഖ്യാപിക്കുന്നു, മറ്റൊന്നുമില്ല, അതിനാൽ ഒരു സൈറ്റ് ഒരിക്കലും മറ്റേ സൈറ്റിന്റെ LAN അറിയുന്നില്ല. Keepalive സൈറ്റിന്റെ അപ്‌ലിങ്കിൽ NAT മാപ്പിംഗ് നിലനിർത്തുന്നു; അത് ട്രാഫിക്കിന് അനുമതി നൽകുന്നില്ല, എന്ത് സ്വീകരിക്കണമെന്ന് ഫയർവാൾ ഇപ്പോഴും തീരുമാനിക്കുന്നു. ഒരു ഗേറ്റ്‌വേയുടെ കോൺഫിഗറേഷൻ മറ്റൊന്നിലേക്ക് പകർത്തുന്നത് ശരിയാണ്, സ്വകാര്യ കീ, ഇന്റർഫേസ് വിലാസം, alias എന്നിവയെല്ലാം മാറുന്നിടത്തോളം.

ഹബ്ബ് തന്റെ രണ്ട് peer-കൾക്കിടയിൽ എന്ത് അനുവദിക്കണം

ഹബ്ബ് തന്റെ സ്വന്തം രണ്ട് peer-കൾക്കിടയിൽ പാക്കറ്റുകൾ കൈമാറ്റം ചെയ്യുന്നു, ഇത് forward ശൃംഖലയിലെ തീരുമാനമാണ്, ഇൻപുട്ട് തീരുമാനമല്ല. പ്ലാറ്റ്‌ഫോമിന്റെ സാധാരണ സംവിധാനത്തിലൂടെ IPv4 കൈമാറ്റം പ്രവർത്തനക്ഷമമാക്കുക, തുടർന്ന് ഡിസൈനിന് ആവശ്യമുള്ള ജോഡികൾ മാത്രം അനുവദിക്കുക.

താഴെയുള്ള നിയമം ഉപയോക്താവിന് ഒരു alias-ഉം ഒരു പോർട്ടും അനുവദിക്കുന്നു, കണക്ഷൻ ട്രാക്കിംഗ് വഴി തിരിച്ചുവരുന്ന ട്രാഫിക്കും അനുവദിക്കുന്നു. forward പാതയിലെ മറ്റെല്ലാം ഇത് ഉപേക്ഷിക്കുന്നു, അതാണ് കാര്യം:

nft add table inet hub_transit
nft add chain inet hub_transit forward '{ type filter hook forward priority 0 ; policy drop ; }'
nft add rule inet hub_transit forward ct state established,related accept
nft add rule inet hub_transit forward iifname wg0 oifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 accept

രണ്ട് വിശദാംശങ്ങൾ പറയേണ്ടതാണ്, കാരണം അവ നിശബ്ദ പരാജയങ്ങൾ ഉണ്ടാക്കുന്നു. ഒരു അടിസ്ഥാന ശൃംഖലയിലെ accept മറ്റൊന്നിലെ drop-നെ അതിലംഘിക്കുന്നില്ല, അതിനാൽ ഇത് നിലവിലുള്ള നയവുമായി ലയിപ്പിക്കുക, അതിനൊപ്പം ലോഡ് ചെയ്യരുത്. ഉറവിട വിലാസം വ്യക്തിയെയല്ല, ഉപകരണത്തെ തിരിച്ചറിയുന്നു; ആപ്ലിക്കേഷൻ പ്രാമാണീകരണം നെറ്റ്‌വർക്ക് അനുമതിയിൽ നിന്ന് വേർതിരിക്കുക.

alias യഥാർത്ഥ വിലാസമാകുന്നിടം

സൈറ്റ് A 10.77.1.20-ലേക്കുള്ള അഭ്യർത്ഥന സ്വീകരിക്കുന്നു, ലക്ഷ്യം യഥാർത്ഥ ആപ്ലിക്കേഷനിലേക്ക് പുനർലേഖനം ചെയ്യുന്നു, ഉറവിടം സ്വന്തം LAN വിലാസത്തിലേക്ക് പുനർലേഖനം ചെയ്യുന്നു, അതുവഴി ടണലിലേക്ക് റൂട്ട് ഇല്ലാതെ മറുപടിക്ക് മടങ്ങാം. രണ്ട് വിവർത്തനങ്ങളും ഒരിടത്ത് ചെയ്യുന്നത് ബാക്കി നെറ്റ്‌വർക്കിനെ alias-നെക്കുറിച്ച് അജ്ഞമാക്കുന്നു. താഴെയുള്ള നിയമങ്ങളാണ് മുഴുവൻ സംവിധാനം:

nft add table ip site_a_nat
nft add chain ip site_a_nat pre '{ type nat hook prerouting priority -100 ; policy accept ; }'
nft add chain ip site_a_nat post '{ type nat hook postrouting priority 100 ; policy accept ; }'
nft add rule ip site_a_nat pre iifname wg0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.77.1.20 dnat to 10.10.7.20:443
nft add rule ip site_a_nat post iifname wg0 oifname lan0 tcp dport 443 ip saddr 10.66.0.10 ip daddr 10.10.7.20 snat to 10.10.7.2

തുടർന്ന് സൈറ്റ് A-യുടെ forward നയം വിവർത്തനം ചെയ്ത ഫ്ലോ ടണൽ ഇന്റർഫേസിൽ നിന്ന് LAN ഇന്റർഫേസിലേക്ക്, കൂടാതെ തിരിച്ചുള്ള ദിശയും അനുവദിക്കണം. forward hook ലക്ഷ്യം കാണുന്നത് ലക്ഷ്യ വിവർത്തനത്തിന് ശേഷവും ഉറവിട പുനർലേഖനത്തിന് മുൻപും ആണ്, അതിനാലാണ് നിയമം യഥാർത്ഥ ആപ്ലിക്കേഷന്റെ വിലാസം പേരെടുത്ത് പറയുന്നത്. ഒരു നിയമം ഒന്നുമായും പൊരുത്തപ്പെടാത്തതായി തോന്നുമ്പോഴെല്ലാം ഈ രണ്ട് hook-കളും ഈ ക്രമത്തിൽ വായിക്കുക. alias-നെതിരെ എഴുതിയ forward നിയമത്തിന് ഒരിക്കലും പൊരുത്തപ്പെടാനാവില്ല, കാരണം ആ hook-ൽ alias ഇനി നിലവിലില്ല.

സൈറ്റ് B ഇത് സ്വന്തം alias-ഉം സ്വന്തം കീയും ഉപയോഗിച്ച് ആവർത്തിക്കുന്നു. സൈറ്റ് A-യുടെ സ്വകാര്യ കീ വീണ്ടും ഉപയോഗിക്കരുത്, കാരണം രണ്ട് peer ഒരു ഐഡന്റിറ്റി പങ്കിടുന്നത് കാണാൻ പ്രയാസവും ഫയൽ പകർത്തി ഉണ്ടാക്കാൻ എളുപ്പവുമായ കോൺഫിഗറേഷൻ പിഴവാണ്. രണ്ട് ഗേറ്റ്‌വേ രേഖകളും വ്യത്യാസപ്പെടേണ്ട മൂല്യങ്ങളൊഴികെ ഒരുപോലെ സൂക്ഷിക്കുക, അവലോകനത്തിൽ വ്യത്യാസം തെളിയട്ടെ. പകർത്തിയ ഫയലാണ് ആ പിഴവിന്റെ സാധാരണ ഉറവിടം.

ഉറവിട പുനർലേഖനത്തിന് വിലയുണ്ട്. ആപ്ലിക്കേഷൻ ഗേറ്റ്‌വേയെ തന്റെ ക്ലയന്റായി കാണുന്നു, അതിനാൽ ഏത് ഉപയോക്താവ് കണക്റ്റ് ചെയ്തുവെന്ന് ഇനി ലോഗുകൾ കാണിക്കുന്നില്ല. ഗേറ്റ്‌വേയുടെ ഓഡിറ്റ് ട്രെയിൽ സൂക്ഷിക്കുക, വിവർത്തനം നീക്കിയ നെറ്റ്‌വർക്ക് ഐഡന്റിറ്റി നികത്താൻ ആപ്ലിക്കേഷൻ ലോഗിൻ ദുർബലമാക്കരുത്.

പ്രസിദ്ധീകരിച്ച രണ്ട് പേരുകളും പ്രതികരിക്കുന്നുവെന്ന് തെളിയിക്കുന്നത് എങ്ങനെ

ഓരോ alias-നും DNS നാമം നൽകി ആ നാമത്തിന് ആപ്ലിക്കേഷനും സർട്ടിഫിക്കറ്റും കോൺഫിഗർ ചെയ്യുക, കാരണം വിവർത്തനം റീഡയറക്ടുകളോ ഉൾച്ചേർത്ത കേവല URL-കളോ പുനർലേഖനം ചെയ്യുന്നില്ല. ഓരോ സൈറ്റിനും ഒരു നാമം ഉപയോഗിക്കുക, സർട്ടിഫിക്കറ്റ് പൊരുത്തക്കേട് ഒരിക്കലും റൂട്ടിംഗ് പിഴവായി തെറ്റിദ്ധരിക്കപ്പെടരുത്.

യഥാർത്ഥ ക്ലയന്റിൽ നിന്ന് പരീക്ഷിക്കുക, ഏത് സൈറ്റ് പ്രതികരിച്ചുവെന്ന് ഉറപ്പാക്കുക, അനധികൃത പോർട്ടും പരീക്ഷിക്കുക. ഏതെങ്കിലും NAT മാറ്റത്തിന് ശേഷം പുതിയ കണക്ഷനുകൾ ഉപയോഗിക്കുക, സ്ഥാപിത അവസ്ഥ പഴയ മാപ്പിംഗ് നിലനിർത്തുന്നു:

wg show wg0 allowed-ips
sudo nft list ruleset
curl -sS -o /dev/null -w "%{http_code}\n" https://site-a.example.net/

ആദ്യ കമാന്റിൽ alias ശൂന്യമോ അപ്രതീക്ഷിതമോ ആണെങ്കിൽ ഏതെങ്കിലും ഫയർവാൾ നിയമം പ്രസക്തമാകുന്നതിന് മുൻപേ peer തിരഞ്ഞെടുപ്പ് തെറ്റാണ്. alias ശരിയാണെങ്കിലും പേര് ഇപ്പോഴും പരാജയപ്പെടുന്നെങ്കിൽ പ്രശ്നം DNS-ലേക്കും സർട്ടിഫിക്കറ്റുകളിലേക്കും മാറിയിരിക്കുന്നു. രണ്ട് പേരുകളും പ്രതികരിച്ച് മൂന്നാം പോർട്ട് അടഞ്ഞു നിൽക്കുമ്പോൾ, ഡിസൈൻ താൻ പറയുന്നത് ചെയ്യുന്നു: സങ്കുചിതമായി പ്രസിദ്ധീകരിച്ച രണ്ട് സേവനങ്ങൾ, ലയിപ്പിച്ച രണ്ട് LAN അല്ല.