നിങ്ങളുടെ പൊതു Linux സേവനം എന്തുകൊണ്ട് VPN വഴി മറുപടി നൽകുന്നു

സോക്കറ്റിൽ ഏത് ഇന്റർഫേസ് അഭ്യർത്ഥന കൊണ്ടുവന്നു എന്ന് ഓർക്കുന്ന ഒന്നുമില്ല, അതിനാൽ പൂർണ്ണ ടണൽ VPN-ന്റെ ഡിഫോൾട്ട് റൂട്ടിന് WAN-ൽ പെടേണ്ട ഒരു മറുപടി പിടിച്ചെടുക്കാം. സേവനം ഇൻബൗണ്ട് ഇന്റർഫേസ് അവഗണിക്കുകയല്ല; Linux പ്രാദേശികമായി സൃഷ്ടിച്ച മറുപടിയെ ലക്ഷ്യവും ഉറവിട നയവും അനുസരിച്ച് റൂട്ട് ചെയ്യുന്നു. ഉറവിട അധിഷ്ഠിത നിയമത്തിന് പകരം സേവനത്തിന്റെ മറുപടികൾ മാത്രം പൂർണ്ണ WAN പട്ടികയിലൂടെ അയയ്ക്കാം, സാധാരണ പുറത്തേക്കുള്ള ഒഴുക്ക് ടണലിൽ വിടാം. മറുപടി തെറ്റായ വഴിയിലൂടെ പോകുമ്പോഴും പോർട്ട് തുറന്നിരിക്കുന്നു, അതുകൊണ്ടാണ് ലക്ഷണം ഏകപക്ഷീയമായി തോന്നുന്നത്.

തെറ്റായ ധാരണ: മറുപടികൾ വന്ന ഇന്റർഫേസിനെ പിന്തുടരുന്നു

eth0-ൽ എത്തുന്ന പാക്കറ്റ് eth0-ൽ തന്നെ പോകണം എന്ന് യുക്തിസഹമായി തോന്നുന്നു. അവസ്ഥയില്ലാത്ത പാക്കറ്റ് ഫിൽട്ടറുകൾ അങ്ങനെ എഴുതാം, ഇൻബൗണ്ട് വശത്തെ tcpdump അഭ്യർത്ഥന പ്രതീക്ഷിക്കുന്നിടത്ത് കൃത്യമായി കാണിക്കുന്നു. ഹോസ്റ്റ് സ്വയം സൃഷ്ടിക്കുന്ന ട്രാഫിക്കിന് റൂട്ടിംഗ് അങ്ങനെ പ്രവർത്തിക്കുന്നില്ല.

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

അതുകൊണ്ടാണ് ലക്ഷണം ഏകപക്ഷീയമായി തോന്നുന്നത്: അഭ്യർത്ഥനകൾ വരുന്നു, മറുപടികൾ അപ്രത്യക്ഷമാകുന്നു. അതുകൊണ്ടുതന്നെ ഇൻബൗണ്ട് പോർട്ടിന് ഫയർവാൾ നിയമം ചേർത്താലും ഒന്നും മാറുന്നില്ല. പാക്കറ്റ് അകത്തേക്കുള്ള വഴിയിൽ തടയപ്പെടുന്നില്ല; പുറത്തേക്കുള്ള വഴിയിൽ മറ്റെവിടെയോ റൂട്ട് ചെയ്യപ്പെടുന്നു. ഉറവിട-നിർദ്ദിഷ്ട തിരയലിലൂടെ മറുപടി പിന്തുടരുക, വഴിത്തിരിവ് ദൃശ്യമാകും.

കേർണൽ യഥാർത്ഥത്തിൽ എന്താണ് റൂട്ട് ചെയ്യുന്നത്: ഉറവിട വിലാസം

നിങ്ങൾക്ക് വേണ്ട ഹാൻഡിൽ സേവനം മറുപടികൾക്കായി ഉപയോഗിക്കുന്ന പ്രാദേശിക വിലാസമാണ്. eth0 വിലാസം ഉദാഹരണമായി 192.0.2.10/24 ഉം ഗേറ്റ്‌വേ 192.0.2.1 ഉം ഉള്ള ഹോസ്റ്റിൽ ആ വിലാസം ഇന്റർഫേസിൽ ഉണ്ട്. ക്ലൗഡ് VM-ൽ പൊതു വിലാസം മുകളിൽ പരിഭാഷപ്പെടുത്തിയതും അതിഥിയിൽ ഇല്ലാത്തതുമാകാം, അതിനാൽ ഹോസ്റ്റിന് യഥാർത്ഥത്തിൽ ഉള്ള വിലാസം ഉപയോഗിക്കുക.

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

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

