നിങ്ങളുടെ iptables നിയമം പാലത്തിലൂടെയുള്ള VPN ട്രാഫിക് എന്തുകൊണ്ട് ഒരിക്കലും കാണുന്നില്ല
പാലത്തിലൂടെയുള്ള ഫ്രെയിമുകൾ നിങ്ങൾ നിരീക്ഷിക്കുന്ന IP ചെയിൻ ഒഴിവാക്കാം. മറ്റൊരു നിയമം ചേർക്കുന്നതിന് മുമ്പ് തദ്ദേശീയ bridge കുടുംബത്തെ പഴയ br_netfilter-മായി താരതമ്യം ചെയ്യുക.
ഒരേ ഹോസ്റ്റിലെ രണ്ട് വെർച്വൽ മെഷീനുകൾ ഒരു പാലത്തിലൂടെ LAN-ൽ എത്തുന്നു, എന്നാൽ ip forward ചെയിനിൽ വെച്ച ഒരു നിയമം ഒരിക്കലും നീങ്ങാത്ത ഒരു കൗണ്ടർ കാണിക്കുന്നു. ഫ്രെയിമുകൾ യഥാർത്ഥമാണ്, ട്രാഫിക് കടന്നുപോകുന്നു, എന്നാൽ നിയമം അതിന്റെ വഴിയിൽ ഇല്ല. Linux പാല ട്രാഫിക് പുറത്തുകാണിക്കുന്ന രണ്ട് രീതികൾ താരതമ്യം ചെയ്യുന്നത് ഈ നിശ്ശബ്ദത വിശദീകരിക്കുന്നു, കൂടാതെ ഒരു പഴയ മൊഡ്യൂൾ ലോഡ് ചെയ്യുന്നത് കാണുന്നതിനേക്കാൾ മോശം ഉത്തരമാണെന്നും ഇത് വിശദീകരിക്കുന്നു.
ഒരു ഹോസ്റ്റിലൂടെ രണ്ട് വഴികൾ
ഒരു പാക്കറ്റിന് ഈ ഹോസ്റ്റ് രണ്ട് വളരെ വ്യത്യസ്ത വഴികളിലൂടെ വിടാം, ആ വ്യത്യാസം ഏത് ഹുക്കുകൾ അതിനെ കാണുമെന്ന് തീരുമാനിക്കുന്നു. ലക്ഷ്യം ഒരു ഭൗതിക പോർട്ടിന് അപ്പുറമാണെങ്കിൽ, ഫ്രെയിം പാലത്തിന്റെ രണ്ട് പോർട്ടുകൾക്കിടയിൽ സ്വിച്ച് ചെയ്യുന്നുവെങ്കിൽ, ഹോസ്റ്റ് ഒരു Ethernet ഫ്രെയിം കൈമാറുന്നു; റൂട്ടിംഗ് കോഡിനോട് ചോദിക്കുന്നില്ല, റൂട്ട് ചെയ്ത ഒരു ഹോപ്പും സംഭവിക്കുന്നില്ല. ലക്ഷ്യം ഹോസ്റ്റ് തന്നെയോ ടണൽ ഇന്റർഫേസിലൂടെ എത്തുന്ന ഒരു നെറ്റ്വർക്കോ ആണെങ്കിൽ, പാക്കറ്റ് റൂട്ട് ചെയ്യപ്പെടുന്നു, IP പാളിയിലെ ഹുക്കുകൾ യഥാർത്ഥത്തിൽ ബാധകമാണ്. ഈ കവല ഓർമ്മയിൽ വയ്ക്കുക, കാരണം ചെയിനുകളെയും കുടുംബങ്ങളെയും കുറിച്ചുള്ള ഓരോ തുടർന്നുള്ള ചോദ്യവും ഫ്രെയിം രണ്ട് വഴികളിൽ ഏതാണ് സ്വീകരിക്കുന്നത് എന്നതിൽ നിന്നാണ് വരുന്നത്.
ആ വ്യത്യാസമാണ് ഒന്നും കണക്കാക്കാത്ത ഒരു നിയമത്തിന് പിന്നിലെ മുഴുവൻ കഥ. veth9a1 ൽ നിന്ന് enp3s0 ലേക്കുള്ള പാല ഫ്രെയിം IP സ്റ്റാക്കിലല്ല, പാലം കടക്കുന്നു, അതിനാൽ ip forward ചെയിന് പൊരുത്തപ്പെടുത്താൻ ഒന്നും കാണുന്നില്ല. പഴയ ഉദാഹരണത്തിലെ ഇന്റർഫേസ് നാമങ്ങൾ നിങ്ങൾക്ക് ഏത് വഴിയാണെന്ന് തീരുമാനിക്കുന്നില്ല, അതിനാൽ ആദ്യ ഘട്ടം റൂൾസെറ്റിലല്ല, ടോപ്പോളജിയിൽ നോക്കുന്നതാണ്.
ടണൽ പേര് നൽകാൻ യോഗ്യമായ മൂന്നാമത്തെ കേസ് ചേർക്കുന്നു. TUN ഉപകരണം IP പാക്കറ്റുകൾ ഹോസ്റ്റിന് നൽകുന്നു, അതിനാൽ അവ റൂട്ട് ചെയ്യപ്പെടുകയും യഥാർത്ഥത്തിൽ IP ചെയിനുകളിലൂടെ കടന്നുപോകുകയും ചെയ്യുന്നു, അതേസമയം പാലത്തിൽ ഘടിപ്പിച്ച TAP ഉപകരണം ഫ്രെയിമുകൾ നൽകുകയും പാല കേസ് പോലെ പ്രവർത്തിക്കുകയും ചെയ്യുന്നു. ഉപകരണത്തിന്റെ തരമാണ് തീരുമാനിക്കുന്നത്, ഉൽപ്പന്നത്തിന്റെ പേരല്ല.
പാല ഫ്രെയിം കാണാൻ കഴിയുന്ന രണ്ട് കുടുംബങ്ങളെ താരതമ്യം ചെയ്യുക
Linux nftables-ന്റെ bridge കുടുംബത്തിലൂടെ തദ്ദേശീയ പാല ഫിൽട്ടറിംഗ് പിന്തുണയ്ക്കുന്നു, പറക്കുന്ന ഫ്രെയിമുകൾ പരിശോധിച്ച് ഉപേക്ഷിക്കാൻ അതിന് പഴയ മൊഡ്യൂൾ ആവശ്യമില്ല. കേർണലിന്റെ സ്വന്തം പാല ഡോക്യുമെന്റേഷൻ ഈ ശുപാർശ നേരിട്ട് നൽകുന്നു, ഒരു സെർച്ച് ഫലം മൊഡ്യൂൾ ലോഡ് ചെയ്യാൻ പറയുന്നതിന് മുമ്പ് ഇത് അറിയുന്നത് ഉപകാരപ്രദമാണ്.
| Observation point | What it sees | What it costs |
|---|---|---|
nftables bridge family chains | Ethernet frames forwarded between bridge ports, in both directions | Rules must be written in bridge syntax with link-layer matches |
Legacy br_netfilter plus an ip chain | Bridged IPv4 and IPv6 packets, re-exposed through IP-layer hooks | Existing host rules may begin matching traffic they never saw before |
inet chain for routed traffic | Packets the host routes, including traffic arriving from a TUN device | No visibility into purely switched frames |
iptables-ന് പകരം nft കമാൻഡ് ഉപയോഗിക്കുന്നത് സ്വയം നിയമത്തെ ശരിയായ കുടുംബത്തിൽ നിർത്തുന്നില്ല. bridge കുടുംബത്തിൽ പ്രഖ്യാപിച്ച ചെയിൻ ഫ്രെയിമുകൾ കാണുന്നു; ip, ip6 അല്ലെങ്കിൽ inet-ൽ പ്രഖ്യാപിച്ച ചെയിൻ അവ കാണുന്നില്ല, അത് ഏത് ബൈനറി സൃഷ്ടിച്ചാലും. കുടുംബം ചെയിനിന്റെ സ്വത്താണ്, അത് ടൈപ്പ് ചെയ്ത ഉപകരണത്തിന്റേതല്ല.
പഴയ വഴി വ്യത്യസ്തമായി പ്രവർത്തിക്കുന്നു, അതുകൊണ്ടാണ് ശീലത്താൽ ഒരു വശം തിരഞ്ഞെടുക്കുന്നതിന് പകരം താരതമ്യം ചെയ്യേണ്ടത്. br_netfilter ലോഡ് ചെയ്ത് bridge-nf-call ക്രമീകരണങ്ങൾ പ്രവർത്തനക്ഷമമാക്കുമ്പോൾ പാലത്തിലൂടെയുള്ള IPv4, IPv6 ട്രാഫിക് വീണ്ടും IP പാളിയിലെ ഹുക്കുകളിലൂടെ പുറത്തുവരുന്നു, അതിനാൽ സാധാരണ iptables നിയമത്തിന് ഒടുവിൽ അതുമായി പൊരുത്തപ്പെടാം. ഫ്രെയിമുകൾ മാറുന്നില്ല; അവ കടന്നുപോകുന്ന ഹുക്കുകളുടെ കൂട്ടം മാറുന്നു, അതായത് ഓരോ നിലവിലുള്ള ഹോസ്റ്റ് നിയമത്തിനും ഇപ്പോൾ പുതിയ പ്രേക്ഷകരുണ്ട്.
നിയമം ചേർക്കുന്നതിന് മുമ്പ് യഥാർത്ഥ വഴി വായിക്കുക
മൂന്ന് കമാൻഡുകൾ നിങ്ങൾ എവിടെയാണെന്ന് നിർണ്ണയിക്കുന്നു: പാലം എന്തിലാണ് ഘടിപ്പിച്ചിരിക്കുന്നത്, പഴയ മൊഡ്യൂൾ സജീവമാണോ, bridge കുടുംബത്തിൽ ഏത് ചെയിനുകൾ ഇതിനകം ഉണ്ട്. എന്തെങ്കിലും എഴുതുന്നതിന് മുമ്പ് അവ പ്രവർത്തിപ്പിക്കുക, കാരണം ഉത്തരം രണ്ട് ഡിസൈനുകളിൽ ഏതാണ് വിപുലീകരിക്കുന്നത് എന്ന് തീരുമാനിക്കുന്നു. ഈ ഘട്ടം ഒഴിവാക്കുന്നതാണ് ശരിയായ നിയമം ഒന്നും കടന്നുപോകാത്ത ഒരു ചെയിനിൽ എത്തുന്ന വഴി.
bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"ഔട്ട്പുട്ട് കേസുകളെ വൃത്തിയായി വേർതിരിക്കുന്നു. പാലത്തിന് താഴെ ലിസ്റ്റ് ചെയ്ത പോർട്ടുകൾ ഏത് ഇന്റർഫേസുകളാണ് സ്വിച്ച് ചെയ്യുന്നത് എന്ന് പറയുന്നു; ശൂന്യമായ lsmod ഫലം അർത്ഥമാക്കുന്നത് പാല ഫ്രെയിമുകളുടെ IP പാളിയിൽ യാതൊരു ദൃശ്യതയുമില്ല; bridge കുടുംബത്തിന്റെ നിലവിലുള്ള forward ചെയിൻ അർത്ഥമാക്കുന്നത് നയത്തിന്റെ ഉടമ ഇതിനകം ഉണ്ട്, നിങ്ങളുടെ നിയമം സ്വന്തം പുതിയ ചെയിനിലല്ല, അവിടെയാണ് വരുന്നത്.
തുടർന്ന് തിരികെ വായിക്കാൻ എളുപ്പമുള്ള ഒരു നിയമം ചേർക്കുക, ഒരു കൗണ്ടറോടെ, വിധി മാറ്റാതെ, ഒരു പ്രതിനിധി പ്രവാഹം പാലത്തിലൂടെ കടത്തിവിടുക. ചലിക്കുന്ന കൗണ്ടർ ഫ്രെയിം നിയമത്തിൽ എത്തിയെന്ന് തെളിയിക്കുന്നു. അത്രമാത്രമാണ് അത് തെളിയിക്കുന്നത്, അതിനാൽ നിരസിക്കപ്പെട്ട വഴിയും കൂടി പരിശോധിക്കുക, കാരണം എല്ലാം സ്വീകരിക്കുന്ന നയവും ചലിക്കുന്ന കൗണ്ടർ ഉണ്ടാക്കുന്നു.
nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter acceptപഴയ മൊഡ്യൂൾ പെരുമാറ്റം മാറ്റുന്നിടത്ത്
പ്രവർത്തിക്കുന്ന ഒരു പാലത്തിൽ പഴയ വഴി പ്രവർത്തനക്ഷമമാക്കുന്നത് ദൃശ്യത ചേർക്കുന്ന ഒരു നിഷ്പക്ഷ പ്രവർത്തനമല്ല. പാല ട്രാഫിക്കിന് മുമ്പ് എത്തിച്ചേരാൻ കഴിയാതിരുന്ന നിയമങ്ങൾ എത്തിച്ചേരാവുന്നതാകുന്നു, മറ്റൊരു ഇന്റർഫേസിനായി എഴുതിയ ഹോസ്റ്റ് നിയമങ്ങൾ ഉൾപ്പെടെ, കൂടാതെ ip forward ചെയിനിലെ സ്ഥിരസ്ഥിതി drop നയം മുമ്പ് സ്പർശിക്കപ്പെടാതെ കടന്നുപോയ ഫ്രെയിമുകൾക്കും പെട്ടെന്ന് ബാധകമാകാം. ആ പാലത്തിലൂടെ കൈകാര്യം ചെയ്യുന്ന ഹോസ്റ്റിൽ ഫലം കൺസോൾ ഇല്ലാത്ത ലോക്കൗട്ടാണ്. ഇത് ഒരു സാങ്കൽപ്പിക പരാജയ മോഡല്ല; നിങ്ങൾ ഇപ്പോൾ വിപുലീകരിച്ച വഴിയിലൂടെ എത്തുന്ന ഒരു മെഷീനിൽ ഹുക്കുകളുടെ കൂട്ടം വിപുലീകരിക്കുന്നതിന്റെ സാധാരണ ഫലമാണ്.
കൂടുതൽ സുരക്ഷിതമായ ക്രമം ഏത് കുടുംബമാണ് നയം കൈവശം വയ്ക്കുന്നത് എന്ന് തീരുമാനിക്കുക, നിയമങ്ങൾ അവിടെ എഴുതുക, ഏതെങ്കിലും sysctl മാറ്റുന്നതിന് മുമ്പ് സ്വതന്ത്രമായ വീണ്ടെടുപ്പ് വഴി നിലനിർത്തുക എന്നതാണ്. രണ്ട് കുടുംബങ്ങളും നിയമങ്ങൾ സൂക്ഷിക്കുന്നുവെങ്കിൽ, ഏതാണ് അധികാരമുള്ളതെന്ന് രേഖപ്പെടുത്തുക; ഒരു ഫയലും വായിക്കാനില്ലാതെ ഒരിടത്ത് സ്വീകരിക്കുകയും മറ്റൊരിടത്ത് നിരസിക്കുകയും ചെയ്യുന്നതിന്റെ വഴിയാണ് രണ്ട് ഓവർലാപ്പിംഗ് നയങ്ങൾ.
വേർതിരിവിന് തന്നെ ഇപ്പോഴും പൂർണ്ണമായ ഒരു രൂപകൽപ്പന വേണം. ഒരു ഉറവിടത്തെ ഒരു ലക്ഷ്യത്തിലേക്ക് അനുവദിക്കുന്നത് ഒരു പ്രവാഹം പ്രവർത്തിക്കുന്നു എന്ന് മാത്രം തെളിയിക്കുന്നു, എന്നാൽ ആവശ്യകത സാധാരണയായി ഒരു VM-ന് അതിന്റെ അയൽക്കാരെയോ ഹോസ്റ്റിനെയോ എത്താൻ കഴിയരുത് എന്നതാണ്. നിരസിക്കൽ നിയമങ്ങളിലെ കൗണ്ടറുകൾ സ്വീകരണ നിയമത്തിലെ കൗണ്ടറിനേക്കാൾ പ്രധാനമാണ്, കാരണം സ്വീകരണ കൗണ്ടർ നീങ്ങുമെന്ന് നിങ്ങൾ ഇതിനകം പ്രതീക്ഷിച്ചതാണ്.
അവസാനമായി, ഹോസ്റ്റ് ഇൻപുട്ട് കേസ് വേർതിരിച്ച് വയ്ക്കുക. പാലത്തിന്റെ സ്വന്തം IP-യിലേക്ക് അഭിസംബോധന ചെയ്ത ട്രാഫിക് forward-ലല്ല, input-ൽ എത്തുന്നു, forward-ലെ ഒരു നിയമം നിങ്ങൾ ഏത് കുടുംബം തിരഞ്ഞെടുത്താലും അതിനെ ഒരിക്കലും കാണില്ല. മൂന്ന് കേസുകൾ, രണ്ട് കുടുംബങ്ങൾ, ഒരു പാഠം: വഴി ഹുക്ക് തീരുമാനിക്കുന്നു, ഹുക്ക് നിങ്ങളുടെ നിയമം ഉണ്ടോ ഇല്ലയോ എന്ന് തീരുമാനിക്കുന്നു.