ടണൽ വഴി വിദൂര /24 ലേക്ക് എത്തുക: NETMAP, DNAT അതോ റൂട്ട്?
NETMAP ഉപയോഗിച്ച് മുഴുവൻ പ്രിഫിക്സും മാപ്പ് ചെയ്യുക, ഓരോ ഹോസ്റ്റിനും DNAT നിയമങ്ങൾ ചേർക്കുക അല്ലെങ്കിൽ യഥാർത്ഥ ശ്രേണി റൂട്ട് ചെയ്യുക, കൂടാതെ വിദൂര വശം എന്ത് കാണണം, ആർക്ക് ട്രാഫിക് ആരംഭിക്കാം എന്നിവയുടെ അടിസ്ഥാനത്തിൽ തീരുമാനിക്കുക.
ടണൽ എൻഡ്പോയിന്റിന് പിന്നിലുള്ള ഒരു സബ്നെറ്റിലേക്ക് മൂന്ന് വഴികളിലൂടെ എത്താം, ഒരു മിനിറ്റ് വസ്തുതകൾ ശേഖരിച്ചാൽ സാധാരണയായി രണ്ടെണ്ണം ഒഴിവാക്കപ്പെടും. വസ്തുതകൾ ഇവയാണ്: അവിടെയുള്ള സർവറുകൾ ഉപയോക്താക്കളെ വേർതിരിച്ചറിയേണ്ടതുണ്ടോ, അവിടെ നിന്ന് ആരെങ്കിലും എപ്പോഴെങ്കിലും നിങ്ങളുടെ ശ്രേണിയിലേക്ക് ഡയൽ ചെയ്യുമോ, ഏത് കൈയ്ക്കാണ് വിദൂര റൂട്ടർ തിരുത്താൻ കഴിയുന്നത്. ഈ മൂന്നിനും ഉത്തരം നൽകിയാൽ ഡിസൈൻ സ്വയം തിരഞ്ഞെടുക്കപ്പെടും. ബാക്കിയുള്ളത് നിങ്ങൾ എൻഡ്പോയിന്റ് നടത്തുകയും അതിന്റെ ഫയർവാൾ തിരുത്തുകയും ചെയ്യാമെന്ന് അനുമാനിക്കുന്നു.
മൂന്ന് ഓപ്ഷനുകൾ, ഓരോന്നും യഥാർത്ഥത്തിൽ എന്താണ് മാറ്റുന്നത്
പ്രിഫിക്സ് മാപ്പിംഗ്, ഓരോ ഹോസ്റ്റിനുമുള്ള DNAT, റൂട്ട് ചെയ്ത പ്രിഫിക്സ് എന്നിവയെല്ലാം ഒരേ രണ്ട് ശ്രേണികൾക്കിടയിൽ പാക്കറ്റുകൾ നീക്കുന്നു, പക്ഷേ വ്യത്യസ്ത കാര്യങ്ങളാണ് മാറ്റുന്നത്. മാപ്പിംഗ് ഒരു അലിയാസ് ശ്രേണി കണ്ടുപിടിച്ച് പറക്കുന്നതിനിടയിൽ വിലാസങ്ങൾ ഗണിതശാസ്ത്രപരമായി മാറ്റിയെഴുതുന്നു. ഓരോ ഹോസ്റ്റിനുമുള്ള നിയമങ്ങളും മാറ്റിയെഴുതുന്നു, പക്ഷേ ഓരോ ലക്ഷ്യവും കൈകൊണ്ട് പേരിടുന്നു. റൂട്ട് ചെയ്ത പ്രിഫിക്സ് ഒന്നും മാറ്റിയെഴുതുന്നില്ല: പാക്കറ്റുകൾ യഥാർത്ഥ വിലാസങ്ങൾ നിലനിർത്തുന്നു, ആ വിലാസങ്ങൾ എവിടെയാണെന്ന് ഇരു അറ്റങ്ങളും യോജിക്കുന്നു.
| What the far side needs | Prefix mapping | Per-host DNAT | Routed prefix |
|---|---|---|---|
| Users visible to its logs | Only without source NAT | Same condition | Yes, unchanged |
| To start a connection toward you | No, alias is local | No, same reason | Yes, both ends route |
| To absorb a new host | Yes, arithmetic only | No, one rule per address | Yes, it simply routes |
| To require no config change | Yes, with source NAT | Yes, same condition | No, it needs a route back |
ഒഴിവാക്കൽ വിദൂര വശത്തുനിന്ന് തുടങ്ങുക, നിയന്ത്രണങ്ങൾ മാറ്റാൻ ഏറ്റവും പ്രയാസമുള്ളത് അവിടെയാണ്. അവിടെയുള്ള സർവർ ക്ലയന്റ് വിലാസങ്ങൾ ലോഗുകളിൽ എഴുതുന്നുണ്ടെങ്കിൽ, അവ അനുവദനീയമായ പട്ടികയുമായി താരതമ്യം ചെയ്യുന്നുണ്ടെങ്കിൽ, അല്ലെങ്കിൽ മറ്റൊരു സിസ്റ്റത്തിന് കൈമാറുന്നുണ്ടെങ്കിൽ, സ്രോതസ്സ് വിവർത്തനം ചെയ്യുന്നത് അതിന്റെ ഏക ഐഡന്റിഫയർ നശിപ്പിക്കുന്നു. വിദൂര വശവും ഉള്ളിലേക്ക് ഡയൽ ചെയ്യേണ്ടതുണ്ടെങ്കിൽ, വിവർത്തനം പൂർണ്ണമായും ഒഴിവാക്കപ്പെടും, കാരണം അലിയാസ് നിലവിലുണ്ടെന്ന് അവിടെ ആർക്കും അറിയില്ല. വിദൂര വശം അഭ്യർത്ഥനകൾക്ക് ഉത്തരം നൽകുന്നു മാത്രമാകുമ്പോൾ മാത്രമേ വിലകുറഞ്ഞ ഓപ്ഷനുകൾ സുരക്ഷിതമാകൂ.
പ്രിഫിക്സ് ജോടികൾ, എന്തുകൊണ്ട് വലുപ്പങ്ങൾ ഒത്തുപോകണം
NETMAP എന്നത് ഒരേ നീളമുള്ള പ്രിഫിക്സുകളുടെ ജോടിയിൽ പ്രവർത്തിക്കുന്ന nat പട്ടികയുടെ ലക്ഷ്യമാണ്. അതിനുള്ളിൽ ഓരോ വിലാസത്തിനും പട്ടികയില്ല: അത് പ്രിഫിക്സ് അഴിച്ചെടുത്ത്, ഹോസ്റ്റ് ബിറ്റുകൾ സൂക്ഷിച്ച് പുതിയ പ്രിഫിക്സിലേക്ക് വീണ്ടും ഘടിപ്പിക്കുന്നു, അതിനാൽ /24 /24-ലേക്ക് മാപ്പ് ചെയ്യപ്പെടുന്നു, ഒരിക്കലും /25-ലേക്ക് അല്ല. സ്ഥാനം ദിശ തീരുമാനിക്കുന്നു: PREROUTING-ലെ ലക്ഷ്യ പൊരുത്തം പാക്കറ്റ് എങ്ങോട്ട് പോകുന്നു എന്ന് മാറ്റിയെഴുതുന്നു, POSTROUTING-ലെ സ്രോതസ്സ് പൊരുത്തം അത് എവിടെ നിന്ന് വന്നു എന്ന് മാറ്റിയെഴുതുന്നു.
192.168.2.17-ലെ ഹോസ്റ്റ് നിങ്ങളുടെ ക്ലയന്റുകൾക്ക് 10.50.1.17 ആയി കാണപ്പെടുന്നു, അവസാന ഒക്ടെറ്റ് അലങ്കാരമല്ല — അത് ഇരുവശത്തും ഒരേ സംഖ്യയാണ്. നാളെ 192.168.2.40-ൽ ഒരു ഹോസ്റ്റ് ചേർക്കുക, അതിന്റെ അലിയാസ് 10.50.1.40 ആയിരിക്കും, തിരുത്താനുള്ള നിയമമില്ല.
ക്ലയന്റുകൾക്ക് അലിയാസ് ശ്രേണിക്കായി നിങ്ങളുടെ ബോക്സിലേക്ക് ചൂണ്ടുന്ന ഒരു റൂട്ട് ഇപ്പോഴും വേണം, അലിയാസ് അവർ ഇതിനകം എത്തുന്ന സബ്നെറ്റിനുള്ളിലാണെങ്കിൽ ഒഴികെ. ഗേറ്റ്വേയ്ക്ക് അലിയാസിനായി റൂട്ട് ആവശ്യമില്ല, കാരണം ലക്ഷ്യ വിവർത്തനം റൂട്ട് തിരച്ചിലിന് മുമ്പ് PREROUTING-ൽ നടക്കുന്നു. ഫോർവേഡിംഗും ഓണായിരിക്കണം, അല്ലെങ്കിൽ മാറ്റിയെഴുതിയ ശേഷം കെർണൽ പാക്കറ്റ് ഉപേക്ഷിക്കും. താഴെയുള്ള മൂന്ന് കമാൻഡുകൾ ക്ലയന്റുകൾ br0-ൽ, അലിയാസ് 10.50.1.0/24-ൽ, ടണൽ tun0-ൽ ഉള്ള ഒരു Debian ശൈലിയിലുള്ള ഗേറ്റ്വേയിലെ മുഴുവൻ ക്രമീകരണമാണ്.
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADEമറുപടി സ്വയം തിരിച്ചുള്ള വഴി കണ്ടെത്തണം
ലക്ഷ്യം മാറ്റിയെഴുതുന്നത് പാക്കറ്റ് എവിടെ എത്തിക്കപ്പെടും എന്ന് മാത്രം തീരുമാനിക്കുന്നു. വിദൂര സർവർ ഇപ്പോഴും തനിക്ക് എത്താവുന്ന ഒരു വിലാസത്തിന് ഉത്തരം നൽകണം, അത് ക്രമീകരിക്കാൻ രണ്ട് വഴികളുണ്ട്. മറുപടികൾ നിങ്ങളുടെ ബോക്സിലേക്ക് തിരികെ വരാൻ സ്രോതസ്സ് വിവർത്തനം ചെയ്യുക, അല്ലെങ്കിൽ സ്രോതസ്സ് അതേപടി വിട്ട് വിദൂര വശത്തിന് ക്ലയന്റ് ശ്രേണിക്ക് ഒരു റൂട്ട് നൽകുക.
പുറത്തേക്കുള്ള masquerade ആണ് ചെറിയ വഴി: POSTROUTING-ൽ ഒരു നിയമം, വിദൂര വശം നിങ്ങളുടെ ടണൽ വിലാസം കാണുന്നു, അതിനാൽ അതിന് സ്വന്തം റൂട്ട് ആവശ്യമില്ല. വില എന്നത് ഓരോ ഉപയോക്താവും ഒരൊറ്റ വിലാസത്തിലേക്ക് ചുരുങ്ങുന്നു, ഉപയോക്താവ് തിരിച്ചുള്ള ലോഗുകൾക്ക് അർത്ഥം നഷ്ടപ്പെടുന്നു. സ്രോതസ്സ് കേടുകൂടാതെ വിട്ടാൽ ആ വിവരം നിലനിൽക്കും, പക്ഷേ അപ്പോൾ വിദൂര സൈറ്റ് ക്ലയന്റ് ശ്രേണിയുടെ മറുപടികൾ ടണലിലൂടെ തിരികെ അയയ്ക്കണം.OpenVPN സർവറിൽ അത് push ചെയ്യുന്ന push "route 10.50.9.0 255.255.255.0", കൂടാതെ route 192.168.2.0 255.255.255.0 വരി.
ചെലവേറിയ പരാജയം ഓരോന്നിന്റെയും പകുതി ചെയ്യുന്നതാണ്. ചില ട്രാഫിക് masquerade ചെയ്യുമ്പോൾ വിദൂര വശം മറ്റ് ട്രാഫിക്കിന് തിരിച്ചുള്ള റൂട്ടും വഹിക്കുന്നുണ്ടെങ്കിൽ, മറുപടികൾ കണക്ഷൻ ട്രാക്കിംഗ് എൻട്രി ഒരിക്കലും കണ്ടിട്ടില്ലാത്ത ഇന്റർഫേസിൽ വരുന്നു. സർവർ സേവിച്ചതായി രേഖപ്പെടുത്തിയ ഒരു അഭ്യർത്ഥനയ്ക്ക് ക്ലയന്റ് ടൈംഔട്ട് റിപ്പോർട്ട് ചെയ്യുന്നു. ഒരു ഫ്ളോയുടെ രണ്ട് ദിശകളും ഒരേ netfilter ഇൻസ്റ്റൻസിലൂടെ കടന്നുപോകണം: ഒരു ഗേറ്റ്വേ വിവർത്തനം ചെയ്യുന്നു, രണ്ട് ഫയർവാളുകൾ തുടർച്ചയായി അല്ല.
conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -nഎൻട്രി രണ്ട് ദിശകളിലും വായിക്കുക: യഥാർത്ഥ tuple ലക്ഷ്യത്തിൽ നിങ്ങളുടെ അലിയാസ് സൂക്ഷിക്കുന്നു, മറുപടി tuple യഥാർത്ഥ വിലാസം വഹിക്കുന്നു. മറുപടി tuple ഇല്ലെങ്കിൽ, പ്രശ്നം നിയമമല്ല, തിരിച്ചുള്ള പാതയാണ്. PREROUTING കൗണ്ടറുകൾ ഒരിക്കലും നീങ്ങിയിട്ടില്ലെങ്കിൽ, പാക്കറ്റ് ആ hook-ൽ എത്തിയിട്ടില്ല.
കൂട്ടിയിടികളും ആദ്യം പ്രവർത്തിക്കുന്ന തിരച്ചിലും
രണ്ട് വ്യത്യസ്ത ശ്രേണികൾ കൂട്ടിയിടിക്കാം, രണ്ട് പരാജയങ്ങളും മോശം നിയമത്തെക്കാൾ തകർന്ന ടണലിനെപ്പോലെ തോന്നുന്നു. നിങ്ങൾ കണ്ടുപിടിക്കുന്ന അലിയാസ് മുഴുവൻ പാതയിലും ഉപയോഗിക്കപ്പെടാത്തതായിരിക്കണം, യഥാർത്ഥ വിദൂര ശ്രേണി നിങ്ങളുടെ നെറ്റ്വർക്കിൽ ഇതിനകം ഉണ്ടാകരുത്. ഡ്യൂപ്ലിക്കേറ്റ് ഇടയ്ക്കിടെ തെറ്റായ ഹോസ്റ്റിലേക്ക് ട്രാഫിക് ഉണ്ടാക്കുന്നു, അത് നിഷേധിക്കപ്പെട്ട കണക്ഷനെക്കാൾ രോഗനിർണയം ചെയ്യാൻ ബുദ്ധിമുട്ടാണ്. ഒരു നിയമം ചേർക്കുന്നതിന് മുമ്പ് റൂട്ടിംഗ് പട്ടികയോട് ചോദിക്കുക.
ഗേറ്റ്വേയിൽ, ip route get 192.168.2.17 ടണൽ ഉപകരണം പേരിടണം; ലോക്കൽ ബ്രിഡ്ജ് എന്നാൽ വിദൂര ശ്രേണി മറയ്ക്കപ്പെട്ടിരിക്കുന്നു, ഒരു nat നിയമവും അത് നന്നാക്കില്ല. നിങ്ങളുടെ നെറ്റ്വർക്ക് ഇതിനകം 192.168.2.0/24 ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, കൂട്ടിയിടിക്ക് മുകളിൽ മാപ്പിംഗ് അടുക്കിവയ്ക്കുന്നതിന് പകരം വിദൂര സൈറ്റ് പുനർനമ്പർ ചെയ്യുക.
യഥാർത്ഥ ക്ലയന്റിൽ നിന്ന് പരീക്ഷിച്ച്, പിന്നീട് സൂക്ഷിക്കുക
അലിയാസ് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന ഒരു യന്ത്രത്തിൽ നിന്ന് പരീക്ഷിക്കുക, ഗേറ്റ്വേയിൽ നിന്നല്ല, കാരണം ലോക്കലായി ഉണ്ടാക്കുന്ന ട്രാഫിക് PREROUTING-ലൂടെ ഒരിക്കലും അതേ രീതിയിൽ കടക്കുന്നില്ല. അലിയാസുള്ള ഒരു ഹോസ്റ്റിലേക്ക് ഒരു കണക്ഷൻ തുറന്ന് കൗണ്ടറുകളും conntrack എൻട്രിയും ഒരുമിച്ച് പ്രത്യക്ഷപ്പെടുന്നത് നിരീക്ഷിക്കുക, തുടർന്ന് അടച്ച് എൻട്രി പോകുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക. കാലഹരണപ്പെട്ട എൻട്രി പകുതി തുറന്ന കണക്ഷനെ സൂചിപ്പിക്കുന്നു, അതായത് സാധാരണയായി മറുപടി തിരികെ വന്നിട്ടില്ല.
curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17രണ്ടോ മൂന്നോ വിജയകരമായ കണക്ഷനുകൾ ഗണിതം തെളിയിക്കുന്നു, പക്ഷേ സ്ഥിരതയെക്കുറിച്ചോ അടുത്ത എൻജിനീയറെക്കുറിച്ചോ ഒന്നും പറയുന്നില്ല. ബൂട്ട് പ്രക്രിയ വായിക്കുന്നിടത്ത് നിയമങ്ങൾ സംരക്ഷിക്കുക, Debian-ലും Ubuntu-യിലും അത് iptables-save > /etc/iptables/rules.v4 netfilter-persistent പ്രവർത്തനക്ഷമമാക്കി എന്നാണ് അർത്ഥം. റീബൂട്ടിൽ അപ്രത്യക്ഷമാകുന്ന മാപ്പിംഗ് ഒന്നുമില്ലാത്തതിനെക്കാൾ മോശമാണ്, കാരണം തകരാർ കുറ്റപ്പെടുത്താൻ സമീപകാല മാറ്റമൊന്നുമില്ലാതെ വരുന്നു.
നിയമങ്ങൾക്കരികിൽ ഒരു കുറിപ്പ് വിടുക: അലിയാസ് ശ്രേണി, യഥാർത്ഥ ശ്രേണി, ജോടിയുടെ കാരണം, ഏത് വശത്തിന് തുടങ്ങാം. ആ കുറിപ്പ് ഒരു ഡിസൈനിനെ ആരും മായ്ക്കാൻ ധൈര്യപ്പെടാത്ത നിയമങ്ങളുടെ കൂമ്പാരത്തിൽ നിന്ന് വേർതിരിക്കുന്നു. പിന്നീടുള്ള ചോദ്യവും അത് തീർക്കുന്നു: വിദൂര സൈറ്റ് ഒരു ഹോസ്റ്റ് ചേർക്കുമ്പോൾ, ആരും ക്രമീകരിക്കാത്ത ഒരു വിലാസം ഇതിനകം ഉത്തരം നൽകുന്നു. വിദൂര വശത്തിന് തിരിച്ചുള്ള റൂട്ട് വേണമെന്ന് കുറിപ്പ് പറയുന്നുണ്ടെങ്കിൽ, masquerade നിയമം നീക്കുന്നത് കണക്ടിവിറ്റി തകർക്കുമെന്ന് അടുത്തയാൾക്ക് അറിയാം. ഇവിടെ ഡോക്യുമെന്റേഷൻ വിലകുറഞ്ഞതാണ്; രാത്രി മൂന്ന് മണിക്ക് NAT ആശ്രിതത്വം വീണ്ടും കണ്ടെത്തുന്നത് അല്ല.