പ്രാദേശിക ആപ്പ്, VPN നിയമം: നിങ്ങളുടെ FORWARD ചെയിൻ എന്തുകൊണ്ട് ഒരിക്കലും പ്രവർത്തിക്കുന്നില്ല
മെഷീനിലെ പ്രോസസ് OUTPUT ഉപയോഗിക്കുന്നു, FORWARD അല്ല. ശരിയായ namespace-ലെ hook തിരഞ്ഞെടുത്ത്, mark അല്ലെങ്കിൽ ലളിതമായ route മതിയോ എന്ന് തീരുമാനിക്കുക.
നിങ്ങൾ FORWARD ചെയിനിൽ VPN ട്രാഫിക്കിന് ഒരു നിയമം ചേർക്കുന്നു, അതേ Linux മെഷീനിൽ നിന്ന് അഭ്യർത്ഥന പ്രവർത്തിപ്പിക്കുന്നു, എന്നാൽ കൗണ്ടർ പൂജ്യത്തിൽ തന്നെ നിൽക്കുന്നു. നിയമം ഒരുപക്ഷേ ശരിയാണ്. പാക്കറ്റ് ആ വഴി ഒരിക്കലും സ്വീകരിച്ചില്ല, കാരണം മെഷീനിൽ തന്നെ ജനിക്കുന്ന അഭ്യർത്ഥന അത് മുന്നോട്ട് കൈമാറുന്നില്ല. സോക്കറ്റിൽ നിന്ന് വയറുവരെ പാക്കറ്റിന്റെ ജീവിതം പിന്തുടരുന്നത് ഇത് എന്തുകൊണ്ടെന്നും നിയമം യഥാർത്ഥത്തിൽ എവിടെ വേണമെന്നും വിശദീകരിക്കുന്നു.
പാക്കറ്റ് എവിടെ ജനിച്ചുവെന്ന് കണ്ടെത്തുക
Netfilter-ന്റെ hook ക്രമം മൂന്ന് സാഹചര്യങ്ങളെ വേർതിരിക്കുന്നു, അവയിൽ ഒന്നിൽ മാത്രമേ FORWARD ഉൾപ്പെടുന്നുള്ളൂ:
| Origin | Path | Hook that sees it |
|---|---|---|
| Local process | OUTPUT then POSTROUTING | OUTPUT, POSTROUTING |
| Addressed to a local service | PREROUTING then INPUT | PREROUTING, INPUT |
| Received for another host | PREROUTING, FORWARD, POSTROUTING | FORWARD |
പ്രാദേശിക ആപ്പ്ലിക്കേഷൻ OUTPUT പാതയിലാണ് തുടങ്ങുന്നത്, കാരണം പാക്കറ്റ് ഇവിടെ ഉത്പാദിക്കുന്നുവെന്നും ഒരിക്കലും മുന്നോട്ടുള്ള കൈമാറ്റത്തിന് സ്ഥാനാർത്ഥിയല്ലെന്നും കർണൽ മുൻകൂട്ടി തീരുമാനിച്ചിട്ടുണ്ട്. ടണൽ നിർമ്മിക്കുന്നത് ആ വർഗ്ഗീകരണം മാറ്റുന്നില്ല; ടണൽ പാക്കറ്റിന് പുറത്തുപോകാൻ കഴിയുന്ന ഒരു ഉപകരണമാണ്, പ്രാദേശിക ഔട്ട്പുട്ടിനെ ട്രാൻസിറ്റാക്കി മാറ്റുന്ന ഘട്ടമല്ല.
രണ്ട് പാക്കറ്റ്, ഒരു കഥ
ടണൽ ഉയർന്നുകഴിഞ്ഞാൽ ആപ്പിന്റെ ആന്തരിക പാക്കറ്റും എൻക്രിപ്റ്റ് ചെയ്ത ബാഹ്യ പാക്കറ്റും വ്യത്യസ്ത വസ്തുക്കളാണ്. ആന്തരിക പാക്കറ്റ് ആപ്പ് തിരഞ്ഞെടുത്ത ലക്ഷ്യവും പേലോഡും വഹിക്കുന്നു. ബാഹ്യ പാക്കറ്റ് സൈഫർടെക്സ്റ്റ് പീയറിന്റെ വിലാസത്തിലേക്കും പോർട്ടിലേക്കും കൊണ്ടുപോകുന്നു, ഭൗതിക ഇന്റർഫേസ് യഥാർത്ഥത്തിൽ കടക്കുന്നത് അതാണ്.
നിങ്ങളുടെ നയം അവയിലൊന്നിനെ സംബന്ധിക്കുന്നു, തെറ്റായത് തിരഞ്ഞെടുക്കുന്നത് നിയമം ഒന്നും ചെയ്യുന്നില്ലെന്ന് തോന്നുന്നതിനുള്ള സാധാരണ കാരണമാണ്. പീയറിന്റെ ബാഹ്യ വിലാസവുമായി പൊരുത്തപ്പെടുന്ന നിയമം ഓരോ ടണൽ പാക്കറ്റിനെയും ഒരേപോലെ കാണുന്നു, അകത്തെ ആപ്പ് എന്ത് ചെയ്താലും. ആന്തരിക ലക്ഷ്യവുമായി പൊരുത്തപ്പെടുന്ന നിയമം നിങ്ങൾക്ക് പ്രധാനമായ ട്രാഫിക്ക് കാണുന്നു, അത് നിങ്ങൾ നിയമം സ്ഥാപിച്ച hook-ൽ ആ പാക്കറ്റ് എത്തുമ്പോൾ മാത്രമേ പ്രവർത്തിക്കുകയുള്ളൂ.
namespace അതിർത്തി നീക്കുന്നു
കണ്ടെയ്നർ തത്വം മാറ്റാതെ ഇത് കൂടുതൽ ബുദ്ധിമുട്ടാക്കുന്നു. ആപ്പിന്റെ അഭ്യർത്ഥന കണ്ടെയ്നറിന്റെ നെറ്റ്വർക്ക് namespace-നുള്ളിലെ പ്രാദേശിക ഔട്ട്പുട്ടാണ്. ഹോസ്റ്റ് ആ ട്രാഫിക്ക് വെർച്വൽ Ethernet ഇന്റർഫേസിൽ സ്വീകരിച്ച് മുന്നോട്ട് കൈമാറാം, അതിനാൽ അഭ്യർത്ഥന സൃഷ്ടിച്ച പ്രോസസ് ഹോസ്റ്റിന്റെ OUTPUT ചെയിൻ ഒരിക്കലും സ്പർശിച്ചിട്ടില്ലെങ്കിലും ഹോസ്റ്റിലെ FORWARD നിയമം അർത്ഥവത്താകാം.
hook തിരഞ്ഞെടുക്കുന്നതിന് മുൻപ് നിയമങ്ങളുടെ കൂട്ടവും ടണലും യഥാർത്ഥത്തിൽ എവിടെയാണെന്ന് ഉറപ്പാക്കുക. കണ്ടെയ്നറിനുള്ളിലെ ടണൽ, കണ്ടെയ്നർ അതിലൂടെ route ചെയ്ത ഹോസ്റ്റിലെ ടണൽ, വേറിട്ട namespace-ലെ ടണൽ എന്നിവ മൂന്ന് വ്യത്യസ്ത ടോപ്പോളജികളും മൂന്ന് വ്യത്യസ്ത നിയമ സ്ഥാനങ്ങളുമാണ്. ഉപകരണം കൈവശമുള്ള namespace-നുള്ളിൽ നിയമങ്ങൾ വായിക്കുക, ഡിഫോൾട്ടിൽ മാത്രമല്ല.
mark യഥാർത്ഥത്തിൽ ആവശ്യമുണ്ടോ എന്ന് ചോദിക്കുക
ഒരു ലക്ഷ്യ പ്രിഫിക്സ് ടണലിലൂടെ അയക്കുകയാണ് ലക്ഷ്യമെങ്കിൽ, ആ പ്രിഫിക്സിന് ഒരു route മതിയായേക്കാം. ആദ്യം ഫലപ്രദമായ routes പരിശോധിക്കുക, സർവർ തള്ളിയ എല്ലാം ഉൾപ്പെടെ: റീഡയറക്ട് ചെയ്ത ഡിഫോൾട്ട് നിങ്ങൾ ഉദ്ദേശിച്ച ഇടുങ്ങിയ നയത്തേക്കാൾ എത്രയോ കൂടുതൽ ട്രാഫിക്ക് VPN-ലൂടെ അയക്കുന്നു, എത്ര mark ചെയ്താലും ഫലം ഉദ്ദേശവുമായി ഒത്തുപോകില്ല.
route പ്രകടിപ്പിക്കാൻ കഴിയാത്ത എന്തെങ്കിലും തീരുമാനം ആശ്രയിക്കുമ്പോഴാണ് വർഗ്ഗീകരണം ആവശ്യം, ഉദാഹരണത്തിന് ഉറവിടം, ഉപയോക്താവ് അല്ലെങ്കിൽ പ്രോസസ്. സ്വീകരിച്ച ട്രാഫിക്കിന് PREROUTING-ലെ mark പ്രവർത്തിക്കുന്നു. പ്രാദേശിക ട്രാഫിക്കിന് mark സ്ഥാപിച്ചതിന് ശേഷം പുതിയ route അന്വേഷണം ആരംഭിക്കാൻ കഴിയുന്ന ഔട്ട്പുട്ട് ഘട്ടത്തിൽ mark ചെയ്യണം. nftables-ൽ അത് ഔട്ട്പുട്ട് hook-ലെ route തരം ചെയിനാണ്; സാധാരണ ഔട്ട്പുട്ട് ഫിൽട്ടർ ചെയിൻ മൂല്യം സ്ഥാപിച്ച് route മാറ്റാതെ വിടും.
iptables-ൽ സമാനമായത് mangle OUTPUT ക്രമീകരണത്തിലുണ്ട്, അതേ വ്യവസ്ഥ ബാധകമാണ്: mark ഉണ്ടായതിന് ശേഷം route തീരുമാനം വീണ്ടും പരിശോധിക്കണം. തുടർന്ന് നയ നിയമം mark ഉപയോഗിച്ച് ഉപയോഗയോഗ്യമായ route ഉള്ള പട്ടികയിലേക്ക് ചൂണ്ടണം. conntrack mark സ്ഥാപിക്കുന്നത് മൂന്നാമത്തെ, വേറിട്ട പ്രവർത്തനമാണ്; അത് ഫ്ലോയിൽ മൂല്യം സൂക്ഷിക്കുന്നു, ആ മൂല്യം നിലവിലെ പാക്കറ്റിൽ സ്വയം ചേർത്ത് route-ന് വായിക്കാൻ കഴിയുന്നതാക്കുന്നില്ല.
അന്വേഷണവും കൗണ്ടറും ഒരുമിച്ച് പരിശോധിക്കുക
nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1വിലാസവും mark-ഉം ഉദാഹരണങ്ങളാണ്, രണ്ട് route ചോദ്യങ്ങളും വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു. രണ്ടാമത്തേത് പാക്കറ്റിൽ ആ mark ഉണ്ടായിരുന്നെങ്കിൽ കർണൽ എന്ത് ചെയ്യുമായിരുന്നു എന്ന് ചോദിക്കുന്നു; നിങ്ങളുടെ നിയമക്കൂട്ടം ഒരെണ്ണം നൽകുന്നുവെന്ന് അത് കാണിക്കുന്നില്ല. ഇതിനെ സിദ്ധാന്തപരീക്ഷണമായി കാണുക, നയം പ്രവർത്തിക്കുന്നു എന്ന തെളിവായി അല്ല.
തുടർന്ന് നിരുപദ്രവകരമായ ഒരു അഭ്യർത്ഥന പ്രവർത്തിപ്പിച്ച് ഒരുമിച്ച് രണ്ട് കാര്യങ്ങൾ നോക്കുക: നിങ്ങൾ തിരഞ്ഞെടുത്ത hook-ലെ കൗണ്ടർ, പാക്കറ്റ് യഥാർത്ഥത്തിൽ സ്വീകരിച്ച പുറത്തുകടക്കൽ. കൗണ്ടർ ഉയർന്ന് പാക്കറ്റ് മറ്റെവിടെ നിന്ന് പുറത്തുപോയാൽ mark അല്ലെങ്കിൽ പട്ടിക തെറ്റാണ്. രണ്ടും ഉയരുന്നില്ലെങ്കിൽ പാക്കറ്റ് ആ hook-ൽ എത്തുന്നേയില്ല, അടുത്ത ചോദ്യം namespace അല്ലെങ്കിൽ പാതയാണ്.
അവസാനമായി, പരീക്ഷണം സംവിധാനത്തിന് പ്രകടിപ്പിക്കാൻ കഴിയുന്നതിൽ ഒതുക്കുക. ഒരു വിലാസത്തിനുള്ള ഒരു route, വിലാസങ്ങൾ മാറുന്ന സേവനത്തിന് സ്ഥിരമായ നയമാകില്ല. ആദ്യം പാക്കറ്റ് പരിധി തീരുമാനിക്കുക, പിന്നീട് വീണ്ടും കണക്ട് ചെയ്ത ശേഷവും route-ഉം mark രൂപകൽപ്പനയും ആ പരിധി നിലനിർത്തുമോ എന്ന് പരിശോധിക്കുക.