തുടർന്ന് ഉറവിടം അനുസരിച്ച് ഒരു പട്ടിക തിരഞ്ഞെടുക്കുക. ഇതിനകം 192.0.2.10 വഹിക്കുന്ന മറുപടികളുമായി നിയമം പൊരുത്തപ്പെടുന്നു, അതായത് നിങ്ങൾ ഒഴിവാക്കാൻ ആഗ്രഹിക്കുന്ന പ്രാദേശികമായി അവസാനിച്ച ട്രാഫിക്. ഫോർവേഡ് ചെയ്ത ട്രാഫിക്കും മറ്റ് പ്രാദേശിക വിലാസങ്ങളിൽ നിന്നുള്ള പാക്കറ്റുകളും പൊരുത്തപ്പെടുന്നില്ല.

പകുതി ഡിഫോൾട്ടല്ല, പൂർണ്ണമായ റിട്ടേൺ പട്ടിക നിർമ്മിക്കുക

ഡിഫോൾട്ട് റൂട്ട് മാത്രമുള്ള പട്ടിക മതിയാകില്ല. കേർണലിന് ഇപ്പോഴും ഗേറ്റ്‌വേ പരിഹരിക്കേണ്ടതുണ്ട്, ആ പരിഹാരത്തിന് അതേ പട്ടികയിൽ ബന്ധിപ്പിച്ച പ്രിഫിക്സ് വേണം. ആ പ്രിഫിക്സ് ഇല്ലാത്ത പട്ടിക ഡിഫോൾട്ട് റൂട്ട് ശരിയായി തോന്നിയാലും ഗേറ്റ്‌വേ പരിഹാരത്തിൽ പരാജയപ്പെടുന്നു. രണ്ടും ചേർത്തതിന് ശേഷം ഉറവിട നിയമം പട്ടികയിലേക്ക് തിരിച്ചുവിടുക:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

ഉദാഹരണം പകർത്തുന്നതിന് പകരം യഥാർത്ഥ പ്രിഫിക്സും ഗേറ്റ്‌വേയും ഉപയോഗിക്കുക. ഓൺ-ലിങ്ക് ഗേറ്റ്‌വേയോടെ /32 ആയി ക്രമീകരിച്ച ക്ലൗഡ് ഇന്റർഫേസിന് വേറെ ബന്ധിപ്പിച്ച റൂട്ട് വേണം, തെറ്റായ പ്രിഫിക്സിൽ നിന്ന് നിർമ്മിച്ച പട്ടിക ആദ്യ ഹോപ്പിൽ പരാജയപ്പെടുന്നു. src ആട്രിബ്യൂട്ട് ആ റൂട്ടിന്റെ മുൻഗണനാ ഉറവിടം പറയുന്നു; അത് ഉറവിട നിയമത്തെ മാറ്റിസ്ഥാപിക്കുന്നില്ല.

ക്രമവും പ്രധാനമാണ്. കുറഞ്ഞ മുൻഗണനാ നമ്പറുള്ള വിശാല നിയമം ആദ്യം വിലയിരുത്തപ്പെടുന്നു, അതിനാൽ ഈ ട്രാഫിക്കിനെ പ്രധാന പട്ടികയിലേക്ക് തിരിച്ചയയ്ക്കാവുന്ന ഏത് നിയമത്തിനും മുമ്പ് ഉറവിട നിയമത്തിൽ എത്തണം. ചേർത്തതിന് ശേഷം ip rule show ഉപയോഗിച്ച് മുൻഗണനകൾ പരിശോധിക്കുക, ബൂട്ടിൽ മാത്രമല്ല.

ഉറവിട-നിർദ്ദിഷ്ട തിരയലിലൂടെ പരിശോധിക്കുക

സേവന വിലാസത്തിൽ നിന്ന് ഒരു പരീക്ഷണ ലക്ഷ്യത്തിലേക്ക് റൂട്ട് ചെയ്യാൻ കേർണലിനോട് ആവശ്യപ്പെടുക. മറുപടിയിൽ ടണലല്ല, eth0-ഉം WAN ഗേറ്റ്‌വേയും പേരെടുത്ത് പറയണം:

ip -4 route get 198.51.100.25 from 192.0.2.10

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

അന്തിമ റൂട്ടുകളും നിയമവും ഇന്റർഫേസിന്റെ ഉടമയായ നെറ്റ്‌വർക്ക് മാനേജറുടെ കീഴിൽ വയ്ക്കുക. വിലാസ മാറ്റങ്ങൾ, DHCP പുതുക്കൽ, VPN വീണ്ടും കണക്ട് ചെയ്യൽ എന്നിവയെല്ലാം കേർണൽ അവസ്ഥ മാറ്റിയെഴുതുന്നു, കൈകൊണ്ട് ചേർത്ത നിയമം അടുത്ത സംഭവത്തിന് ശേഷം അപ്രത്യക്ഷമാകുന്നു അല്ലെങ്കിൽ പഴയ ഗേറ്റ്‌വേയിലേക്ക് ചൂണ്ടുന്നു.

ഈ ഒഴിവാക്കൽ എവിടെ നിൽക്കുന്നു

ഒരു ഉറവിട വിലാസത്തിൽ നിന്ന് പ്രാദേശികമായി അവസാനിച്ച ട്രാഫിക്കിന് നിയമം ഒഴിവ് നൽകുന്നു. Docker പ്രസിദ്ധീകരിച്ച പോർട്ടുകൾ, DNAT അല്ലെങ്കിൽ ഹോസ്റ്റ് വഴി ഫോർവേഡ് ചെയ്യുന്ന സേവനങ്ങൾ ഇതിൽ ഉൾപ്പെടുന്നില്ല, കാരണം ആ പാക്കറ്റുകൾ ഫോർവേഡ് ട്രാഫിക്കായി റൂട്ട് ചെയ്യപ്പെടുന്നു, ഹോസ്റ്റിന്റെ പ്രാദേശിക ഉറവിടം അതേ രീതിയിൽ ഒരിക്കലും വഹിക്കുന്നില്ല. അത്തരം രൂപകൽപ്പനകൾക്ക് സാധാരണയായി ഇൻഗ്രെസിൽ വയ്ക്കുന്ന ഒരു മാർക്കും ആ മാർക്കുമായി പൊരുത്തപ്പെടുന്ന നിയമവും വേണം.

ഹോസ്റ്റിന്റെ പൊതു വിലാസം ഇന്റർഫേസിൽ പ്രത്യക്ഷപ്പെടുത്താനും ഇത് സഹായിക്കുന്നില്ല. മുകളിലെ NAT ആ വിലാസത്തിന്റെ ഉടമയാകുമ്പോൾ, ആ NAT പ്രതീക്ഷിക്കുന്ന വഴിയിലൂടെ തന്നെ മറുപടി പുറത്തുപോകണം, അതുകൊണ്ടാണ് WAN പട്ടിക ഊഹിച്ച പൊതു ശ്രേണിയല്ല, യഥാർത്ഥ ഗേറ്റ്‌വേയും പ്രിഫിക്സും പ്രതിഫലിപ്പിക്കേണ്ടത്.

ഒഴിവാക്കൽ അതിന്റെ പട്ടിക നമ്പർ, നിയമ മുൻഗണന, കൃത്യമായ ഉറവിട വിലാസം എന്നിവയോടെ രേഖപ്പെടുത്തി സൂക്ഷിക്കുക. VPN-ലോ ഇന്റർഫേസിലോ ഉള്ള അടുത്ത മാറ്റം അതിനെ നിശബ്ദമായി തകർക്കാം, മൂന്ന് മൂല്യങ്ങൾ പേരെടുത്ത് പറയുന്ന കുറിപ്പ് ഉപഭോക്തൃ റിപ്പോർട്ടിൽ നിന്ന് ലക്ഷണം വീണ്ടും കണ്ടെത്തുന്നതിനേക്കാൾ വേഗത്തിൽ പരിശോധിക്കാം.

ഉറവിട-നിർദ്ദിഷ്ട തിരയൽ വിജയിച്ചതിന് ശേഷവും സേവനം തെറ്റായ വഴിയിൽ മറുപടി നൽകുന്നുവെങ്കിൽ, ലൈവ് സോക്കറ്റിന്റെ ഉറവിട വിലാസം നിയമത്തിലുള്ളതുമായി താരതമ്യം ചെയ്യുക. വൈൽഡ്കാർഡ് വിലാസത്തിൽ ബന്ധിപ്പിച്ച സേവനം നിങ്ങൾ പരീക്ഷിച്ച വിലാസത്തിൽ നിന്ന് വ്യത്യസ്ത ഉറവിടം തിരഞ്ഞെടുക്കാം, ആ പൊരുത്തക്കേടാണ് ബാക്കിയുള്ള വിടവ്.